A screenshot proves someone took a screenshot, not that the seller owns the account
Sellers of Google Play developer accounts with apps usually offer Play Console screenshots or a screen recording as proof. Both can be captured from someone else's account, stitched together, or rebuilt from a web template. At most they show a page once existed. They do not show the account can be accessed now, that the app belongs to it, or that its standing is clean. The question to ask is not what the image shows but whether each claim can be checked against a public page or a live action.
Developer ID and package name: tie the console to the public store page
The most useful cross-check uses three fields: the developer ID in the Play Console URL, the app's package name, and the developer name and link on the public Google Play listing. Ask the seller to open the app's details live and read out the package name. Then search that package name in the store yourself and confirm the public developer matches the console account. If the package cannot be found, the developer name does not match, or the app is delisted while described as live, pause the deal. Page names and field locations change with console updates, so rely on the interface as it appears at the time.
Where fake consoles usually slip: domain, interaction and data logic
Forged consoles are typically static pages or local templates, and they tend to fail in three places. The address bar: a genuine console sits on an official Google domain with a normal secure indicator, so local files, unfamiliar domains or cropped screenshots do not count. Interaction: a real console lets you switch apps, date ranges and menus with data loading live, while a template often has only a few clickable pages and goes blank elsewhere. Data logic: installs and ratings in the console should roughly line up with what the public listing shows. These are supporting signals and do not replace the ID and package check.
Account standing is more than being able to log in
A working login says little about account health. Before ordering, ask to see policy-related messages in the inbox, the release status of the app, and whether the account is individual or organization. What matters to a buyer is whether there are warnings, whether apps were removed or restricted, and whether account and payment profile details are complete. No one can promise an account will never face future review or enforcement, so these checks only reduce the chance of a hidden existing problem. Make sure the account type also fits your intended use, for example do not accept an individual account where an organization is needed.
What makes a live check count
A useful check meets three conditions: it is live, you direct the steps, and exposure is controlled. Have the seller navigate pages in the order you name, not play a prerecorded video. You do not need, and should not ask, to see passwords, verification codes or recovery details on screen. If the seller offers only screenshots, refuses any live demo, or keeps saying the console cannot be opened casually, treat that as a signal in itself. A sound handover is transparent about who holds login, verification and recovery channels, and whether the previous holder keeps any access afterwards, all agreed before payment.
Stop conditions before you pay
Treat any of these as a reason to stop: the developer ID or package name cannot be matched to the public listing; no live demonstration is allowed; the address bar is hidden or the domain looks wrong; the account type or entity differs from what was claimed; the seller cannot explain the account history, app origin or payment profile ownership; or full payment is demanded before verification. If the checks pass, still write down whether the app transfers with the account, who holds signing keys and source code, and how payment details are handed over, then decide.