Account age says nothing about the app's own history
An account with an app carries two separate timelines: when the developer account was registered, and when the app was first published and updated. They can be years apart. An old account may hold an app created last year, and a newer account may hold an app that arrived from elsewhere. So "how old is the account" only answers how long it has existed. Ask the seller for both timelines and confirm that the console supports each one.
Fields to verify in the console first
Have the seller walk through Play Console live or provide current screenshots. Look at the developer name and developer ID, the account type (personal or organization), any open policy warnings or restrictions, the package name and publishing status of each app, and the release history. The registration year can be cross-checked against the registration fee receipt, account emails and the first release record. Menu and field names change as the console is redesigned, so rely on what the page shows at the time. A seller who will only send one static image has given you too little to decide on.
Whether age helps with new apps depends on current rules
Google has added extra conditions for newer personal accounts publishing apps, such as a closed testing period with a minimum number of testers before production. Those rules have effective dates and may change. Do not read "aged account" as "free to launch new apps". If you only need to maintain and update the existing app, age matters little. If you also plan to publish new apps under this account, confirm the account type, registration date and the current help documentation before paying a premium for age.
The payments profile has to fit the account type, country and payout setup
The Google payments profile governs paid apps, in-app purchases, subscriptions, payouts and tax details. Check three things: whether the profile's country matches your target sales markets, since this is generally hard to change after creation; whether the name on the profile is consistent with the account type, so an organization account reflects organization details; and whether tax and payout information is complete and can legitimately be changed by the new owner. For a free app with no in-app charges this matters less, but the profile should still be in good standing.
What ties the app to the account decides whether you can keep shipping
What you are really buying is the ability to release the next version. Confirm the package name matches the live build. Find out whether Play App Signing is enabled, who holds the upload key, and whether a reset path exists if it is lost. Make sure source code, or at least a reproducible build project, is handed over. Check which account owns linked services such as Firebase, AdMob and API access. If these stay with the seller, you may own the account yet be unable to update or support the app properly.
Signals that mean you should stop and reassess
Pause the order if any of these hold: the seller cannot show the real console; the payments profile name or country does not fit the account type; the account has unresolved policy warnings, restrictions or removal history; the app's release record contradicts the claimed age; or nobody can say who owns the upload key, source code or linked services. The purpose of these checks is to confirm you are getting a clearly stated, usable account. Working around platform verification or review is outside what we help with.