First, a correction: Play developer accounts have no annual fee
Google Play charges a one-time registration fee, unlike the Apple Developer Program, which renews yearly. So the question of who pays the annual fee after buying an aged account usually rests on a wrong premise, probably borrowed from the Apple side. The exact amount and rules are whatever the Play Console registration page shows at the time. If a seller says the account will expire unless renewed, ask them to point to the specific notice or billing record in Console.
What can actually lapse or cost money around the account
The account itself is not billed yearly, but several things attached to it expire or carry charges. A custom-domain login email dies with its domain, and with it your recovery path. The recovery phone and backup email behind two-step verification can disappear if the number is cancelled. Linked Google Cloud, Firebase or Google Ads billing stays with whoever originally pays for it. And if apps sell paid downloads, in-app items or subscriptions, the platform service fee comes out of revenue; it is not a renewal charge. Ask who owns and pays for each of these before you order.
The payments profile is the real handover item
The Play Console payments profile holds the legal name, address, tax information and payout bank account, and all earnings settle through it. Ask three things: whose name and bank account are registered now; if nothing is set up yet, whether you can configure it first; and if it is set up, which fields can be edited and which trigger re-verification. Country or region and entity type on a payments profile generally cannot be changed freely, so check the current platform page. If the payout account is still the seller's, you can log in and still send revenue to them. Put that in writing before you pay.
Accounts with apps or revenue need extra checks
With an account that has apps, look beyond login access. Check whether apps have paid products, active subscribers and pending earnings. Changing the payments entity under active subscriptions can affect who is settled and who reports tax, and chat messages alone will not settle that. Ask the seller for screenshots or exports of the payments overview, pending balance and product setup, and state who owns revenue before and after the handover date. If you only need a clean account for a new app, one with no revenue history is cheaper to hand over and easier to verify.
Hand over in this order: verify, change, then let the seller leave
Confirm who controls the login email and recovery methods, then move them to an email and phone you control and make sure two-step verification is on your device. Next review the payments profile and tax details, changing what can be changed and deciding whether you accept what cannot. Then, in Users and permissions, confirm you hold admin rights and look for leftover users or service accounts. Only after that should the seller remove their own access. Reversing the order, with the seller leaving before payment details are fixed, makes later problems hard to trace. Make every change yourself through the normal platform flows, without relying on forwarded codes or shared devices.
Stop and reassess if you see these signs
Pause when the payments profile is tied to the seller's personal bank account and they cannot explain why it cannot change; when they will only give temporary shared logins instead of releasing the email and recovery phone; when the account has unsettled earnings or live subscriptions but no payments overview is offered; or when they insist on renewing something for you periodically without saying what. In those cases ask for more evidence or choose an account with no revenue history. Rules, fees and review states change, so rely on the platform's pages at that moment, not on what a seller tells you.