I registered a Google Play organization account from China. Four walls nobody warns you about.

Bottom line up front: registering a Google Play organization account as a mainland China company is possible, and the fee is just $25 one time. I did it in one morning. The four things that actually cost time are all after the payment screen: how Google reads your D&B profile, how the payout account validation works, how verification steps queue against each other, and one bug in the payment partner’s system right now.

I run a small software company in Huizhou. We publish on the Microsoft Store already, and Google Play was the next shelf. Here is the log of the registration itself. No theory, just what the screens said.

Why an organization account

Two reasons, both practical.

First, personal accounts created after November 2023 must run a closed test with 12 real testers for 14 straight days before the first app ships. Organization accounts skip that wall. Second, our company already owns a D-U-N-S number from the Apple developer process, so the organization route had no extra paperwork cost for us.

The fee is $25 one time. Google’s own page says identity verification can take up to 5 days, and it warns the fee is not refundable if your information turns out invalid. The card charge went through on the spot, in USD.

Step 1: sign up with a Gmail

Google nags you that a Gmail “looks like a personal account” and suggests switching to an org email. That popup is advice, not a block. I continued with the Gmail and later set the public developer email to our company-domain address. It verified fine.

Account type choice is permanent. Organization, once, cannot be switched back to personal. Read this twice before clicking.

Step 2: the developer display name is not your company name

The first real question asks for a display name, up to 50 characters, shown on Google Play, changeable later. Mine is a brand name, not the legal name.

Before you pick, search the name on Google Play. I nearly named the store after a phrase that a very famous Chinese countdown app already owns as its English brand. That app has millions of ratings on the App Store and the trademark risk was obvious. Ten seconds of searching the store saved that mistake.

Step 3: D-U-N-S, and the surprise in the matching screen

Google asks for your 9-digit D-U-N-S number and warns you get a limited number of tries. Ours came from the Apple channel in September, after we paid a correction cycle to fix the English spelling and postcode in the D&B record.

Then came the surprise. The confirmation screen showed our record back like this:

• D-U-N-S: correct, 9 digits
• Business name: the Chinese legal name from our business license, not the English name we had just spent two weeks fixing in D&B
• Address: the Chinese address, postcode 516081, correct

The D&B record for a Chinese company turns out to be indexed on the AIC registration, which means the Chinese name is the primary key. Apple reads the English fields of that record; Google matched the Chinese field. Same company, same number, different field being compared. I checked anyway: the postcode and the district anchor in that snapshot matched what we filed, so the correction work did reach Google.

Practical note: whatever this screen shows becomes your payment profile’s legal identity. Every later document upload compares against it. Do not try to “fix” it during registration.

Step 4: the questions Google asks, and honest answers

There is a set of survey screens between payment and verification. My answers:

• Employee count: 1. D&B checks the company exists, not its size. Inflating it is the one thing that fails phone checks.
• Planned apps in 12 months: picked the 21-50 band. Honest number, because the band you declare and the pace you keep should match.
• Category declaration: “none of the above”. Do not check “designed for families” by accident. That checkbox moves your account into Google’s family-app regulatory track with extra review, and we are a tools company.
• Monetization: yes, ads and in-app purchase. Google states this answer does not gate any features.
• “Have you used other Google accounts on Play Console?” Answer factually. If your team’s second Gmail once browsed the console during research, say yes and list it. These questions exist to map your identity, and a wrong “no” costs more than the truth.

One useful field: the statement screen asks you to describe your Android and Play Console experience. I wrote four plain sentences: small company, existing web and desktop products, first time on Play, plan to publish tools. It passed. Do not write marketing.

Step 5: verification is a queue, not a checklist

After payment, the console shows three tasks: verify identity, verify organization website, verify phone number. They are not parallel.

The phone task stayed locked at first with this message: “to verify this phone number, please complete other verification tasks first.” I assumed I did something wrong. I had not. Google approves your uploaded documents first, and only then enables the phone OTP. Our identity approval came through the same morning, and the phone verification passed right after it.

Website verification offers DNS or an HTML file. The file route took two minutes: Google gives a small html file, you put it at the domain root, done. One warning from Google itself: keep the file there forever, or the verification status drops. Our old WeChat and Microsoft verify files already sit at the same domain root. Three verify files in one root, each owned by a different platform. That is the actual shape of indie infrastructure.

Step 6: the wall nobody blogs about. Getting paid.

