Registering is not the same as being able to publish
Readers searching for how to apply often expect one submission and one review. In practice there are three stages: create the account and pay the one-time registration fee, complete identity or organization verification, then meet the requirements that apply to new accounts before a first release. The first takes minutes. The other two decide whether you can ship. Fees, accepted payment methods and verification rules change, so treat the Play Console sign-up page as the source of truth at the time you register.
Gather these items first, or you will redo steps midway
You need a dedicated Google account with two-step verification, not a shared or casual mailbox. You need a card that supports international payments, ideally matching the entity you register. You need your legal name and address exactly as on a government-issued ID for a personal account. You need a contact email and phone number that you can keep for years, because they are verified and later receive review notices. And you need a developer name, which is shown publicly on your store listing. For an organization account, add the legal entity name, a D-U-N-S number, a website, and evidence that you can act on the organization's behalf. D-U-N-S issuance or updates can take time, so confirm it before you start.
Most form errors come from inconsistent names and contact details
The form is simple, but mismatches cause failures. A name spelled differently from the ID, or an address formatted differently from the document, can fail later verification. Avoid developer names that imply an official relationship, use another party's trademark, or include terms such as Google. Temporary email addresses can lose verification codes and policy notices. The phone number should receive SMS or calls and include the right country code. Display fields are usually editable later, but changes to legal entity details often trigger re-verification, so enter them exactly as documented the first time.
If verification stalls, check three root causes in order
The first is the documents themselves: blurry, glared or cropped images, an expired ID, or an organization name and address that differ from the D-U-N-S record. The second is conflicting identity data: payer, ID name and developer profile that do not line up, or several accounts created in a short time from the same device or network. The third is account association: Google's policies cover related accounts, so overlap in details, devices or payment methods with a previously terminated account can lead to rejection. The first two are fixable by resubmitting. The third is not solved by retrying and needs an appeal. Read the rejection message in Play Console and your inbox, fix the fields it points to, and avoid replacing everything on a guess.
After verification, new accounts face extra conditions before release
Verification gets you into Play Console, nothing more. For newly created personal accounts, Google has required closed testing before production access, with thresholds for testers and duration; exact numbers and scope are whatever Play Console states at the time. Some accounts also need to verify through an Android device. On the app side you need a privacy policy URL, the Data safety form, the content rating questionnaire, a target API level that meets current requirements, and access instructions if the app has a login. These surface only at submission, so build the testing period into your schedule instead of assuming launch on registration day.
Know when to stop retrying and change course
Use three tests. If the same rejection appears twice after you corrected what it pointed to, the cause is not the form, so stop and audit the identity data and supporting documents. If the message refers to account association or a policy violation, go to appeal and stop creating new accounts, since each one widens the association. If an organization lacks a D-U-N-S number or cannot show authority to represent the company, fix that first rather than switching to a personal account, which creates ownership and transfer problems for a business app later. Checks done before paying are cheap; the same gaps found after payment cost waiting time.