How to Create a Google Play Developer Account in 2026

The 14-day test is the only part of this list that depends on other people, and it is where solo developers stall. It is the part PrimeTestLab runs for you, and it is covered in how we help at the end of this post.

Most walkthroughs for this query stop at the payment confirmation, and most of them were accurate when they were written. The problem is what Google added afterwards: an identity check that compares your documents against a payments profile you may not have looked at in years, a device-verification task for new Personal accounts, and a production gate that the date you created the account pulls you into, then makes you clear app by app. The result is a familiar sequence of forum posts, and they all start the same way. I paid the $25, so why can I not publish anything.

This post is written in the order the decisions actually bite: what to have ready before you pay, what each account type has to produce, what the console asks for and in what order, which details must match which record, and what a new Personal account owes Google after the receipt arrives. Where Google publishes a number, it is quoted with the Help answer it comes from. Where Google publishes nothing, this post says so instead of borrowing a figure from a vendor page that does not know either. Everything here was checked against Google's own documentation and is current as of August 13, 2026.

What to prepare before you pay Google

The $25 payment gets treated as the moment of commitment because it is the only step that touches your bank account. It is the wrong thing to be nervous about. The steps that are genuinely hard to undo are the ones that cost nothing: the Google Account you happen to be signed in as becomes the account owner, and while Google now documents a restricted way to hand ownership to someone else, it is not available to every account and it is not a settings toggle. The legal identity you type becomes the thing every document you later upload is compared against, and some of it is published on Google Play. Neither of those asks you to confirm that you are sure.

On the fee itself, this post says one thing and moves on: it is US$25, charged once per developer account, not an annual membership and not per app. The full breakdown of what the fee does and does not cover lives in the Google Play publishing requirements post.

What Google will show publicly

This is the part of the decision that gets skipped, and it is the one people come back to regretting. Some of what you type into the signup form is displayed on your Google Play listing for anyone to read. A Personal account is not an anonymous account, and if you monetize, the disclosure widens.

Scroll the table sideways to see every column

The pre-registration checklist

The list below is Google's requirements reorganized by when you need them rather than by which Help page they live on, and it is split into three stages on purpose. Stage 01 is what the signup form asks for, and it is the only stage the verdict scores. Stage 02 and stage 03 are real requirements that arrive after your money does, and a checklist that mixes them into one score tells you that you cannot register until you have found 12 testers, which is simply untrue. Two rows carry real waiting time, and both are organization rows, which is the practical reason an organization signup should never be started on the same day it is decided.

Pre-pay readiness inspector

The three decisions that are hard to undo

Everything else on that list can be corrected with a form. These three cannot, or not cheaply.

None of this makes approval certain. It removes the failures Google actually documents, which is a different and more useful thing. What it cannot remove is the waiting: Google publishes precise timings for the narrow parts of the process and nothing at all for the identity review as a whole, which is covered in the verification section below.

Personal or Organization at signup

The important thing to know first is that this is not a tier system. Google says the two account types have access to the same general functionality, and both can monetize through a payments profile. Nobody is buying a better Play Console by registering an organization. What differs is what you have to produce to get in, and what obligations follow you afterwards.

Four categories where Google makes the choice for you

Google names four kinds of app whose developers should use an Organization account, regardless of how the developer thinks of themselves:

If your app is in one of those groups, the account-type question is already answered and the D-U-N-S lead time becomes part of your build schedule rather than an afterthought.

What each type has to produce

This table is about the signup desk only: what Google asks each type for, and what each type carries afterwards. Whether an Organization account is worth forming a company for is a different question with a different answer for almost everyone, and it is covered properly in Personal vs Organization accounts.

Scroll the table sideways to see every column

Can you change the account type later?

This is the fact most likely to be wrong in whatever else you have read. For years the standard advice was that the account type is chosen once and permanently, and that a developer who incorporated later had to register a second account from scratch. Google's current documentation does not say that. It describes a conversion path, and it distinguishes clearly between the direction it supports and the direction it does not.

What the conversion actually involves

The mechanism is a payments-profile change rather than a Play Console toggle, which is why it is easy to miss in the documentation. You create or switch to a Google Payments profile of the organization type, complete the verification that profile requires, which for an organization means the D-U-N-S number and the organization documentation, and link it to the developer account. The D-U-N-S lead time applies here exactly as it does at signup, so converting is not a same-day operation either.