This is where I lost the afternoon. It is solved now, but the solution is a bank trip, not an app. Here is what happened.

We use WorldFirst (万里汇) for our Microsoft Store and Kindle payouts. Both use a US dollar virtual account at a US bank (Citibank before, Chase for this one), and it works. So I assumed the same for Google. The Google payout form refused the account, and the refusal was not even about the bank details. Three facts explain it:

1. Google’s payout rule for developers (their help page, “Enter your business bank account details”): the bank account must be located in the country of your merchant registration, and paid in local currency by EFT or in USD by wire transfer. Our merchant registration country is China. So China entity means China bank. A US virtual account does not qualify, no matter who issued it.
2. The wire-transfer form for China merchants validates SWIFT codes strictly: 8 or 11 characters, and the middle two must be CN. Our US account’s code starts with a US bank code and a US country tag. “Invalid input”, both 8-character and 11-character forms rejected.
3. Payoneer is the other obvious tool, and their community guides say the same thing in plain words: mainland-registered Google accounts cannot be collected through Payoneer. That door is closed too.

Two roads lead to a compliant bank account: open a corporate USD account (现汇账户) at your own bank in China, or get the mainland-China USD virtual account a payment provider sells for Google payouts. I checked the second one first, because we already have an account with WorldFirst.

Step 7: the virtual-account workaround, and why I ruled it out

WorldFirst does sell a China-issued USD virtual account for Google Play, AdSense and AdMob. Their guide, updated 2026-09-22, says to apply through the homepage shortcut and choose Google Play, USD, opening place “mainland China”. The older entry inside developer account management only offers US/HK/SG, which is why I missed it at first.

I went to get one anyway. First the store-holder record linking license and ID, with strict name matching: the holder name must equal the company name on the platform account exactly. Then the wall. On our developer-side account, the mainland-China option never appeared. Support gave the plain answer: mainland USD accounts live in their cross-border e-commerce product line, the digital/developer account cannot switch over, and opening a fresh e-commerce account means a new phone, a new email, and re-verification of the company. And even if that door opened, their customer notice said the Google Play quota channel that auto-generates settlement quota was broken at that moment, with manual upload as the fallback.

So I picked the bank route: a corporate USD account at the company’s bank. It takes a branch visit and a stack of license documents, but the account country is CN and the SWIFT code is CN, so everything Google validates matches by construction. If you already have a corporate RMB account at a bank, that same branch can usually open the USD side in one visit.

One timing note, because it changes the cost of the whole problem. Do not let the bank account block your app launch. Money accrues to your Google balance while the account is being opened, and a free app with ads can ship before the payout profile is finished. Paid apps and in-app purchases need the complete payout profile. Open the bank account while the apps run, not before.

Step 8: after the account, two things worth minutes

First, the 15% service fee tier. New developers pay 15% on the first $1M of yearly revenue, but Google makes you enroll: it requires creating an account group in Play Console first, then accepting the tier terms. Not automatic, so go do it manually the same day.

Second, the payout profile’s public business page. Three fields matter: a customer support email (we used our company-domain one), a credit card statement name (we used the store brand name, so a buyer who checks their card statement recognizes it; that is a cheap way to reduce chargebacks), and an optional website. Leave the website empty if your public site is still a placeholder. That field can be added later from settings.

The honest scorecard

What went smooth, and what it took:

Item	Cost	Time
Registration + $25	$25 one time	about 1 hour of clicking and OTPs
Identity + phone verification	free	same day, queue-gated
Website verification (HTML file)	free	2 minutes, file must stay forever
Payout account	the real problem	bank route chosen: corporate USD account, CN SWIFT
D-U-N-S	free via Apple channel earlier	weeks, but done before this

If your D-U-N-S record is already healthy, the Google Play organization account itself is a one-morning job. The payout rails are the project. You can ship free apps while the bank account is in progress, but the verified payout method has to land eventually, and the branch visit means starting it weeks before you want to turn on paid products, not days.

One more caution, since this is how accounts die. The fee is not refundable when your information turns out invalid. Every field here should come from one master copy of your license data, typed by nobody from memory. We keep one source file and paste from it into every platform, Google included. That habit is the cheapest insurance in this business.

If you are mid-registration right now and the phone verification button is grey: wait for the document review to pass, and the button enables on its own. If the payout form calls your SWIFT code invalid: check whether it contains CN. If it does not, your account is in the wrong country, and no amount of re-typing fixes that.