相关概念
- 业务 ID（bid） 为了管理第三方应用接入腾讯公益，应用侧需要事先在公益侧做好相关的配置。业务 ID 用来标识接入公益侧的应用，由公益侧提供。
- 密钥（key） 配置业务 ID 的时候同时生成，在应用侧主动查询支付订单信息时会用到。
- 支付成功通知回调链接（callback）
由应用侧提供，非必须。在公益侧支付成功后会请求该链接发送支付成功信息。
- 注意：这里是后台接收支付成功通知的链接，不是支付成功后前端跳转的链接
申请流程
按以下模板填写完整 ，再找相关负责人开通
项目id:
应用名称:
域名：（带协议）
是否需校验下单合法性：
支付结果通知回调 url ： 非必须(一般不用,只有特殊要求使用，公益后台异步通知业务接口，一般用于自己记录流水订单)
关于接入的业务流程
一个应用只能有一种接入方式，不能同时接入两种方式。 具体使用哪种接入方式，由业务侧决定；并在申请接入时，和对接人沟通和配置好。方式1：无票据接入
适用场景：引流场景，无特殊需求
- 优势：接入流程简单
- 劣势：无校验(如，可随意更改金额)，无限制(如，任何用户都可以下单)
注意：
- 回调接收不是必选项，若接入方不关心是否支付成功，可以不配置回调链接
- 无论哪种接入方式，仅支付成功后，才能收到支付成功的回调通知
需关注文档
方式2：票据验证接入
适用场景：用户需满足一定条件后才允许捐赠的场景，多用于限制用户下单,限制下单项目,限制下单金额等。 比如：某业务需要用户在项目100123下捐赠10元，才能得到这个业务发放的奖励; 此时，可以在获取下单ticket时, 指定pid为100123，money为1000。
- 优势：有校验，可以限定用户的捐款行为
- 劣势：接入流程相对复杂（每次请求都需先获取ticket，且有有效期）
需关注文档
- 小程序接入 或 H5接入
- 应用授权模式：获取下单ticket, 回调信息较少，仅告知某笔订单支付成功了；
- 用户授权模式： 获取下单ticket-用户授权版, 回调信息较多，除了告知某笔订单支付成功了，还会告知具体捐赠信息，如，金额、项目、业务类型等
- 支付通知
关于如何保证业务完整获取到捐款成功的请求
若业务无需关心用户是否捐款成功，则忽略这部分内容
有3重保证，来保证业务完整的收到所有捐款成功的请求回调，如下图
- 对于大部分业务来说，使用第1重(回调对接方式)即可，24小时内会做阶梯式回调(即不断重试)，直到业务侧响应成功
- 对于需要保证强一致性的业务，则需采用第3重(账单对齐)的方式，来保证完整性；若还有实时性要求，则对于超过一定时间（建议1分账以上，因为用户跳转过来后有很多停留和操作时间，时间太短没有意义）没有收到回调的请求，采用第2重(主动查询)进行补充
需关注文档