微信订单号查询(订单号怎么查付款人)

大家好，我是讯享网，大家多多关注。

为了了解和梳理交易平台的模块和要点，我们需要从哪些方面入手？笔者从业务、风险控制、支付结算等方面进行了阐述。

我简单的把交易平台分为:

业务管理风控管理支付管理（收银台+渠道管理）结算管理

先看下订单交易付款时，短版的时机是怎样的？

业务编号:付款序列号= 1: n

这种对应关系意味着同一个业务号码可以在收银台支付多次。

例如:

a买东西用微信支付失败。该支付流水号和微信订单号失败，无法在最终状态更改，业务订单号也失败但不在最终状态；

当订单再次使用支付宝支付成功时，业务订单的状态将更改为成功和最终。

业务编号:付款序列号:渠道订单号= 1: n: n

是的。简单来说，当支付成功信息没有及时发回业务端，导致业务端再次发起支付时，这种情况下，业务端只有收到一次成功结果才会成功，第二次支付的成功结果无论是否送达都不会被记录，造成重复支付，这也是为什么在结算环节业务端和支付端会进行两次记账的原因。

那为什么业务端不改单号进行支付呢？

这个也是基于场景的，会结合固定支付限额。比如每天快车班15分钟，火车票/机票30分钟等等。，都会占用库存，而对于服装类，很少用同一个单号付款。

我们再以电子商务为例:当购物车中的商品被点击结算时，实际上会占用相应商品的库存。取消奇数意味着需要在库存被占用之前释放库存。如果业务号不变，一方面可以减少库存占用和阅读的压力，特别是对于SKU多、老化快的公司；另一方面可以通过时效性增加客户紧迫感来引导支付。

二、风控模块

目前我接触的风险控制比较少，欢迎分享相关经验。

不是所有的公司都设立风险控制部门。一般互金公司和大公司都会设立风控部门，小公司一般在it部门。在交易时，如果公司无力做风险控制，可以将风险控制的责任转移到支付渠道。风险控制也是三方渠道提供的服务之一，比如支付宝、微信，也就是说渠道自己承担交易风险。

交易风险控制一般分为三个部分:

1. 事前策略

根据《中华人民共和国网络安全法》的要求，用户获取一些信息，根据已有信息，通过策略配置、标签处理、黑白名单、常规路由等手段进行屏蔽。

2. 事中监控

交易发生时，系统根据事前策略进行规则分析，分析订单信息和用户信息，判断用户的风险系数。根据系数进行相应的拒绝、暂停、通过等操作。

3. 事后处理

事后案件最常见的来源有两个。

通常第一例风险用户未被发现当后续该用户再次交易时会把之前的用户订单拉出来比对。此时案件小组就需要进行参与人工处理，包括对应的原订单止损、现有订单拦截、案件分析结果及策略组完善规则等。当被害用户通过发卡行、媒体渠道、交易平台进行投诉，也是事后风控的处理范畴。三、支付渠道

访问和使用交易平台渠道的流程如下:

根据自己的轻重缓急选择渠道。一般接入前可以看到:渠道背景、支持的产品、开通的限额和费率、支持对账的模式、结算周期等。但近年来《银行卡收单业务管理办法》的严格实施，使得各支付公司都在拼价格、拼服务，使得支付业务朝着规范化方向快速发展。

2. 支付渠道的接入

开发通道访问时，一般分为以下两个模块:

交易模板：交易模块一般指代收、代付等。对账模块：对账一般区分为对交易、对手续费、对资金(支持资金自动结算及账户余额查询时系统可以自行核对)。3. 支付渠道的使用

通道接入完成后，就要切卷了。这时候就需要根据渠道额度、签约产品、费用等进行备份处理。，并根据您自己的路由规则配置卷。

一般在试运行2周左右需要第一份渠道试运行报告。报告内容包括:渠道成功率、结算、服务时效、错误码准确率等。结合现有的渠道评分对路由策略进行调整和优化。

四、结算管理

交易支付完成时，其实整个订单在系统中还没有完成，结算才刚刚开始。

简单来说，结算就是交易完成后的资金结算。和解的常用词如下:

1. 资金结算周期

实时结算:资金实时到账。这种结算方式一般是通过支付渠道进行预付款，所以相对费率比较高。

D+1:自然日+1日结算，通常理解为次日结算。

T+1:工作日+1日结算，节假日和周末不结算。

T+n:工作日+n天结算。

2. 结算方式

全额结算:指资金结算时不扣除手续费，手续费从另一账户结算或按一定周期独立扣除。

抵销结算:指在资金结算时，对扣除手续费后的剩余金额进行结算。

3. 对账管理

结算时通常会用到财务:账对账对账和账对账对账。

实账对账:渠道账单+渠道资金对账。对账时，你首先要确认对方记录的资金与对方给的账单一致。

对账:业务系统账单+交易系统(支付出纳)账单+渠道账单。此时，任何部分的内容出现错误都会影响对账结果。

4. 对账差异

所有对账异常订单都放入异常池，按照以下两种表现进行相应的处理:

长段落:

需要退还用户，通过调用原渠道的退款或代发接口将资金退回。需要补单，根据原订单 号进行关联单号补单处理。

短段落:

坚持谁欠钱谁需要的原则。比如渠道出了问题，渠道就要承担资金损失。错误:系统内部承诺拦截订单止损等。

其实这篇文章很多东西还可以更详细，比如路由策略，错误码管理，对账管理，对账异常池。不过我打算先建立自己的支付框架，然后再写各个功能的详细设计。所以文章看起来框架感很强，后续文章我会继续细化小节内容。

创业三年半，面临人生第一次转型和瓶颈，我们在奋力前行！

欢迎同行留言:从事支付多少年？你现在在做什么？

本文由@华山论练原创发布。大家都是产品经理，未经作者允许，禁止转载。

来自Unsplash的图像，基于CC0协议。