How to prepare a Google Play Console account for publishing an Android app in Brazil

Publishing an Android app on Google Play often looks like a build task: generate an AAB, write a store listing, upload screenshots, and send the app for review. In practice, the fragile part usually happens before that.

If the developer account is not verified, if the payments profile has mismatched information, or if the app package is registered with the wrong signing key, a launch can stall for days.

This checklist summarizes the order we use at Sunstone Apps when preparing a Brazilian organization account before submitting an app.

1. Start with account identity

For an organization account, treat Play Console as a legal registration flow, not as a marketing profile.

Check:

• Legal organization name.
• Legal address.
• Tax identifier.
• Contact email and phone.
• Owner Google Account.
• Official organization documents.

In Brazil, documents such as the CNPJ registration extract, articles of incorporation, or MEI certificate can appear in the verification flow. The important part is matching: the name and address should align with the payments profile and the documents you submit.

If the CNPJ, company document, and payments profile show conflicting addresses, fix that mismatch before resubmitting documents.

2. Configure the public developer profile

The public developer profile is shown to users and also keeps the account coherent.

Before creating the app, prepare:

• Developer icon at 512x512.
• Header image at 4096x2304.
• Official website.
• Short promotional text.
• Developer email and phone.

This profile should represent the studio brand, not a single app. For us, Sunstone Apps is the public brand; the legal company name remains where Google needs it.

3. Create the payments profile early

If the app will have in-app purchases, subscriptions, or any revenue through Google Play Billing, do not leave payments until the end.

The payments profile asks for public merchant information. Some fields are easy to misread, such as the name shown on the buyer’s credit card statement. That is not your company’s credit card; it is the text the customer may see after buying something.

A good descriptor is short and recognizable:

Google* SUNSTONE APPS

After that, bank account verification may still require a micro-deposit. That can take a few days, so start before you depend on it.

4. Enroll in the 15% service fee tier

For small developers, it is worth checking enrollment in the 15% service fee tier.

The program applies a 15% service fee to the first US$1 million in eligible annual earnings for the account group. To enroll, Google asks you to create an account group and declare whether there are other developer accounts associated with the same legal entity or brand.

If there is only one Play Developer account for the company, declare that accurately. Do not create extra accounts to split apps or manipulate eligibility.

5. Do not register the wrong app key

Android developer verification may ask for the SHA-256 fingerprint of the certificate for a package name.

That value should come from the final app signing key or from the stable upload key used in the real release flow. Do not use a debug fingerprint or a temporary local build fingerprint.

Before registering the key, answer:

• Will the app use Play App Signing?
• Is the upload key stable?
• Is the local build signed with a real release key or a debug key?
• Is the package name final?

The package name is a long-term decision. After publishing, changing it means shipping another app.

6. Create the app after the account is ready

Once identity, public profile, payments, and signing are understood, creating the app is much simpler.

For a free game with ads and in-app purchases, you will still configure:

• App category and type.
• Ads declaration.
• Data Safety.
• Content rating.
• Store listing.
• Screenshots and feature graphic.
• Play Billing products.
• Internal or closed testing track.

The first submission does not need every roadmap idea. It needs to match what the app actually does. If the Data Safety form says users can request data deletion, prefer a dedicated public page for that flow in addition to the privacy policy.

Final checklist

Before uploading the AAB, validate:

• Developer account has no policy alert.
• Organization is verified.
• Payments profile is created.
• Bank account is verified or in verification, depending on revenue needs.
• Public developer profile is configured.
• Account group is created.
• 15% service fee tier is enrolled, if applicable.
• Package name is final.
• SHA-256 is registered only with the correct final key.
• Public legal pages are live.
• Public data deletion URL is live, when declared in Data Safety.
• Support email works.

This work is not glamorous, but it reduces the chance that launch day gets blocked by an administrative detail after the app is ready.

What to prepare before opening Play Console

A smoother first submission starts before the first field in Play Console. Keep the store identity, package name, signing plan, privacy answers, and testing route in one small release note. The goal is not bureaucracy; it is avoiding decisions while the console is already asking for irreversible or slow-to-change values.

For an indie Android app, the minimum checklist is usually enough:

• confirm the final Android package name before uploading any build;
• decide whether Play App Signing will manage the app signing key;
• keep the support email, developer name, privacy policy, and terms URLs ready;
• prepare screenshots and the short description before the binary is uploaded;
• know which countries and tester groups should see the first release.

The biggest mistake is treating Play Console as the place where the release is designed. It works better as the place where a release that already exists is registered.

The slow parts are review and trust

Most first-time publishers underestimate the non-technical waiting time. Google can review the developer account, app content, declarations, data safety answers, and the test track itself. None of those steps is hard, but each can block progress if the answer depends on a missing website page, unclear data collection policy, or an app build that was not generated like a real release.

That is why we prefer an internal track before anything public. Internal testing proves that the package installs, the store page opens, the Play account is eligible, and the binary behaves like the release we intend to ship. It also catches problems that a local debug build hides, such as billing availability, signing differences, and production-only configuration.

A practical first-release rhythm

The safest rhythm is boring: create the app record, upload a release build, invite a tiny tester list, validate install and launch, then expand the checklist. Only after that should the store listing and public rollout get polished for broader traffic.

That sequence keeps the feedback loop small. If installation fails, debug install. If billing fails, debug billing. If the listing is incomplete, debug content. Mixing all of those in the first public submission makes every failure feel bigger than it is.

The order of setup matters

Some Play Console tasks look independent but are easier in a specific order. Start with identity and legal pages because many later forms reference them. Then create the app record and testing track. Only after that does it make sense to polish listing assets.

That order avoids rework. A privacy policy URL that changes late can force edits in the listing, data safety answers, and tester communication. A package name mistake after an upload can be worse: the app record is tied to it, and starting over may be cheaper than trying to bend the release around a bad identifier.

For a first app, the safest mindset is to treat every public identifier as permanent until proven otherwise.

The practical test is simple: if a new teammate can open the note and recreate the first internal release without asking what each field means, the preparation is good enough.

Conclusion

Opening Play Console is not the hard part. The hard part is arriving with stable identifiers, legal pages, payment setup, and a release path that can survive review. Treat the first internal release as a controlled operations exercise, not as a form-filling sprint.