• 交易能力
  • 支付产品介绍
  • 支付能力接入准备
  • 支付产品接入
  • 生活服务行业交易系统
  • 评价能力
  • 通用交易系统
  • 支付方式开通
  • 能力介绍
  • 接入规范
  • 接入指引
  • 组件与API清单
  • 升级指南
  • 钻石兑换
  • 周期代扣
  • 常见问题
  • 广告组件
  • 线索组件配置
  • 接入前准备

      1.步骤1:完成交易能力的权限申请,路径:控制台-小程序-能力-解决方案,选择「交易类小程序通用」,依次开通各类能力权限(注:申请后自动审核通过)
      2.步骤2:等待5分钟后在此路径下配置回调地址控制台-小程序-开发-解决方案配置然后回到上一级页面点击「发布上线」
      开通能力清单
      通用交易系统OPENAPI接口能力(调用交易系统API的必需条件)
      通用交易系统退款扩展点(用于接收退款申请回调)
      通用交易系统支付消息(用于接收支付成功回调)
      通用交易系统退款消息(用于接收退款结果回调)
      通用交易系统分账消息(用于接收分账结果回调)

    关键节点

    关键节点
    说明
    商户进件
      该环节是使用交易能力的前提,进件是开通支付账户的过程
    (注:之前已接入过担保支付或行业交易系统的开发者/服务商,无需再做进件)
    交易下单
      可通过此接口,完成交易下单及支付,留存订单相关信息
    交易履约
      通用交易系统梳理了不同行业的各关键业务节点,将其映射为抽象的履约状态,同时规定了这些状态之间的流转规则
      对于需要接入履约同步的商品类型,履约状态,是平台判定退款规则和可结算时机的关键信息
    交易退款
      开发者可对接平台提供的发起退款api,用户也可以通过平台统一入口发起退款,因此均需对接回调扩展点及审核接口,接受用户多端退款请求
      若为开发者发起退款,无需商户审核,平台均会做默认同意退款处理。若为用户直接向平台发起退款,平台将判断用户申请的此笔订单目前的履约状态(通过交易履约服务同步的状态机)及交易规则定义的该履约状态下是否可退/是否需要开发者审核,来判断此笔订单的流转情况
    交易结算与分账
      对于有履约流程的交易,当履约状态到达履约完成后,可发起结算请求(或配置自动结算),结算账期详见此处
      如有分账诉求,则可通过该接口将分账列表传入。此时扣除分账的资金及平台的技术服务费后,剩余资金到商户的可提现账户
    退分账
      开发者发起分账后,如果发生退款,可以从已分账方退回分账到商户可提现账户。只支持外部分账方的退分账,不支持平台抽佣、手续费等退分账
    提现
      当开发者发起提现后,资金从「可提现账户」到商户的银行账户
    获取对账单
      开发者可定期获取平台提供的对账单进行对账

    各环节说明

    一、商户进件

    先参照:担保支付|企业版 接入指引_小程序_抖音开放平台,进件环节流程一致,api以此文档下api为准
    若已接入过担保支付,或行业交易系统, 则可跳过此“进件”环节

    二、交易下单

    2.1 开发步骤

    仅需两步:使用tt.requestOrder发起下单,再使用tt.getOrderPayment拉起收银台进行支付

    2.2 收款模式(可选阅读)

      选择一:默认收款模式
    每个小程序开通的第一个商户号(即最后一位为 0 的商户号)为小程序的默认收款商户号,开发者在调用预下单接口时无需传入收款商户号,商户系统会根据小程序 appid 默认匹配尾号为 0 的商户号进行收款
      选择二:多门店模式
    随着小程序业务发展,默认收款模式无法满足部分小程序的需求,一个小程序下的不同商品可能需要收款到不同商户号中,于是衍生出多门店收款模式
    如果有多门店收款需求,请联系客服提供小程序 appid 添加多门店白名单。加入白名单后,开发者可以在下单环节在merchantUid字段将本单要使用的商户号传入,以实现不同商品/不同订单收款到不同商户号的诉求。如果小程序 appid 不在白名单内,则无法使用多门店模式

    2.3 调用时序

      1.开发者/服务商需先调用 tt.requestOrder,下单及获取拉起收银台的相关参数,可通过查询标签组信息服务,查询可传入的标签组ID(tag_group_id)
      2.开发者/服务商调用 tt.getOrderPayment 拉起收银台,用户可在收银台上选择支付方式并确认支付,收银台上展示的支付工具与商户开通的支付方式一致。
      3.用户支付后,平台会通过支付结果回调告知开发者/服务商支付结果,但回调可能存在延迟或丢失。该笔交易付款是否成功,建议开发者/服务商的服务端以主动查询订单信息为准。

    三、履约同步

    3.1 背景说明

      1.请先参考接入规范,确认所接的商品类型是否需要接入履约,如不需要可跳过此环节
      2.通用交易系统梳理了不同行业的各关键业务节点,将其映射为抽象的履约状态,同时规定了这些状态之间的流转规则
      3.开发者需参考这套规则,使用通用交易系统提供的履约同步模式,将订单的履约状态同步给平台
    (注意:平台会根据履约状态,判断订单退款时的可退金额,以及订单的可结算时间)

    3.2 履约同步模式

        作用:拉起平台提供的服务确认组件,引导用户确认关键服务交付节点(如'履约完成'),从而驱动平台订单的状态推进
        接入:根据接入规范,查看是否需要接入、以及在哪个业务流程引入tt.confirmFullfillment
      模式二:通过履约同步openapi,由开发者同步
    作用:将履约状态同步给平台,驱动平台订单的状态推进,达到关键节点(如’履约中‘)
    接入:根据接入规范,查看是否需要接入、以及在哪个业务流程调用履约同步openapi

    3.3 调用时序

    四、交易退款

    4.1 退款入口

    具体交互可参考此处
      选择一:用户直接向开发者发起退款
    用户在小程序内,向开发者直接发起退款
      选择二:用户直接向平台发起退款
    用户可以从小程序右上角「反馈」入口,选择进入「申请退款」页面(注:抖音APP版本>=27.0.0)。退款订单列表页将根据订单所属退款规则标签与订单履约状态,判断用户是否可发起此笔订单退款,及退款是否需要开发者发起审核

    4.2 调用时序

    场景1:用户提交申请,向开发者发起退款
    注:由开发者向平台发起的退款,平台不判断订单履约状态及标签规则,均直接受理退款申请,且异步执行退款。
      开发者需调用发起退款接口,该接口会同步响应退款申请的受理结果。
    场景2: 用户提交申请,由平台直接发起退款
      用户在平台统一入口发起退款(入口见4.1描述)
      平台收到退款申请后,根据订单的履约状态及标签规则,判定是否允许退款,若不允许退款则拒绝申请
      退款申请受理后,平台将向开发者发起退款申请回调,开发者收到回调后,同步返回相关信息(若72小时后开发者仍未成功响应,系统会自动通过

    五、交易结算及之后环节

    开始开发

    查看:API列表