And the owner, which used to be the permanent one

This is the claim most worth updating in your head, because it was true for a long time and is repeated everywhere, including in older versions of this post. Google now documents a self-service owner transfer. Only the current account owner can start it, and the path is Play Console, Users and permissions, find the person you want to hand the account to, Manage, then Make account owner. The transfer is then held for seven days before it completes, and the prospective owner may be asked to verify their identity and provide payment-profile information.

The eligibility line is where it still bites. Google scopes the direct process to Organization accounts and non-monetizing Personal accounts, and says individual developers who monetize their apps are currently ineligible for it. So the developer most likely to want this - the solo publisher who registered personally, started earning, and now wants the company to hold the account - is the one it does not cover. Their route is unchanged: a new developer account, verified from scratch, with the apps transferred to it.

One further caution on the same theme: choosing an organization type you are not entitled to is not a paperwork shortcut. An Organization account is verified against a real business record held by a third party, and fabricating that is a policy problem rather than a clever workaround.

Play Console signup, step by step

Registration opens at play.google.com/console/signup. Before you click it, be sure about which Google Account your browser is signed in as, because that is the decision the flow will never ask you to reconsider.

The eight checkpoints

1. 01
   Sign in with the Google Account that will own the account

   The owner has to be at least 18. Ownership can be handed over afterwards, but only in the cases Google documents: Organization accounts and non-monetizing Personal accounts, started by the current owner, held for seven days, with verification on the incoming owner. A Personal account that monetizes is currently outside that process, so for a lot of developers the account you happen to be signed in as is still effectively the permanent one. Google asks for a Google Account and does not state that it must be a gmail.com address, whatever the tutorials say.

   Goes wrong when: you are signed into a personal browser profile and register the company's account on it.

2. 02
   Choose Personal or Organization

   Personal is Google's option for personal use, including students, hobbyists and amateur developers. Organization is for businesses and organizations. Four app categories are directed to Organization accounts by Google: financial products and services, health apps including medical and human subjects research, apps approved to use VpnService, and government apps.

   Goes wrong when: an organization signup is started before the D-U-N-S number exists.

3. 03
   Create or select a Google Payments profile of the matching type

   Registration links to a Google Payments profile, and the profile type has to match the account type you picked. An existing personal profile cannot carry an organization registration. The identity held on this profile is the reference every document you later upload is compared against, so open it and read it before you go further.

   Goes wrong when: an old payments profile holds an address you moved out of years ago.

4. 04
   Enter your legal, contact and public developer details

   Type the legal name and address exactly as your identity document prints them. You provide a contact email and phone that Google uses to reach you, which are verified but not shown publicly, and a public developer email that is displayed on Google Play. Organization accounts also provide a public developer phone number. Phone numbers go in international format.

   Goes wrong when: the public developer email is a personal address you would rather not publish.

5. 05
   Accept the agreement and pay US$25, once

   You accept the Google Play Developer Distribution Agreement and pay the one-time registration fee. It is charged per developer account, not per app, and it does not renew annually. Google's accepted-payments page lists the card networks it takes, with regional differences, and says prepaid cards are not accepted.

   Goes wrong when: the fee is paid on identity details that were guessed rather than checked. Google warns that invalid identity information can result in the fee not being refunded.

6. 06
   Verify your contact email and phone

   Google sends a six-digit code to the email address and a six-digit code to the phone by SMS or voice call. These are the private contact details, the ones Google uses to reach you rather than the ones shown on your store listing.

   Goes wrong when: the SMS does not arrive. Google's documented answer is the voice-call option, then signal and operator checks, rather than creating a new account.

7. 07
   Complete identity verification

   A Personal account may be asked for an official government identity document, if the linked payments profile has not already been verified. An Organization account may be asked for the D-U-N-S number, an official organization document and a representative's identity document, and newly created Organization accounts have an additional website-verification requirement. Everything submitted has to match the payments profile.

   Goes wrong when: the document and the profile disagree by one line. Google names this match as a requirement, and it is the failure that fills the most Help Community threads on this topic.

8. 08
   Verify a real Android device, on a new Personal account

   New Personal accounts complete a device check in the Play Console mobile app before an app can be made available on Google Play. Google requires a physical, non-rooted device running Android 10 or later, and says the check itself takes less than a minute.

   Goes wrong when: you develop entirely on an emulator and own no eligible phone. Google allows the same device to verify more than one account, so borrowing one is a documented option.

