你以为的“三方支付”的样子，和苹果谷歌落地“三方支付”的样子，堪比网友见面、梦境与现实。
- 抽成方面：即使你使用三方支付，苹果谷歌依然要抽成，只是换了个名字叫“商店服务费”，抽成并没有便宜多少。
- 财务对账：苹果谷歌为了审计你的三方支付的抽成，你需要每月和苹果谷歌对账、打款。
- 必须接入官方内购系统：即使使用三方支付，依然必须接入官方内购系统作为可选项，与三方支付并列显示。
- 劝退弹窗：用户使用三方支付时，会被苹果谷歌弹窗警告，“你即将离开安全环境”、“苹果将不再负责该交易的安全、退款及支持”等。
下面是详细介绍。
一、抽成费率
苹果和谷歌又将“三方支付”分为“应用内三方支付”、“网页外链支付”。顾名思义，“应用内三方支付”就是在应用内使用三方支付（例如接入PayPal SDK），“网页外链支付”就是跳出应用，打开外链支付。二者抽成比例是不一样的。
苹果
在日本，苹果将原来的“佣金”拆分成了 “商店服务费” 和 固定5%的“支付处理费”。如果使用三方支付，则不用出 5%“支付处理费”，但“商店服务费”还是得出。苹果：我聪明吧。
| 方案 |
苹果收取的商店服务费 |
苹果收的支付服务费 |
苹果抽成合计 |
| 官方内购 |
21% (小型开发者或订阅 10%) |
5% |
15% ~ 26% |
| App内三方支付 |
21% (小型开发者或订阅 10%) |
0 |
10% ~ 21% |
| 网页外链支付 |
15% (小型开发者或订阅 10%) |
0 |
10% ~ 15% |
信源：Changes to iOS in Japan
谷歌
| 场景 |
Google 收取的费率 |
谷歌抽成合计 |
| 官方内购 |
30% (小型开发者或订阅 15%) |
15% ~ 30% |
| App内三方支付 |
26% (小型开发者或订阅 11%) |
11% ~ 26% |
| 网页外链支付 |
20% (小型开发者或订阅 10%) |
10% ~ 20% |
App内三方支付，4%优惠，信源：自选结算系统优惠4%、Understanding user choice billing on Google Play（文档里列出了JP）
网页外链支付，10%优惠，信源：Enrolling in the external offers program
费率小结：
三方支付，支付通道（PayPal、Stripe等）收取的通道费一般在3%左右，所以三方支付的综合成本，应该在上面再加上3%。加完后，应用内三方支付和官方内购差别极小，毫无优势。只有“网页外链支付”在抽成方面占优势，但“网页外链支付”体验很差，用户可能更倾向选官方内购，导致“网页外链支付”实际使用率低，达不到降低抽成的效果。
二、申请开通
使用三方支付（App内三方支付、网页外链支付）均需向苹果和谷歌提交申请，并签署新的协议条款。
向苹果提交申请
1、签署最新商业条款
账号持有者（Account Holder）登录 Apple Developer 官网。 在协议（Agreements）页面，找到并签署针对日本地区的最新补充协议（如 Alternative Terms Addendum for Apps in Japan）。这代表你接受苹果的新版佣金结构及月度申报制度。
2、提交在线申请表单
（1）申请入口： 访问苹果官方的权限申请表单（需登录）
（2）选择授权类型：
- 外链支付：勾选 StoreKit External Purchase Link Entitlement (Japan)。
- 第三方支付：勾选 Alternative Payment Processor Entitlement (Japan)。
（3）填写 App 详细信息：
- Bundle ID：必须是已经上架或准备在日本商店分发的 App ID。
- 支付网站域名：如果是申请外链支付，必须提供你计划链接到的顶级域名（URL 必须是 HTTPS 且归属于开发者）。
- PSP 信息：如果是第三方内购，需要填写你合作的支付服务商名称（如 Stripe, PayPay 等）。
向谷歌提交申请
申请“第三方应用内支付”（Google Play External Payments Declaration Form）
1、主体要求： 必须是以“企业/组织”名义注册的账号（个人开发者目前很难申请通过）
2、目标市场： App 必须在日本市场分发，且该功能仅对日本用户生效。
3、技术准备： App 必须集成 Play Billing Library 8.2 或更高版本。即使申请通过，不调用新版本API没办法实现。
4、谷歌官方的帮助文档页面，找到“declaration form”入口进行意向申请 (提交后，谷歌会审核开发者身份，然后后台开放配置入口)
5、如果意向申请通过，Google Play Console -> 在左侧菜单中找到 设置 (Settings) -> 外部支付计划，这个页面可以提交计划使用的外部支付网址URL，然后供谷歌审核
6、提供详细信息：
开发者账号ID：Google Play Console后台可查看的开发者账号ID
企业官方名称：必须与你申请开发者账号时提交的企业名称一致
企业注册地址：请使用注册公司所在国家/地区的官方语言输入地址
应用包名：填写要申请应用的包名，可以一次申请多个应用，但每个应用都需要符合日本分发要求。
账单寄送地址：谷歌在电子发票上显示的地址。用于财务对账和开票。
账单接收邮箱地址：谷歌会根据上报的金额按月向这个邮箱发送服务费账单
联系人邮箱：政策审核、技术问题、合规通知的接收邮箱
用户申诉的地址：一般可以是客服链接或者处理交易纠纷的邮箱地址
三、每月对账：上报三方支付流水
因为苹果和谷歌需要对三方支付抽成，所以需要按照平台要求，每月和苹果谷歌对账，提交三方支付流水。如果被发现瞒报、漏报，苹果和谷歌会采取极严厉的惩罚，包括：追缴欠款及利息；终止该权益的使用权限； 封禁开发者账号。
向苹果提交交易报告
采用 API 实时上报 + 每月财务对账” 的模式。 注意，即使做了API实时上报，也必须做每月App Store Connect的对账进行二次确认。
1、技术侧实时上报
整体流程：客户端生成 Token (StoreKit 侧) => 业务服务端 => 苹果服务器
（1）App 调用 ExternalPurchase.present() (针对外链) 或 ExternalPurchase.purchase() (针对三方支付)
（2）如果用户在系统弹窗中点击了“继续”，StoreKit 会生成一个加密的 ExternalPurchaseToken（字符串格式）。这个 Token 包含了当前用户、当前 App 以及这次点击行为的唯一标识，它是苹果后续对账的唯一凭证，每月财务对账的csv文件里也需要包含该字段。
（3）客户端将token发送给业务服务端。业务服务器需要将这个 Token 与该用户的订单/会话进行关联。如果是外链支付，可能需要暂存这个 Token，等待用户在网页端完成支付
（4）服务器收到三方支付回调（确认钱已到账）后，必须立即（或在 24 小时内）通过 External Purchase Server API 调用 Send External Purchase Report 接口。
上报内容：你需要把从客户端拿到的 Token，连同实际的交易金额（Amount）、货币类型（Currency）以及交易时间戳一起发给苹果服务器。
退款上报：如果用户后来在三方支付端发起了退款，你的服务器也需要通过 API 向苹果上报这笔退款，否则苹果依然会扣你这笔订单的佣金。
2、每月财务对账与支付
（1）在每个日历月结束后的 15天内，你需要通过 App Store Connect 提交一份详细的交易报告。申报通常是上传一个 .csv 格式的模板文件
申报填写字段：
App Apple ID,纯数字,您 App 的唯一 ID
Transaction Date,日期格式,交易发生的具体日期
PSP Name,手动输入文本,您使用的支付服务商全称
Purchase Token,字符串,技术端生成的唯一追踪标识符
Sales Amount,数字,用户实际支付的金额（需扣除交易税）
（2）即使无交易也需汇报：如果该月没有产生任何三方支付流水，您依然需要提交一份“零交易汇报（Zero Transaction Report）”
（3）提交入口：App Store Connect - “Payments and Financial Reports” (付款和财务报告) 模块 - “External Purchases” (外部购买) 选项卡
（4）上传或确认数据：系统通常会根据您通过 API 上报的数据自动预填部分信息。您需要核对并上传最终的 CSV 格式报告，确保其与您的财务记录一致。
（5）苹果会根据你申报的销售额扣除佣金，然后向你发送电子发票。你需要按照发票金额，在规定时间内通过银行转账等方式向苹果支付这笔费用。
（6）注意：为了防止偷税漏税，苹果在协议中保留了强力审计权：苹果有权雇佣第三方审计机构检查你的财务账簿。如果被发现瞒报、漏报，苹果会采取极严厉的惩罚，包括：追缴欠款及利息；终止该权益的使用权限；封禁开发者账号。
向谷歌提交交易报告
采用 "API 实时上报 + 开发者后台汇总确认" 的模式。谷歌不用每月手动上报，采用全自动上报模式，但需要核对漏报进行补报。
1、技术侧实时上报
与苹果相比，谷歌的流程更强调实时性 （24小时内） 和交易类型的精细化。
整体流程：客户端生成 Token (externalTransactionToken) => 业务服务端 => 谷歌服务器
（1）当用户在 App 内选择三方支付或点击外链，并在 Google Play 弹出的系统底页（Disclosure Sheet）点击“确认”后，Billing Library 会向你的 App 返回一个 externalTransactionToken。App 必须将此 Token 连同订单信息传给你的业务后端。它是这笔交易唯一的身份凭证。
（2）每当三方支付成功后，你必须在 24 小时内 通过服务端调用 externaltransactions API。内容：上报 Token、交易金额、货币、时间戳、税收地址（日本区对税收合规要求严格）以及交易类型。
你的服务器需要使用一个拥有 Reply to reviews 或 Manage orders 权限的 Google Cloud 服务账号 (Service Account)。
业务服务端调用上报接口
接口地址： POST https://androidpublisher.googleapis.com/androidpublisher/v3/applications/{packageName}/externalTransactions?externalTransactionId={ID}
URL参数：externalTransactionId：由你定义的唯一订单号（建议使用你数据库里的自增 ID 或 UUID）。
请求body参数：
{
"externalTransactionToken": "从客户端传来的Token",
"transactionTime": "2025-12-30T10:00:00Z",
"oneTimeTransaction": {
"fullPrice": {
"amountMicros": "1000000", // 代表 1.00 货币单位（百万分之一单位）
"currency": "JPY"
}
},
// 或者如果是订阅
// "recurringTransaction": { ... },
"userTaxAddress": {
"regionCode": "JP" // 对日本区对账极其重要
}
}
（3）异常处理：如果在 API 上报过程中出现了由于网络等原因导致的漏报，你需要在次月 5 个工作日内 通过 API 补报（补报之前的漏单）
（4）下载报告核对：你可以从 Google Play Console 的 创收 > 备选的结算系统 中导出谷歌生成的报告，将其与你自己的数据库进行核对。如果金额对不上，通常是因为你漏报了某些 API 请求。
参考资料：
创建/上报交易 (Create Transaction)
developers.google.com/android-pub…
注：在该页面左侧菜单可以看到 get 和 refund（退款）接口
备选结算系统（Alternative Billing）集成指南
developer.android.com/google/play…
此页面包含了“报告外部交易”的技术步骤说明。
2、 账单确认与支付
生成账单：谷歌会根据你 API 上报的数据，在次月生成汇总账单。
支付方式：不像苹果通常需要你主动汇款，谷歌通常会从你账户绑定的结算方式（信用卡或付款资料） 中直接扣除这部分佣金，或者发送正式账单让你在规定时间内支付。
四、严苛的“劝退式”交互
为了保护自己的生态，两大巨头在用户体验上设置了重重障碍：
内购强制接入： 苹果和谷歌均要求，开发者不能仅提供第三方支付，必须同时接入官方内购作为选项，且官方支付按钮的醒目程度必须不低于第三方支付。
劝退的风险弹窗： 用户在点击第三方支付链接时，系统会弹出充满“警告色”的通知（如：“你即将离开安全环境”、“苹果将不再负责该交易的安全、退款及支持”等），这极大地增加了用户的跳失率。
五、总结
1、并没有消失的“平台税”
先看抽成方面。
通过应用内三方支付SDK方式接入，体验较好，但抽成比例和官方支付差别很小，可以省约 1%~2% ；只有通过外链跳出App支付这种方式接入，省的比较多，可以省7%左右，但这种方式体验较差，再加上平台强制“风险警告弹窗”，即使接入了这种支付方式，最终又有多少比例的用户会选择这种支付方式呢？所以，这个7%可能需要打个大折扣。
总结起来就是，接入三方支付并不一定会“省钱”。
2、从运营成本方面看
一旦采用第三方支付，开发者需要承担原本由平台处理的大量行政工作：
每月结算申报： 开发者必须每月手动向苹果/谷歌申报通过第三方渠道产生的流水，并根据申报单向平台转账支付佣金。
自理客服与退款： 所有的退款申请、订阅管理和支付争议，平台一概不管，开发者必须建立自己的客服团队来处理这些琐事。
接受审计风险： 平台保留对开发者财务记录进行审计的权利。如果瞒报、（人员或技术疏忽导致的）漏报三方支付流水，可能面临权利被限制、下架或封号等风险。
3、过审可能变得困难
接入三方支付，会增加包体提审被拒的风险。
作为开发者，提审时需要额外在审核备注里说明接入了三方支付，并提供支付流程截图或视频。
作为审核人员，也会额外“关照”接入了三方支付的应用，检查是否符合相关审核要求。
包体层面，接入三方支付，势必会在包体里加入支付判断、支付切换，或者嵌入三方支付SDK 等高风险行为。机器审核有可能误判为切支付、隐藏功能，增加过审难度。
4、可能失去官方推荐资格
虽然苹果和谷歌官方层面没有明确表明，接入三方支付的应用不会被推荐。但从平台的角度出发，加入三方支付，很大程度上会影响被平台推荐的可能性。
苹果
官方口径： 只要符合 Guideline 3.1.1(a) 且已获得 Entitlement 授权，应用在法律上具备推荐资格。
实际：苹果的推荐位是由其编辑团队（App Store Editors）人工筛选的。他们的考核标准中，“用户体验的一致性”权重极高。三方支付必须弹出一个“离开 App”的系统警告框。对于编辑来说，这种“打断感”被视为用户体验的瑕疵。编辑团队通常倾向于推荐那些能给平台带来完整生态价值（包括 IAP 闭环）的应用。
谷歌
官方口径： 参与 User Choice Billing (UCB) 计划的应用，其推荐资格不受限制。
实际： 算法决定了你是否能进入备选池，人工决定了你是否被推荐。谷歌的自动化推荐算法（如“猜你喜欢”）基于转化率和评分。如果三方支付导致支付流程变长、跳出率增加，你的算法推荐位会自然下降。针对三方支付的退款请求，务必在 App 内提供显著的客服入口，避免用户在商店留下“无法退款，骗钱”的差评，这是算法降权的头号原因。
结语
看完上面的内容，你还会觉得“三方支付真香”吗？
而且，后续如果其它国家或地区吵着要开三方支付，大概率也会遵循上面日本的范式。
放弃幻想吧，宝子们！
登录
