支付

通知地址 即回调地址 包括支付的退款的 appID和appSecret appID和app秘钥 公钥和私钥 我们的 先要创建 在抖音平台创建 私钥自己保存好，不可泄露——自己使用，用于创建签名，请求抖

问题 退款的回调通知，验证签名失败 但是支付的回调通知，成功 代码一样，都是官方代码 在线验证签名也是失败 然后在抖音官方，在线验证签名报错：body格式错误 所以验证签名确定是报错的 一开始以为真的

流程图 创建预订单 创建预订单的时候，后端无需请求抖音接口，而是直接组装请求参数和签名返回给前端 然后，前端直接请求抖音创建预订单 这也是与一般的对接，最大的不同点 再次唤起收银台 第一次唤起收银台之

抖音平台配置回调通知地址 不同的业务，需要单独配置 比如之前担保支付已经配置 但是后面切换为通用交易支付，也需要再次配置 如果请求参数里的url覆盖了，以请求参数为准 返回数据 怎么获取返回数据？ 通

流程变了 之前担保支付，后端要请求抖音接口，创建预支付订单。现在担保支付要废弃了，需要使用通用支付。 通用支付的流程都变了，现在后端不需要请求抖音接口，只需要直接返回数据和签名即可。 前端 有2步，有

前言 今天来讲下js支付，以微信js支付为例。 支付宝，也差不多。 流程图 步骤有点多，一个阶段一个阶段的介绍 先扫码 检查码的状态 检查码的状态 检查商户的状态 这是用户第一次和支付网关通信 调用微

前言 幂等和重复支付，是两个不同的问题，必须得分开，不能混淆，才能理解清楚。 下面以扫码支付为例。 幂等 幂等的解决方案是：先查后改 + 锁。 先查后改 直接举例，第一次支付请求，订单号1并且支付成功

# 核心思想 是否超时，核心思想，肯定是比较时间差。 实际上，就是两个时间。第一个时间，是扫码的时间。第二个时间，是真正支付的时间。 # 基于token ## 方案1-手动比较时间差 此时的tok

背景 之前写了两篇文章，一篇是有独立的手续费账户，一篇是没有独立的手续费账户。 但是实际上，公司ys只有独立的手续费记账流水，但是并没有独立的手续费账户。也就是说，都是使用同一个账户。另外，细节写的也

背景 之前讲了手续费有手续费账户的情况，这次讲没有手续费账户的情况。 其实就是两种不同的架构设计。 表 订单表 金额相关字段： 1、订单金额 2、手续费 记账流水表 核心字段： 1、订单金额 2、手续

数据来源 内部 内部的意思是，交易系统计费，具体的话，是调用计费系统的计费接口计费。 外部 外部的意思是，直接来自入参。交易系统不需要计算，直接使用入参的值，因为别人已经计算好了。 有没有专门的手续费

和支付有点不一样 支付的时候，是在支付成功之后，即渠道通知支付成功的时候： 1、更新本地订单状态为成功 2、记账 先插入记账流水，后异步轮询。 3、通知商户 4、通知代付 为什么不是直接调用记账接口记

微信js支付里的签名 我们直接基于实际的应用场景讲签名，比如现在这个微信js支付，在支付的时候，微信会返回预支付id，然后会唤起密码框，用户输入密码真正支付。 怎么唤起密码框？说白了，就是调用微信接口

为什么叫js支付？ 首先这个本来是公众号支付，但是也叫js支付，为什么呢？因为微信唤起密码控件之后，用户输入密码真正支付的时候，是基于js代码，即微信app(相当于是微信浏览器)自己的js代码，你用它

反扫和非反扫最大的区别？ 1.正扫和反扫 一个是正扫，一个是反扫。 比如，js支付是正扫，就是你拿微信扫商户的二维码(即收款码)。而反扫是商家拿扫码枪扫你的微信二维码(即付款码)。 2.速度 反扫速度

流程 包含4个核心流程： 1.预授权支付 2.预授权撤销 3.预授权完成 4.预授权完成撤销 详细说明继续看下文。 预授权支付 这一步没有记账，只是把钱从消费者银行卡转账到支付公司备付金。但是，商家没

应用场景 住酒店，刚住进去的时候，付了500(包含住宿300 + 押金200)，这个是预授权支付，是先冻结。 然后退房的时候，才会真正扣款：即给商家加300，退200给消费者。本文主要讲的就是退房的时

表关系 退款订单可能包含多笔退款明细。即一对多的关系。 为什么会有多笔退款明细？ 因为业务需要，而且代码也没有禁止只能有一笔明细。 具体原因看下文。 多笔退款明细产生的原因？ 第一笔退款明细，发往渠道

流程 退款的时候，记账分两步： 先冻结 后解冻 同时扣款 退款的时候，为什么要先冻结后解冻？直接扣钱不行吗？也可以，但是退款一般分两个阶段： 先受理退款 然后真的发往渠道退款 为什么要这么做？为什么要

支付异常引起的退款 单次支付 应用场景 消费者支付了，但是渠道侧暂时没有成功，不仅仅是暂时没成功，而且是过了很长的时间仍然没有成功。 但是，一般订单是有过期时间的，如果一段时间内(比如几分钟)没有支付