What Google Play reviewers need for login or paywall apps

What do I need to give Google Play reviewers if my app has a login or paywall

Give Google Play reviewers everything needed to enter the app and reach the restricted parts without guessing. That means an active demo account or valid login details, clear steps for any special sign-in flow, and access instructions for anything hidden behind a subscription or paywall. Google says that if it cannot get in, it cannot complete review.

Use the Play Console App content page to add sign-in details and restricted-access instructions. Google’s help says to provide all required details for apps restricted by login credentials, memberships, location, or other authentication, and it allows up to five sets of instructions. If your app uses a one-time password, multi-factor authentication, or more than two login fields, put that in the instructions too.

If your app requires sign-in, provide a test username or phone number, a password, and any extra steps needed to reach the content Google must review. Google also says to use only credentials made specifically for testing, not production user credentials. That matters when the reviewer needs to see paid features, gated tools, or premium screens that are not visible after a normal install.

If the app has a subscription paywall, do not stop at the paywall screen. Google’s review instructions say to provide additional access details that let reviewers fully and freely access the content behind the paywall. In practice, that means either a test account with the needed entitlement already active or clear steps that unlock the feature for review.

The part people get wrong is assuming a reviewer will create an account, complete a purchase, or figure out a special flow from the store listing. Google does not ask reviewers to improvise. The review team uses the instructions you provide, and if the app is inaccessible, the app may be rejected because it cannot be reviewed.

The inconvenient part is that every barrier needs to be documented in the exact place Google asks for it. If sign-in is required, write down the login details. If a QR code is required, include it. If the app uses Google sign-in, Facebook sign-in, multi-factor authentication, or another external account, spell out the full path. If the content is behind a paywall, explain how the reviewer reaches it without paying.

A good setup is a dedicated reviewer account with stable access, plus short instructions that match the app’s real flow. For example: open the app, tap Sign in, enter the test email and password, confirm the code sent to the test inbox, then open Premium to review the subscription screen. That kind of note saves time because it removes the need for back-and-forth during review.

If your login flow changes, update the instructions before resubmitting. Google says the App content page should stay current, and it specifically tells developers to provide and manage access instructions there. If the stored instructions are stale, the review can fail even when the app itself works.

Do not rely on buying testers or installs to try to make review easier. Google Play says incentivized and inauthentic engagement can trigger enforcement, and paid tester schemes are not a valid shortcut. Review access and production access are separate problems, and the clean solution for review is straightforward access instructions, not artificial traffic. For DevConnect users, the right pattern is to exchange real testing on apps you own or control, not to buy access.

If you want a simple checklist before submission, use this sequence: make one test account that never expires, confirm it can reach every restricted screen, write the exact steps in Play Console, and verify that any password reset, OTP, or subscription step is also covered. If a reviewer has to ask how to proceed, the instructions were too thin.

For teams that are still setting up their release process, DevConnect can help you organize real testers and keep review accounts separate from production accounts. The platform itself is free to use, and the important rule stays the same: reviewers need access, not a sales pitch. See https://devconnectplatform.com for the product context, then keep the Play Console instructions specific and complete.

If your app is also subject to closed testing for a new personal developer account, that is a separate requirement from reviewer access. Google Play currently requires at least 12 testers opted in continuously for 14 days before production access for eligible personal accounts created after 13 November 2023. That requirement does not replace sign-in details or paywall access instructions, it sits alongside them.

The safest rule is simple: if a human needs a key, code, entitlement, or alternate route to see your app, give Google Play that key in the review fields. If the reviewer has to work around the lock, the app is harder to approve, and the fix is to document the access clearly before you submit.

Quick checklist

• Active demo account or valid login credentials.
• Exact sign-in steps, including OTP, MFA, or QR code steps.
• Test-only credentials, not a production user account.
• Instructions to reach any subscription or paywalled content.
• Updated notes in Play Console if the login flow changes.

What usually causes rejection

• Only giving a store listing and expecting the reviewer to create an account.
• Hiding the premium feature behind a paywall with no unlock path for review.
• Using expired or production credentials that stop working during review.
• Forgetting to document MFA, OTP, or an external sign-in provider.

What to do when the reviewer cannot get in

Open Play Console, update the Sign-in details section, then resubmit the changes for review. Google’s instructions say you can manage these details on the App content page and send the updated changes through Publishing overview. The fix is administrative, not technical, so do it before the next submission rather than waiting for another rejection.