本文主要是介绍图解拒付平台：如何应对用户的拒付，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
这是《百图解码支付系统设计与实现》专栏系列文章中的第（5）篇。
本章主要讲清楚支付系统中拒付涉及的基本概念，产品架构、系统架构，以及一些核心的流程和相关领域模型、状态机设计等。
1. 前言
拒付在中国比较少见，但是在海外非常普遍，只要做跨境收单支付系统，就无法绕开拒付。
拒付涉及到冻结收单单据，并扣减商户的结算款，所以拒付经常和收单、结算一起讲。下面这个图第三次出现，只是想强调三者之间的紧密关系。
三者的职能如下：
收单核心：主要负责处理商户订单的全生命周期管理：订单创建、支付推进、退款、撤销等。
结算核心：主要负责把商户应收账款算清楚，把结算款按合同约定结转给商户。
拒付核心：主要负责处理用户的拒付和对应的抗辩以及最后的判责。
2. 拒付基本概念
拒付在中国比较少见，但是在海外非常普遍，只要做跨境收单支付系统，就无法绕开拒付。
简单地说，拒付就是指用户在收到账单后，向发卡行申请对某笔交易拒绝付款。然后发卡行、卡组、收单行、第三方收单机构就开始正式进入拒付流程，中间会涉及到拒付举证、拒付判责等。
一旦拒付量大，卡组就会对收单机构的风控能力质疑，有一些惩罚措施，严重可能会影响收单资质，所以一般的收单机构对拒付率看得比较重，收单机构的风控能力也就显得尤为重要。
拒付的原因通常有以下3种：
- 用户的卡被盗。
- 对商品不满意并产生交易纠纷。
- 恶意拒付。
3. 拒付产品架构
拒付的业务相对比较简单，产品架构也比较简单。
4. 拒付核心流程
拒付发生一般有两种来源：1）外部渠道的清算文件，这种一般称为在线拒付。2）外部渠道通过邮件发送给收单机构，需要由收单机构人工录入到内部系统，这种一般称为离线拒付。
拒付发生后，需要通知商家，商家一般会举证。比如证明是用户亲自签收的，或者收货地址是用户常用地址等。
不过从实际情况看，大部分的拒付会判商家或收单机构的责任。所以对收单机构的风控能力要求比较高。
5. 拒付领域模型
拒付的领域模型是根据拒付处理承载的信息来设计的。首先是拒付主单，关联拒付的理由、明细、清算流水，判责等。一旦判断是商家责任，还需要记录赔付信息。
6. 拒付状态机
拒付初始化为等待拒付（WAIT_JUDEG），可以被关闭（CLOSE)，如果进入判责流程，就推进到IN_JUDGE，最后判责完成后，推进到JUDGE_FINISH。
7. 风控系统与拒付关系
拒付除了和收单结算紧密相关外，还和风控系统紧密相关，因为交易是由风控系统来判断风险的，如果这个用户的卡被盗刷，那风控系统的实时风控就不应该通过。如果是正常的购买，那风控系统就应该收集证据去抗辩。
这里面涉及的东西会比较多，后面有机会再讲。
8. 结束语
本章主要讲了拒付的基本概念，以及对应的产品和系统架构图，一些核心的领域模型和状态机设计。
到现在为止，与商户业务强相关的收单、结算、拒付就讲完了，后面会进入收银支付的讲解。
这篇关于图解拒付平台：如何应对用户的拒付的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
