Handover is about control, not credentials
Receiving a login and password does not mean the account is yours. Control in Google Play Console sits in several layers: the Google account used to sign in, Owner-level permissions inside the Console, the organization details tied to the account, the payment profile, and the apps under it. If any layer stays with the previous holder, you have access rather than an account you can run independently. Decide which layers you expect to receive, and put that in writing before you order.
Confirm the account type matches the entity
Organization accounts register a legal entity name, address and contact details, and typically involve D-U-N-S based verification. Check three things: the developer name in Play Console matches the entity, the account type is organization rather than personal, and the entity details are in a usable state. If the seller cannot say which entity stands behind the account or how it was verified, pause. Verification requirements change, so treat Google's current help pages as the reference.
You need Owner rights and the ability to manage others
In Users and permissions, check that your role is Owner rather than a limited role such as app management or financial viewing. A limited role means the seller can remove you at any time and you cannot add your own team. Also review the existing user list for people or service accounts you do not recognize. A concrete test of completion: signing in with an account you control, you can invite and remove users, and the previous holder's access has been removed or its remaining purpose is explained.
Migrate sign-in email, recovery and two-step verification together
Many handover failures come from credentials, not the Console. Confirm who owns the login email, whether recovery email and phone have been replaced with ones you control, and whether two-step verification is on your device. If these still point to the seller, any security challenge gives them the final say. Where possible, moving ownership to your own Google account is safer than inheriting the original login, and each recovery path should be tested. Whether a transfer is possible and its effect on account status depend on current platform rules.
Check the payment profile before assuming it is usable
If the account has a payment or merchant profile, verify that the entity name, address and tax details match your actual operating entity and that you can lawfully change them. Payment and tax information carries real legal responsibility and should not be used when it does not match. Also ask whether payments were ever configured and whether there are unpaid fees or refunds. Changing these details may trigger re-verification, so avoid scheduling it right before a launch.
Accounts with apps need a separate ownership review
For accounts that include existing apps, add these checks: package names and app signing configuration, past rejections or policy warnings, whether the data safety form and privacy policy URL remain valid, and any dependency on the seller's third-party services, API keys or ad accounts. Account history matters more than app count; an aged account with violations may help a new release not at all. Read the policy status and app content pages in the Console rather than relying on a verbal description.
When to stop or choose another route
Pause or consider registering yourself if any of these appear: the seller will not make you Owner; the entity and verification source cannot be explained; the account has restrictions, suspensions or unresolved policy issues; you are asked to pay in full before permission details are shown; or credentials are offered without moving recovery. Any pitch built on bypassing verification, forging documents or hiding associations should be declined, as it conflicts with platform rules and leaves the account exposed. The handover is complete only when you hold an account you can manage independently and trace to a real entity.