Paywall Still Showing After Signing In: Where a Paid News Subscription Gets Lost

A digital news subscription can be billing correctly every month and still produce a paywall on every article inside the publisher's own app. The bank statement shows the charge. The app shows a signed-in name in the corner. The article still stops after three paragraphs. Clearing the app cache, reinstalling, or changing the password rarely moves this, because in most cases nothing is broken — two separate records simply have never been introduced to each other.

The fix depends on one question that troubleshooting usually skips: who took the money. A subscription bought through the App Store belongs to an Apple Account. One bought through Google Play belongs to a Google Account. One bought on the publisher's own website belongs to whatever email address went through that website's checkout. One supplied by a university, an employer, or a public library belongs to none of them. Those are four different records held in four different systems, and the app can only open content when it can see the one that applies to this device.

Start With the Receipt, Not With the App

Apple's own subscription guidance points at the receipt first: to work out which account a subscription sits under, look through email for a message with the subject receipt from Apple or invoice from Apple. Google's purchase documentation says the same thing from the other side — a confirmation email with the order information goes to the Google Account used at the time of purchase. If neither exists anywhere in the mailbox, the charge almost certainly came from the publisher directly, and the publisher's own confirmation email is the record that matters.

Purchase history can be checked without waiting to find the email. These paths are the ones Apple and Google currently publish:

• Apple, on iPhone: open the App Store app, tap the Sign-In button or the photo at the top of the screen, then tap Purchase History.
• Apple, on iPad: the same route, except the tap order is Apps & Purchase History, then Purchase History.
• Apple, on the web: reportaproblem.apple.com, signing in with the Apple Account and password.
• Google Play, in the app: open the Play Store, tap the profile icon at the top right, then Payments & subscriptions, then Budget & history.
• Google Play, on the web: play.google.com, profile icon at the top right, then Payments & subscriptions, then Budget & Order history.

Apple attaches an explicit warning to that history page, and it is the single most common cause of this whole symptom: if more than one Apple Account exists, a different one may have been used to buy the item, and the advice is to sign in with the other Apple Account and check the history again. Google's subscription page carries the equivalent instruction — make sure you are signed in to the Google Account that has your subscriptions.

When Apple or Google Is the Biller

A subscription bought inside an app is a store transaction. Apple holds it against an Apple Account and Google holds it against a Google Account, and the publisher never sees the card. Two consequences follow, and both cause paywalls.

The device has to be signed in to the buying account

If the subscription was bought on an old phone under a personal Apple Account, and the current phone signs in to a work Apple Account, the store has no record to hand the app. Confirm which account the store is using before anything else — on iPhone, open the App Store app and tap the photo or Sign-In button at the top of the screen; the account in use is shown there. To see the subscription itself, Apple's route is the Settings app, then tap your name, then Subscriptions. On the web the same list sits at account.apple.com/account/manage/section/subscriptions. On Google Play, the route through Android settings is Google, your name, Manage your Google Account, Payments & subscriptions, Manage subscriptions.

If the subscription is not in that list, the account currently signed in is not the account that owns it. That is the finding, and no amount of app-side troubleshooting substitutes for it.

The app needs a restore step, and it is not automatic

Apple's App Store Review Guidelines make the point plainly in section 3.1.1: developers should make sure you have a restore mechanism for any restorable in-app purchases. That mechanism exists precisely because a purchase does not travel with a reinstall or a new device by itself. After reinstalling an app, restoring from a backup, or moving to a new handset, the app has to be told to go and ask the store what this account already owns.

What that control is called is not standardized, and no platform rule fixes the wording, so guessing at a specific button name would be inventing detail. It usually lives in the app's account or settings screen. The reliable instruction is: look through the app's own account screen for the option that re-checks purchases, and use it while the device is signed in to the buying account.

When the Publisher Is the Biller

If the receipt came from the publisher rather than from Apple or Google, the store is irrelevant. The subscription is attached to an email address in the publisher's own system, and the app is a client that has to sign in to that system.

Apple's guidelines describe this category of app directly. Guideline 3.1.3(a) covers what Apple calls Reader apps — magazines, newspapers, books, audio, music and video — and states that such apps may allow a user to access previously purchased content or content subscriptions, and may offer account management functionality for existing customers. That is why a news app can show a plain sign-in field with no purchase option next to it. It is not a defect; it is the app operating as a reader for content bought elsewhere.

The address on the receipt is the one that counts

A publisher account can quietly exist twice. A subscription started years ago on a work address, and a free account created later on a personal address, are two records; signing into the second one produces a valid session with no entitlement behind it. The test is narrow and it settles the question: sign in on the publisher's website in a browser, using the address printed on the billing receipt, and see whether the site opens articles. If the browser session is unlocked and the app is not, the app is signed in as somebody else — sign the app out completely and back in with the receipt address.

Sign in with Apple hides the address that was actually used

An account created through Sign in with Apple may not be filed under a normal address at all. Apple documents that Hide My Email creates addresses on the domain @privaterelay.appleid.com, and that the choice is offered at sign-up: share the real address if the app or site is familiar, hide it for more privacy. A subscription bought under a relay address will not be found by searching the publisher's system for a personal address, and support staff will not find it either.

