先分清买的是账号，还是 App 的所有权
带 App 的账号交易，实际上有两种结构。一种是整号交接，开发者账号连同名下所有 App 一起转移；另一种是账号不动，只把某个 App 转到买家自己的账号。前者买到的是账号主体加历史包袱，后者买到的是单个应用及其用户与评价。两者要核对的东西不同：整号要看账号状态、主体信息和全部应用；单个 App 转移要看 Play Console 的应用转移功能是否适用于该应用，限制条件以平台当时的帮助文档为准。下单前先确认你要的是哪一种，否则后面所有清单都会对不上。
控制权：Owner 邮箱、两步验证与恢复方式必须一起换
登录名和密码只是表层。真正决定控制权的是几项：账号 Owner 对应的 Google 账号、该账号绑定的两步验证设备、恢复邮箱和恢复手机号，以及 Play Console 里的用户与权限列表。如果卖家仍保留恢复手段，或者还有其他成员拥有管理员权限，交接完成后原持有人依然可以重新进入。核对标准很具体：交接后只有你能完成两步验证，恢复信息全部是你控制的，权限列表里没有你不认识的账号。做不到这三条，就不算完成交接。
签名与包名：能否继续更新 App，取决于密钥在谁手里
已上架 App 的包名无法更换，更新必须使用与原版本匹配的签名。判断点是该应用是否启用了 Play App Signing。启用的话，Google 保管应用签名密钥，你只需要上传密钥，必要时可以通过平台流程重置上传密钥，风险相对低。没有启用、仍由开发者自管 keystore 的老应用，一旦拿不到原 keystore 和密码，就无法用同一签名发布更新，用户只能被迫迁移到新包名。所以要让卖家说明签名方式；自管的，要求交付 keystore、别名和密码，并在交接后立即做一次测试构建验证。拿不到就应该重新评估价格。
收款与订阅：付款资料绑定的是主体，不是 App
如果 App 有内购、订阅或付费下载，付款资料（Payments profile）、商家信息和税务信息都与账号主体绑定。这部分不能靠口头约定，需要弄清三件事：现有订阅用户的后续收入会进入哪个付款资料；未结算的历史收入归谁；变更付款资料中的名称、地址或收款账户时，平台是否会要求重新验证。所有变更都应通过平台正常流程完成，信息要与实际持有人一致。如果卖家主体与你的主体不同，并且 App 依赖订阅收入，应预留结算周期的空档，不要假设收入会无缝衔接。
关联服务：App 能不能正常运转，往往卡在 Play Console 之外
很多 App 的后端依赖并不在 Play Console 里。需要逐项确认：Firebase 项目的所有者、AdMob 账号及其关联的应用 ID、Google Ads 的应用推广关联、Play Developer API 使用的服务账号与密钥、第三方登录和推送所用的 OAuth 客户端、以及各类 SDK 的密钥与后台账号。其中任何一项仍归卖家持有，就意味着广告收入、登录或推送可能在交接后失效。建议让卖家列出依赖清单，并对每一项写明当前所有者和转移方式，无法转移的要提前确定替代方案。
交接前后的核对清单，以及应当暂停的信号
交接前，要求卖家提供账号状态截图、应用列表、各应用的签名方式、有无进行中的政策警告或申诉、是否存在未完成的版本审核。交接后，立刻做这几件事：修改 Owner 与恢复信息，清理权限列表，提交一次测试更新，确认商店资料、隐私政策链接和联系邮箱可由你修改，并核对付款资料状态。出现下列情况应暂停交易：账号存在未解决的违规或封禁记录；卖家无法证明对账号和关联服务的控制权；自管签名但交不出 keystore；要求你使用与实际持有人不一致的材料去应付验证。最后提醒，政策、验证要求和审核机制会变化，一切以平台当时的页面为准。