本章主要讲清楚支付系统中拒付涉及的基本概念，产品架构、系统架构，以及一些核心的流程和相关领域模型、状态机设计等。

拒付在中国比较少见，但是在海外非常普遍，只要做跨境收单支付系统，就无法绕开拒付。

拒付涉及到冻结收单单据，并扣减商户的结算款，所以拒付经常和收单、结算一起讲。下面这个图第三次出现，只是想强调三者之间的紧密关系。

三者的职能如下：

1. 收单核心：主要负责处理商户订单的全生命周期管理：订单创建、支付推进、退款、撤销等。
2. 结算核心：主要负责把商户应收账款算清楚，把结算款按合同约定结转给商户。
3. 拒付核心：主要负责处理用户的拒付和对应的抗辩以及最后的判责。

一、拒付基本概念

拒付在中国比较少见，但是在海外非常普遍，只要做跨境收单支付系统，就无法绕开拒付。

简单地说，拒付就是指用户在收到账单后，向发卡行申请对某笔交易拒绝付款。然后发卡行、卡组、收单行、第三方收单机构就开始正式进入拒付流程，中间会涉及到拒付举证、拒付判责等。

一旦拒付量大，卡组就会对收单机构的风控能力质疑，有一些惩罚措施，严重可能会影响收单资质，所以一般的收单机构对拒付率看得比较重，收单机构的风控能力也就显得尤为重要。

拒付的原因通常有以下3种：

1. 用户的卡被盗。
2. 对商品不满意并产生交易纠纷。
3. 恶意拒付。

二、拒付产品架构

拒付的业务相对比较简单，产品架构也比较简单。

三、拒付核心流程

拒付发生一般有两种来源：

1）外部渠道的清算文件，这种一般称为在线拒付。

2）外部渠道通过邮件发送给收单机构，需要由收单机构人工录入到内部系统，这种一般称为离线拒付。

拒付发生后，需要通知商家，商家一般会举证。比如证明是用户亲自签收的，或者收货地址是用户常用地址等。

不过从实际情况看，大部分的拒付会判商家或收单机构的责任。所以对收单机构的风控能力要求比较高。

四、拒付领域模型

拒付的领域模型是根据拒付处理承载的信息来设计的。首先是拒付主单，关联拒付的理由、明细、清算流水，判责等。一旦判断是商家责任，还需要记录赔付信息。

五、拒付状态机

拒付初始化为等待拒付（WAIT_JUDEG），可以被关闭（CLOSE)，如果进入判责流程，就推进到IN_JUDGE，最后判责完成后，推进到JUDGE_FINISH。

六、风控系统与拒付关系

拒付除了和收单结算紧密相关外，还和风控系统紧密相关，因为交易是由风控系统来判断风险的，如果这个用户的卡被盗刷，那风控系统的实时风控就不应该通过。如果是正常的购买，那风控系统就应该收集证据去抗辩。

这里面涉及的东西会比较多，后面有机会再讲。

七、结束语

本章主要讲了拒付的基本概念，以及对应的产品和系统架构图，一些核心的领域模型和状态机设计。

到现在为止，与商户业务强相关的收单、结算、拒付就讲完了。