What comes after the eighth checkpoint

Those eight finish the account. They do not finish the route to a published app, and the order of what follows is worth being precise about, because a lot of pages imply the 12-tester test is something you owe before you are allowed to create an app. The opposite is true. You create the app, complete its setup, store listing and declarations, upload a build and publish a release to a closed track first, because the qualifying test runs on that release. Only then does the 14-day clock start. When it finishes you are eligible to apply for production access, Google reviews the application, and the production release goes out after that access is granted.

There is one ordering caveat, and it is the difference between preparing a test and running one. Account verification still gates the release itself: Google says a developer account has to be verified before apps can be submitted for consideration, and on a new Personal account the real-device check has to be completed before an app can be made available on Google Play. So creating the app, configuring it and writing the store listing are all things you can do while the identity review is still running. Publishing the closed-track release that the 14-day clock runs on is not. Plan for the overlap you actually get, which is preparation, not elapsed test days. Verified

Two claims you will meet elsewhere are worth naming so you can discount them on sight. The first is that signup requires an address ending in @gmail.com: Google's signup page asks for a Google Account, which can be created on an address you already own. The second is that Google "usually activates" a developer account within 24 to 48 hours. No such commitment appears in Google's current documentation, and building a launch plan on it is how a release date slips in public. No published SLA

Documents, matching rules and the delays nobody publishes

Verification is where the process stops being a form and starts being a comparison. Google is not reading your document to learn who you are. It is checking your document against a record it already holds, and where an organization is involved, against a second record held by Dun and Bradstreet. Google states the requirement plainly: what you submit must match the information in your linked payments profile. In the Help Community threads reviewed for this post, the rejections with a diagnosable cause came down to those records disagreeing about a name, an address, or a single missing line of an address.

What each account type is asked for

Scroll the table sideways to see every column

The exact-match rule, before you upload

The rule is easy to state and easy to fail: the legal identity on the document, the identity in the linked Google Payments profile and, for an organization, the identity on the Dun and Bradstreet record all have to agree. Not be recognizably the same person. Agree. A missing middle name, a street abbreviated on one side and spelled out on the other, an apartment number that lives on the document but never made it into the profile, an accent dropped because a form would not take it: each of those is enough to send a document back.

The tool below is a text comparison, not an approval check and not a model of Google's review. Google publishes the requirement that the records must match; it does not publish the comparison it actually runs, how it handles abbreviations or punctuation, how it transliterates, or what else it scores. So this reads the two strings you give it and names the difference it can see. Everything it tells you is about your own text.

Profile consistency checker

What Google times, and what it leaves open

This is where competing pages invent numbers. Several of the currently ranking tutorials quote an identity review of "a few hours to two business days" or an account "usually activated within 24 to 48 hours". Neither figure appears in Google's current documentation. What Google does publish is much narrower, and much more useful, because each published figure attaches to a specific action rather than to the whole process.

Scroll the table sideways to see every column

The Android device check

This one catches a specific and growing group: developers who build on an emulator, on a company laptop, or on a device that is rooted precisely because they are the kind of person who develops Android apps. There is no desktop route. The check runs in the Play Console mobile app, on hardware.

Timing matters here in one specific way: this is a gate on making an app available, not on creating the account. You can register, verify your identity and build the app without it, then discover it at the least convenient moment. It costs a minute if you have the hardware and it costs a week if you have to find some, which is the whole argument for doing it on day one.

What a new Personal account inherits

This is the part that surprises people, and the reason it surprises them is that it works on two levels at once. Whether the rule touches you at all is decided by your account: personal, created after the cutoff. But what you actually have to do is decided by the app, because Google's wording is that you must run a closed test for your app, and the production-access application then asks about that app, the test you ran for it and its readiness. So you can build the app first, do everything correctly, pass review, and still find production unavailable, because the obligation came in with the account and has to be discharged on the app. The cutoff has been in force since November 13, 2023, which was 1,015 days ago, so unless you are working on a developer account you set up years ago, it applies to you.

How the rule got to 12

Two numbers circulate, and only one of them is current. If you are reading a page that says 20 testers, you are reading a page written before December 2024 or one that copied from it.