The list of apps and sites where Sign in with Apple was used can be checked directly. On iPhone or iPad: open Settings, tap your name, then tap Sign in with Apple. On Mac: Apple menu, System Settings, your name, then Sign in With Apple. If the publisher appears in that list, the account was created that way, and the app must be signed into the same way — a typed email and password will land on a different record. Where the relay address forwards can also be inspected, on iPhone at Settings, your name, iCloud, Hide My Email, then Forward To at the bottom.

Google's equivalent is Subscribe with Google, which Google documents as a website checkout using the phrase Subscribe with your Google Account or Subscribe with Google, with the instruction to make sure the correct Google Account is signed in. A subscription started that way is filed against a Google identity, not against a password the publisher holds.

When a Library, School, or Employer Supplies the Access

Institutional access is a different animal, and it is the category most likely to have no app-side answer at all. Library and campus access is often delivered by a proxy. OCLC describes EZproxy, one widely deployed example, as connecting users to licensed e-resources using their existing single sign-on credentials, and as connecting on the user's behalf from an authorized IP address so the content provider grants access regardless of where the reader physically is.

The consequence matters here: that entitlement belongs to a browser session travelling through the institution's proxy. A native app talking straight to the publisher's servers is not inside that session. So a subscription that opens every article in the campus browser can be completely invisible to the same publisher's app on the same phone.

Whether a specific publisher supports institutional sign-in inside its app, and by what route, is a publisher-by-publisher question with no general answer. It has to be confirmed with the library or IT service desk that provides the access. Where the app is not supported, the browser is the working route, and treating that as a fault only wastes time.

When the Payment Quietly Failed

An expired card produces the same visible symptom as an account mismatch: a paywall on an account that has been paid for. The difference is that the biller has a published sequence for it, and one of them states the numbers.

Google Play's documentation describes what happens after an unsuccessful subscription payment: there may be a grace period during which the subscription still works; when that ends, or where there is none, the account may be placed on hold for up to 60 days, during which the subscription cannot be used. Separately, Google notes that an authorization hold may appear on the payment method up to 48 hours before the next renewal period — up to five days for accounts based in India or Brazil — which explains a pending charge that does not match the billing date. Google's advice on prevention is specific: add a second payment method to the Google Play account so a failing primary card does not interrupt the service.

On the Apple side, the published fix for a declined payment method is: open Settings, tap your name, go to Payment & Shipping, add a different payment method, remove the old one, and try the purchase again. Apple's article on declined payments does not publish a retry schedule or a hold length, so the exact window before access stops is not a documented number and should not be treated as one. Apple also states outright that it does not have information about why a payment method was declined, which means the bank — not the publisher and not the store — is the party who can answer that.

A Check Order That Does Not Waste Steps

1. Find the billing receipt and read who sent it: Apple, Google, the publisher, or nobody.
2. Open the matching purchase or subscription list from the paths above and confirm the subscription is actually listed and active.
3. If it is not listed, sign in to the other Apple or Google account that may have bought it, and check again.
4. Sign in on the publisher's website in a browser using the address on the receipt. If the browser opens articles, the problem is on the app's sign-in, not on the subscription.
5. Sign the app out fully, then back in with that exact address — or with Sign in with Apple / Subscribe with Google if the account was created that way.
6. For a store purchase, run the app's restore-purchases step while the device is signed in to the buying account.
7. Check the payment method for a decline or an expired card before opening a support ticket.

What Not to Try

Two habits make this worse. The first is creating a fresh publisher account to get past a sign-in error, which produces a third record with no entitlement and a support case that is now harder to untangle. The second is deleting the app to cancel the billing: Google states plainly that uninstalling an app does not cancel the subscription, and Apple keeps cancellation inside the subscription list, so removing the app leaves the charge running while removing the only place the access could appear.

When This Doesn't Apply

This diagnostic frame assumes a live, paid entitlement that the app cannot see. It does not apply in several situations. If the subscription is a limited tier — a digital plan that does not include the section being opened, or a print plan without digital access — the paywall is the product working correctly, and no sign-in will change it. If the article sits behind a separate one-off purchase or a partner publication, the main subscription was never meant to open it. If access came from a promotional or trial period that has ended, there is no entitlement left to restore. If the account is shared through Apple's Family Sharing, note Apple's rule that a subscription belongs to the family member whose Apple Account appears on the receipt, so another member's device may genuinely have no claim on it. And where access is institutional, the app may simply be outside the supported route, in which case the browser is the answer rather than the workaround.

This is also not a guide to reading paywalled articles without a subscription. Everything above concerns getting an existing, paid entitlement recognized by the app it was bought for.

Escalating With Evidence That Ends the Ticket

Where the ticket goes depends on the same first question: a store-billed subscription is a store matter for anything involving the charge, and a publisher matter for anything involving what the app shows. Apple's guidance on reaching a developer is to check the App Store listing, which shows who made the app and where to get support, or to look in the app's own menus and settings for contact details.

What shortens the exchange is sending the identifiers rather than the story: the biller's name from the receipt, the order or transaction identifier, the exact email address the account was created under — including the @privaterelay.appleid.com address if Sign in with Apple was used — and one line stating whether the publisher's website opens articles in a browser. That last line tells support in a single sentence whether they are looking at a broken entitlement or a mismatched login, and it is the detail that most tickets leave out.