1. Nov 13, 2023
   The cutoff date

   Personal developer accounts created after this date fall under the testing requirements. The date is still on Google's current policy page, unchanged.

2. Late 2023
   Launched at 20 testers

   The requirement began at a minimum of 20 testers for 14 days. Google's own community documentation records the original figure, alongside contemporaneous Help Community threads. Historical

3. Dec 11, 2024
   Reduced to 12 testers

   Google announced the reduction in a Play Developer Community post titled "Reduced testing requirements for Personal developer accounts". The two-week duration stayed. Background: why Google went from 20 testers to 12.

4. Aug 13, 2026
   Current rule: 12 testers, 14 continuous days

   At least 12 testers opted in continuously for at least the last 14 days, before a qualifying Personal account can apply for production access. What that means day to day is covered in the 14 consecutive days rule.

Why the other tracks do not count

A common attempt to route around this is to use a track that is easier to fill. It does not work, and the reason is in the wording: the policy asks for a closed test specifically.

Scroll the table sideways to see every column

The full comparison of the three testing tracks, including when each is genuinely the right tool, lives in internal vs closed vs open testing. What matters at account-creation time is narrower: only the closed track clears the gate, and it takes a minimum of two weeks of real calendar time that cannot be compressed.

What an opt-out actually costs you

The widely repeated version of this rule is that a single drop below 12 breaks the window and the whole thing starts again. That is not what Google's condition says, and the difference is worth real money in wasted weeks.

The test is applied at the moment you apply: at least 12 testers must be opted in then, and each of those 12 must have been opted in for the last 14 days continuously. Google is explicit that testers who opt in, test for less than 14 days, opt out and then opt back in do not count, because the 14 days have to be consecutive. Read together, that produces three consequences most pages get wrong:

• More than 12 is a buffer, not vanity. If 15 testers qualify and one leaves, 14 still qualify and nothing is delayed. It is only when fewer than 12 can each show the full unbroken 14 days that you have to wait.
• A replacement starts from zero. The new tester does not inherit the days completed by the person who left. Their own 14 consecutive days begin the day they opt in.
• The testers who stayed keep their history. One person leaving does not reset anybody else's clock, which is the part the "it starts again" version gets most wrong.

What happens when the 14 days are up

You become eligible to apply. Google then asks you about the test you ran: how testers engaged with the app, what feedback you gathered, what you changed as a result, who the app is for and why it is ready. It is a written application with a human-shaped review behind it, not a counter that flips at midnight on day fourteen. The questions themselves, and how to answer them without padding, are covered in the production access questionnaire post.

A note on tester engagement, because this is where invented rules multiply. The measurable threshold is continuous opt-in: 12 testers, opted in, for 14 unbroken days. Google does not publish a daily-usage quota on the current policy page, and any page telling you that each tester must open the app for a set number of minutes a day is describing something Google has not written down. Engagement is assessed separately, through what you report in the application, rather than as a numeric threshold on top of the count. Verified

On where the testers come from, be careful with the confident version of this too. Google's published requirement does not prescribe one recruitment source, and its own guidance points first at personal and professional networks, naming friends, family, colleagues and classmates, then at communities where your likely users already are. That is guidance rather than a restricted list, so a legitimate testing provider is not excluded by it. What it is not is a blanket "Google does not care who your testers are": Google asks for a diverse, representative group and expects genuine engagement and feedback, and manipulating installs, ratings or reviews is a policy problem no matter how the people were found. Verified

Signup failures and how to fix them

Ten symptoms, with the documented remedy for each

The situations below are the ones Google publishes remedies for, phrased the way developers actually describe them in the Help Community rather than the way the policy pages label them. If your symptom is not here, that is worth knowing too: it usually means the answer is not documented, and the honest next step is Play Console support rather than a forum guess.

Stall router

When the answer is not on that list

There is a pattern in the 2026 Help Community threads that no fix list can solve: developers describing a verification deadlock, where the account cannot be verified and support tickets close without a substantive reply. Those reports are real and they are frequent enough to mention honestly, but they are also self-selecting, because a developer whose verification completes normally does not post about it. Nothing in this post can promise you a way out of that loop. What it can do is keep you out of the loops that have documented causes, which is the majority of them. Community reported

One last distinction worth holding onto, because it causes a whole category of misdirected panic: the identity check on your developer account is not the same thing as the separate, ecosystem-wide Android developer verification program that has its own 2026 timetable. Completing Play Console verification is what this post covers. The other program, and what it means for installs outside Google Play, is covered in the Android developer verification post.

Key 2026 requirements that can block your first release

Account creation and app requirements are separate systems, and it is easy to finish one while quietly failing the other. You can hold a perfectly verified developer account and still be unable to ship, because the build itself does not meet a current requirement. The rows below are the ones that reach a brand new account; which of them apply to you depends on what your app does.

• Aug 31, 2026
  New apps and updates must target Android 16 (API 36)

  Applies to mobile submissions, both new apps and updates to existing ones. Other form factors have their own levels. The full breakdown by device type is in the target API level post.

  7 days away
• Aug 31, 2026
  Apps using Google Play Billing must be on Billing Library 8 or later

  Google's deprecation timetable puts the new-app and update deadline for Play Billing Library 7 on this date, with an extension endpoint of November 1, 2026. It only reaches APKs that require the com.android.vending.BILLING permission, so if your first app has no in-app purchases or subscriptions it does not apply to you. If it does, this is a build dependency you want to discover now rather than at submission.

  If you monetize in-app
• Sep 30, 2026
  Play package-name registration

  Every Play package needs to be registered, but new apps created in Play Console are normally registered automatically, so this is usually a status to confirm rather than a task to do. Confirm it rather than assuming it. This is a different thing from the ecosystem-wide Android developer verification program, which is covered in the Android developer verification post.

  Usually automatic
• Nov 1, 2026
  End of the eligible extension window

  The same endpoint applies to both August 31 requirements: the target-API migration and the Play Billing Library one. Extensions are requested rather than automatic, and they are surfaced through Play Console policy status and notifications. If you are registering an account now, assume you are building to the current requirement rather than to an extension.

  If granted
• Conditional
  Contacts permissions, only if your app reads contacts

  Google's new Contacts Permissions policy governs broad access to a user's contacts for apps targeting Android 17 (API 37) and later. Both of Google's surfaces now give the same effective date, January 27, 2027: the Play Console deadline table and the Android Developers policy page agree, both re-fetched on August 14, 2026. Earlier Google communications circulated an October 28, 2026 date for this policy; that date is superseded. The full dated register is in the 2026 policy updates post. Verified

  Most apps: ignore

Those are the 2026 dates most likely to reach a brand new account, and this post deliberately stops there rather than becoming a policy calendar. It is not a claim that nothing else on the calendar can affect you: category-specific policies land throughout the year, and which of them touch your app depends entirely on what your app does. If you want the full dated register, that is what the policy updates post is for, and it is the page to check before you build rather than after.

How PrimeTestLab helps

Look back at the readiness list at the top of this post. Every row on it is something you can work through alone, on your own schedule, with one exception. The identity document, the payments profile, the codes, the device check: all solo work. Finding 12 people who will install an unfinished app, opt in with the right Google account, and stay opted in for two weeks without drifting away is not solo work, and it is the reason a two-week requirement routinely turns into a two-month one.

Doing it yourself versus handing it over

Both columns clear the same Google requirement. The difference is where the work and the risk sit. The first column is labeled honestly: only the first two rows are numbered conditions Google actually publishes. Engagement is something the production-access reviewer weighs rather than a threshold you can hit, and device diversity is good QA practice that Google encourages but does not turn into a device count you must meet.

Scroll the table sideways to see every column

We have run this test for 7,400+ apps across 120+ countries, and we have been doing it for 5+ years. Our 99.9% figure is a test-completion rate, and it is worth being exact about what that measures: the managed test held the required number of opted-in testers, unbroken, through the full 14 days. It is not an approval rate. What that buys you is a completed closed test that satisfies the requirement Google actually wrote down. It does not buy production access, and nobody can sell you that: Google reviews the application afterwards and decides on it, which is exactly why the honest version of this offer stops where it does.

If you would rather do the recruiting yourself, that is a legitimate choice and this post is not going to pretend otherwise. Seven legitimate ways to find 12 testers covers the routes that work, and whether a paid testing service is worth it is written to help you decide against buying one where that is the right answer.

Frequently asked questions

Bottom line

The 14-day test is the one part of all this that needs other people, and it is the part PrimeTestLab runs for you. See pricing plans →