支付流程进阶指南 - chuwuwang/ReadingNote GitHub Wiki
前言
本文用80%技术和20%商业解释支付流程和背后的一些事。其中有#号的观点是我没有证据,自己脑补的。其实就算比较清楚的事我也看到过很多种矛盾的说法,这里讲的只是在我个人心目中一种能自圆其说picture,不是专业人士,欢迎指正讨论
- 23/Oct更新:增加BNPL
- 23/Jul更新:简易增加return和fraud的内容
- 23/May更新:改进语言,减少缩写,提高易读性
- 23/Mar更新:增加BIN的解释,改进语言,补充退款相关内容
1. 授权流程 Authorization Flow
每一笔刷卡交易都会经过3个流程:支付授权(Authorization),清算(Clearing),和结算(Settlement)。其中授权是付款当时实时发生的,清算和结算会在之后某个时间通过batch processing总体处理。简而言之,授权是指商家从发卡行成功验证了支付信息的正确性、获得了交易许可;清算指的是所有环节的参与者都同步更新了一笔交易的信息、大家在一个公认的大帐本上确定了交易;结算指的是资金真正在不同机构之间完成了转移。
作为文章的第一个部分,我们先探讨一下支付授权的细节。这里的流程其实涵盖了多种的支付手段,包括信用卡储蓄卡礼品卡充值卡等等,也同时涵盖线上和线下交易。流程在实际的处理中千变万化,尤其是近十年的payment processing创新已经让topology相当模糊,为了简化分支方便理解,我们把讨论的重点放在open-loop的支付处理流程,主要以功能的角度看各个步骤。
上行(持卡人到发卡行)
持卡人 Card Holder / Consumer
- 通过Card-Present(CP/POS)或者Card-Not-Present(CNP)提供支付信息给商家
- 持卡人提供对应消费场景的authentication信息
商家 Merchant :
- 商家通过POS硬件或者软件/网页(POI - Point of Interaction)接受持卡人 提供的信息,通过payment application初步处理,之后把卡和交易信息发送给gateway
- Payment application根据卡的信息,在一些情况下回要求持卡人进行一些行为修正或补充,比如在线上提醒你卡号输错了,在线下的根据service code要求插芯片而不是刷磁条
支付网关 Payment Gateway / Payment Switch
- Gateway在线上和线下功能上的功能略有不同,线上指接受payment那一套服务和界面,线下指的是为商家提供分流给不同processor的软硬件,比如通过BIN把store card发给processor 1,credit card发给processor 2,debit card发给processor 3等等,这个步骤或类似的分流功能可以在很多层级和地点实现
- Gateway可能提供一些额外的管理/报告/安全服务
付款处理器 Processor / Acquirer Processor
- Processor帮助acquirer维护和商家的关系,像是个很有实权的代理人,经常提供额外的管理/报告/安全服务,可以根据商家的需求定制化一些交易处理规则,协助之后的settlement
- 收到gateway发送的request,打包商户信息发送authorization request给acquirer
- 如果有3DS(3D Secure)验证,会先把各种验证信息发送个3DS server,经过各种处理完成authentication之后继续authorization流程
- 现如今payment application/gateway/processor的功能整合度越来越高,形成了Payment Service Provider(PSP),包括Paypal/Square/Stripe,他们提供完整的服务可以大幅简化小商家收卡难度
收单行 Acquirer / Acquiring Bank
- 维护商家账户,收到processor发送的request,通过network传送给issuer,确保最后商家拿到钱
- Acquirer在流程中是很重要的一环,但是活主要都交给processor干好了,比较银行本身是很难直接维护和巨量商户的关系,对于我个人理解流程来说比较隐形
网络 Network / Association / Payment Brand
- Network是信息routing的中转站,一般的交易流程里network不直接参与交易,但是acquirer和issuer之间几乎所有实时通信都经过network。除此之外,network在后台做了很多的运营和协调工作,比如确定interchange rates,调节acquirer和issuer之间的dispute,提供交易需要的信息查询,执行规范和处罚等等
- Network也普遍提供增值服务,例如处理fraud detection,控制tokenization,提供3DS的解决方案
发卡行 Issuer / Issuing Bank
- 维护持卡人的账户,进行信息authentication和交易authorization
- 收到acquirer发的request,检查持卡人的账号里是否有足够的钱/credit,验证CVV(2)/zip/AVS等等
- 发送approval/decline的回应和其他结果经过network给acquirer和processor
下行(发卡行到持卡人)
Network / Acquirer / Processor(开始回程了,简要地说)
- Processor通过network收到issuer的回应,进一步根据自己的算法和商家的需求分析处理结果
- Processor发送最终的approval/decline结果给gateway
- 某些结果processor会batch起来,之后(传统上工作日晚上)进行clearing & settlement
- 某些结果processor会trigger其他需要I参与的处理(比如void transaction),这种情况会重新向上发request,一路走到issuer再一路走回来
Gateway / 商家 / 持卡人
- Processor发来的回应一路传回POS/gateway展示给持卡人
大家应该经常听到四方模式( Four Party Scheme)或者三方模式(Three Party Scheme),这是一种对于支付流程的简要概括,四方模式的参与者包括持卡人、发卡行、收单行、商户,又有人把network和processor包括进去称为六方模式。而三方模式的参与者包括持卡人、发卡收单行、商户,也就是说持卡人和商会对接的是同一家银行,而这间银行可以在内部联通发卡和收单服务,比如Amex和Discover。
有的时候acquirer和issuer甚至和processor可能是一家,这个时候交易处理流程基本不变。但是银行大哥一想,唉,我自己在院子里干活,为什么我要给官家交路费呢?于是同时拥有acquirer/issuer/processor的Chase地主把大门一关,然后跟全院的人说咱们明天开始关起门挣大钱。外面的人一看,唉,这院子好像挺挣钱,还有quarterly bonus,咱也加入吧。于是Amazon,Paypal,Walmart等等这些大户携家带口加入地主家。地主想要自己院子里挣钱唯一的困难可能就是和官家的谈判了,毕竟需要偶尔出门买菜进原料,不能完全得罪,于是……[编不下去了]。
2. 支付成本 Fee
手续费当然是商家很关心的点,但是跟我们持卡人有什么关系呢?之前解释的流程决定谁有《能力》进行decline,手续费决定谁有《意愿》和《责任》decline。总而言之,想多拿商家客户、多挣钱就要想办法为自己和客户降低风险并提供优质服务,谁挣钱谁就需要承担风险,谁承担风险就越会需要更细致的手续费设置来offset风险。
交易的过程里每个环节都挣了一点手续费,根据Nilson Report 2020年的数据,平均下来所有交易CC在2.2%,DC在0.7%左右,但是这些按照交易量平均的数据明显被大商家(Walmart,Amazon之类的)拉低了,绝大部分商家付的比这多得多。对于CC来说issuer挣了其中的绝大部份(75%+,然后一部分以rewards的形式返还给持卡人),processor挣了一些(15%-)。对于DC来说processor和issuer各挣了小一半。gateway/acquirer/network在所有情况下都是挣一点辛苦钱,其中network会有额外的增值附属收入。这些数字在不同情况下差异极大极大,具体组成大家可以自己查表,大体上由以下风险和服务的原因决定:
- 【Debit/Credit/Prepaid】:最基本的卡类别有不一样的费率,credit更高,debit/prepaid相差无几
- 【Network】:每个network有自己制订的interchange rate(一般是percentage rate, issuer拿)和network fee(一般是flat rate, network拿)
- 【经营类别】:根据category差异巨大,大部分category是percentage+flat,有的category使用其他的收费模式
- 【卡等级】:比如Visa Infinite还是Visa Signature,越“高贵”越贵
- 【商家体量】:大商家可以从network获得更低的费率,从processor拿到更低的markup。行业龙头(Walmart/Amazon/Costco之流)和network协商的MDR(Merchant Discount Rate)已经在0.5%以下了
- 【单笔交易额】:部分network会对每笔交易的大额小额设置不同的费率
- 【Exempt/Regulated Debit】:2010通过的Durbin Amendment对于大银行的debit费率有上限限制(0.05% + $0.21/$0.22,任何network都基本贴着这个上限),对于小银行没有限制(由network自行决定)
- 【Tokenization情况】:Network token可以降低风险提高通过率,所以可以拿到更低费率,或者也可以说是对不使用tokenization的商家惩罚性收费
- 【线上/线下】:同样是风险影响费率,非面对面交易风险更大所以更贵
- 【PIN or Signature】: DC的刷卡方式会影响走哪种network。PIN和变种PINless会走debit card network (Interlink, Maestro, STAR, etc.),signature(俗称“swipe as credit”)会走credit card network(Visa, MasterCard)。虽然直觉上debit network应该便宜一些,但是过去这些年两种network不断竞争,现在费率已经伯仲之间了
- 【Processor markup】:processor的手续费可能会直接charge给商家(interchange plus/pass through)或者摊到某种pricing model里(tiered,flat percentage rate)
- 【Foreign transaction】:外币交易就很复杂了,评论区有讨论
3. 信息交流 Data Communication
为了方便理解,我们把交易分成前半段和后半段,前半段包括持卡人->商家->gateway->processor,后半段包括processor->acquirer->network->issuer。前半段之间通信很大一部分用的是custom protocol,经常是后段行业标准(ISO 8583)的各种变种,再加上主动和客观的obfuscation,导致有的时候持卡人看到的信息并无法推断出背后发生了什么。
后半段的通信规范是network来规范化和监督执行的,理论上acquirer负责上行信息的真实和准确性,network有权利因为错误信息处罚acquirer,实际执行上商家信息大都是processor负责协调收集。在后半段上行传输的数据就是我们常说的L1/L2/L3了,级别越高数据量越大。
L1(广义上的最初级交易数据)
L1最常见,一般需要传达卡的信息、商家的信息、和基础交易信息。Network会制定哪些是mandatory和optional,会对不同行业做出不同的要求(比如航空/火车),也会对支付过程中额外的参与组织/平台加入更多的要求(比如digital wallet)。PCI DSS规范了传输和储存过程的安全和隐私性要求,但是这里为了功能性的理解就假设所有信息都是plaintext。Network希望这些信息满足规范方便acquirer和issuer处理,并且描述足够可读以避免不必要的非恶意dispute。
卡信息在CP交易中最简单就能从磁条获取,磁条一般可以存储三轨信息,其中Track 1是主要存储,包含了卡号/exp/姓名/CVV和service code;Track 2算是一个精简的备份,缺少姓名,也就是剩下的纯数字;Track 3基本没用。这些信息里唯一一个比较陌生的可能就是service code了,这个3位数字POS可以用来本地分析判断卡的使用方式是否符合要求。POS读取其中任意一个track就可以提交交易请求,它会把信息处理后一路上传,中间各个环节可以根据这些信息做出相应的处理。CNP交易会要求zip/地址进行更完善的authentication,而其中地址一般只会通过AVS算法把所有数字部分提取出来进行比对,另外CNP需要的卡上印的CVV2,这个数字和卡内存储的CVV不同,每种CVV只能在相应的CP/CNP交易里使用,但是有些交易银行不需要或者不能验证CVV(2)。
卡号里另外一个重要的信息就是BIN (Bank Identification Number),它是卡号前6-8位,很多环节都需要通过BIN提取issuer的信息进行分类处理,我常用的免费查询工具是binlist 3和binDB 2。BIN lookup不一定准确,同一个BIN在不同工具会查到不同的结果,这是因为BIN range除了一些极其基础的分配规则外(比如4开头的都是Visa,37开头的都是Amex等等)并不被严格regulate。银行可以挪用BIN到另一种产品,各个银行之间也可以交易BIN,这些改变经常导致国家和卡种的变化,也就会让一些database过时。不断更新BIN database需要很大的能力和成本,这就需要提供商通过各种奇技淫巧收集数据,高级的BIN lookup软件的高昂收费也源于此。
商家信息里比较重要的就是MCC了,它是I/P进行风险管理和提供限制服务的重要工具,用一个充足且有限的列表直观地描述风险。这里各方开始了有意思的博弈,也会因此导致有趣的事情:持卡人希望能获得好的rewards,商家希望交易finctionless地通过、不被chargeback(或者有更大的权利dispute)、并且支付低的费率,processor希望提供商家需要的服务并且符合network的规则,network希望维护内容的一致性和准确性,issuer希望得到正确的数据以满足自己提供服务/产品的需求、并且正确评估风险。
L2/L3 高阶数据
L2和L3代表商家提供更多交易信息给network的传输规范,等级越高商家提供的信息就越多,但是具体的L2/L3需要的信息内容每个network都不一样。
Visa和MasterCard总体而言对L2/L3的规范差不多,L2包括额外的总体税务信息,L3再额外包括分项的购物细节,比如商品描述、数量、单位价格等等,可以理解成“电子小票”该有的信息。商家提供额外的信息可以在商业卡交易拿到更低的费率,#而低费率的原因可能是因为network/issuer可以根据消费细节提供corporate服务(禁止购买特定种类产品,track spending category等等)从而吸引大消费的企业客户或从企业服务额外盈利。
Amex虽然我们经常叫它家的L3,但Amex其实不支持L3,它的L2(“L2+”, “L2.5”)的信息量介于V/MC的L2和L3之间,有商品清单(部分证据表明在Amex的规范里这不是mandatory,但是提供interface的服务商普遍把这定为mandatory)和邮寄地址(CNP only)。Amex的出发点不是商业卡服务,#不为商家提供interchange折扣,从表面上看只是为了额外的fraud prevention和report服务。
传输L2/L3的信息需要所有环节支持:持卡人和商家满足条件,gateway和processor能处理,network有规范和银行协调,issuer能接收。举几个限制的例子,第一是餐厅类别的商家不可以传L2/L3,第二是现阶段很多PSP都不支持L2/L3的传输。除此之外,商家也要综合考量系统升级成本、长期使用成本、商业卡的消费比例、以及信息价值,因此一般只有有大量企业客户的商家会选择支持L2/L3,比如办公用品店。除此之外,关系紧密的商家-银行直接合作也可能传递itemized detail(不确定是以L3的形式还是proprietary communication),比如Walmart给曾经的合作发卡伙伴Synchrony发itemized detail,加拿大Scotiabank主导的会员计划Scene Plus的参与菜店会给Scotiabank发itemized detail,这些本质上是因为银行切实地用数据为商家提供服务支持进而提高利润,商家才有动力分享数据。
4. 电子钱包 Digital Wallet
Digital Wallet (DW) 从我的理解分为线上线下。线上常见的就是Paypal,Apple Pay,Shop Pay这种结账可以帮你省掉输卡号地址的服务。线下是那种contactless的电子支付,主要分成NFC派和QR/barcode派。这些DW公司(尤其有线上部分的)很多时候都提供G/P服务,虽然不一定每次或每种交易都用到。
NFC线下
DW很重要的一个技术是tokenization,以Apple Pay举例,本质上是把PAN(Primary Account Number,也就是正常的卡号)替换成一个non-confidential payment token,再在每次交易中加入额外的dynamic mechanism保证token不能被复用。因为EMVCo的spec支持tokenization,所有标记这“三个扇形logo”支持contactless的POS都可以且默认支持Apple Pay,不需要前半段任何特殊处理。Token是由Token Service Provider(TSP,通常是network旗下的服务)负责生成/储存/管理,当然生成的时候要和issuer沟通验证卡信息。
当你用NFC刷Apple Pay之后,token的信息和其他的交易信息会一路传到network,之间的步骤是看不到PAN的。为了确保gateway/processor/acquirer能正确的route交易,token(特指这种TSP产生的non-format-preserving token)也有自己的BIN range,和PAN的BIN range不重叠,所以通过前6-8位可以立刻分辨一个账户号是PAN还是token,并且通过BIN可以查到一些基本信息,#不过同一个账号的PAN和token查询出来的信息可能因为技术原因不完全匹配。
当token正确的传到network的时候,network会根据token还是PAN分流,PAN的话进入之前的流程,token的话会额外的和TSP进行一轮通信以获得原始的PAN,并把这个PAN和原本的交易信息打包发给issuer。Issuer会知道交易是tokenized以便结算时正确的扣fee,也知道是哪家的DW以便正确分利,比如Apple Pay的分成就是从issuer手里拿的。
QR线下
QR派其实还分成两种,一种是DW自己的proprietary,一种是EMVCo的规范,两种的处理方式也完全不同。EMVCo的QR和contactless处理方式非常相似而且很少见就不说了,我们主要说说持卡人-presented的非EMVCo付款码,这种在中国遍地但在美国几乎只有潭友才用的支付方式。
QR派会为每次交易产生一个one-time token,常见的是10-30位纯数字(所以也可以用barcode传达),有效时间几十秒到几分钟不等。付款时商家或持卡人选择DW品牌(token没有统一规范的identificaiton number,虽然常见的几个可以区分),scanner读取这个token,然后通过gateway传输给能处理对应DW的公司。某I姓GC巨头一直都提供各种“非标”gateway服务,但是工作原理信息基本查不到,它和QR派的DW有合作,#会把token和交易信息打包给DW然后由DW的processor处理交易,处理完的信息经过正常的tokenized payment流程继续处理。回程的结果会一路返回POS,经常也会通过网络同步结果到持卡人原本展示QR的设备上。
线上
线上购物的时候会由gateway(#可能需要包括相应的processor的功能)提供DW的支持。商家在和gateway合作的时候需要注册商户信息,要么商家提供和acquirer注册商家 account时的信息,要么gateway直接或间接指派适合的MCC(s),之后每次来自这个商家的交易都使用这些MCC。每种DW支持的gateway不同,比如Square的gateway支持它自己的DW服务/Apple Pay/Google Pay,Paypal的gateway只支持它自己的DW服务,所以这时商家想要接受不同的DW就需要多个gateway。
5. 退款 Refund
取决于退钱的原因和时间点,退钱可以分为refund,void,和reversal。Void 指在authorization期间、资金真正交换之前发起的退款,它会取消原本的交易,回到交易没发生的状态,商家会在batch里删除这比交易,持卡人会看到交易在pending状态,但会在几天之后因为issuer一直没有收到这笔交易的settlement请求而消失。Reversal的目标同样是回到交易没发生的状态,但是商家/processor额外通知了issuer放弃这笔交易,持卡人账户里的pending会更快消失。通过void和reversal,商家一般不需要支付手续费,因为交易没有完整走完,所以说对于短时间内的退款商家会更愿意走这种流程。
如果交易已经开始了clearing,退钱只能通过refund的方式进行,商家这时发起一笔新的类型为refund的交易,这笔交易会完整的走完支付流程,除了把正常向issuer发送的authorization request换成反向送钱的request,最终持卡人会在几天后在账户里收到退款。Visa/MasterCard/Discover对于refund会返还商家interchange,但是Amex不会,这也就进一步增加了商家接受Amex的成本。Processor也经常通过不同的pricing plan来处理refund的手续费,比如大部分PSP(PayPal、Square、Shopify等待)都不会退还原始手续费给商家。
Refund在前半段的处理中又可分为referenced refund和non-referenced refund,这两者的区别在于refund交易有没有refer到原交易的支付信息。Referenced refund会挂一个unique identifier到原本的交易,通过原gateway退款到原支付方式,不需要持卡人手动提供卡信息。Non-referenced refund可以退款到任何持卡人在退款时提供的卡,对于商家来说这种方式return fraud的风险更大。
6. 风险管理 Frand Management
Fraud这个话题在整个支付体系里过于重要,而我知道的又太肤浅,我只能列一些有意思的点,之后有能力再整理成一个逻辑。
先说一句废话,对于商户来说,他们最想要的支付服务是:好人都通过,坏人(盗刷)都decline。然而在现实社会里,有些好人正常的支付被false decline了,之后很多好人不会选择继续尝试付款下单,商家也就损失了一单销售,在美国范围内这个损失一年超过100亿美元,是个巨大的蛋糕。另一方面,坏人也经常能够跳过风控系统盗刷成功,但这个成功率在不同环境下差别巨大。大商户比如Walmart/Amazon(以及他们的processor)能把fraud降到0.1%以下,而一般的中小型商户这个数字在0.5%左右,这不是说Amazon管理fraud的水平有多高,只是相对比比人高,然后坏人们会挑最薄弱的环节去欺负而已。
当持卡人发起chargeback之后,商家需要向issuer提供一些基本信息,进行第一轮issuer带头的“一审”。如果输了的话商家可以进行第二轮的由issuer带头的“二审”。如果再输了商家可以进行最后一轮由network带头的终审arbitration。这整个过程对商家的消耗极大,包括准备材料证据的人力时间成本,需要付给中间多个环节的手续费,甚至包括最后失败的财物两失。
因为liability的分配问题,在POS商家可能更愿意接受EMV,在CNP商家可能会加入3DS authentication,这些方式都能有效把liability转移到issuer,但是这些额外的friction也会导致conversion rate降低。同样的,那些能更好控制fraud,降低merchant liability,甚至能提高conversion rate的processor也会受到商家的青睐,即使他们收更高的费用,比如CNP的Paypal。但是这个过程其实在实际的authorization flow里是十分动态的,比如商家在最开始的authorization request里提交了所有信息,结果被issuer decline掉了,那么商家会多次不断tweak authorization request,比如不发CVV,不用tokenization等等,尽量让交易最后成功通过。但是这样的forced authorization也会导致商家承担更多的liability,这就需要商家(或者processor)在这些复杂的动态中配合恼人的规则,找到一个合适的conversion-liability平衡。
7. 先买后付 Buy Now Pay Later
先解释一下BNPL的几种模式,之后再更详细的更新。
-
商户对接的BNPL:AfterPay/Klarna/Affirm之类no interest pay-in-4服务,这可能是大家理解力最标准的BNPL。需要逐个商户进行direct merchant integration,也有一些PSP帮助对接,比如通过Square对接AfterPay。商家付极高的手续费给平台(5%~10%+),商家得到流量、销售额、和转化率提高,持卡人可以credit还款,平台挣手续费差价。
-
Network的BNPL:通过Visa/MasterCard Installments,提供给持卡人一张用来付款的信用卡信息,这样确保任何商家都可以接收。一个实现的例子是Apple Pay Later,对于本来就接收线上Apple Pay的商家来说,他们不需要做任何事情就可以接收Apple Pay Later。高盛为苹果提供傀儡卡,背后的风险和利润都是Apple扛着和高盛无关。商家付credit card interchange,但是是挺高的一个tier,持卡人debit还款,Apple挣手续费差价。
-
赔本赚吆喝的BNPL:长得像套壳钱包,商家付credit手续费,持卡人credit付款,比如Paypal Pay In 4。类似的也有zip in-store card,稍微收点手续费回本,主要还是起到扩展平台的使用范围的作用,培养用户对于第一类BNPL的长期使用习惯。
-
伪装成BNPL的loan/installment:一般会有hard pull,比如Citizens Pay或者Klarna/Affirm提供的12/24个月有息financing,本质是商家外包出去的financing服务,如今借着BNPL的东风改名字成BNPL。这种方法的term完全根据商家的需求定制,平台的盈利来自商户支付的手续费和服务费、非0的APR、以及penalty。同样的服务商家也可以反向整合进自己的产品设计和marketing里,像是Peleton和Affirm合作的长期、no interest、soft pull的BNPL在我的理解里也属于这一类,只是商家替你交了利息承担了风险,可以说没有BNPL就没有豪华家庭健身设备这个品类的兴起。
-
买完再分的BNPL:之前的类别都是购物时就得选择的BNPL,这一种是买完再说,平台提供给持卡人支付用的卡信息(credit or debit)给商家付钱,之后用户再选择性进行reroute(比如Curve,但这种已经不太算BNPL了)或者finance(比如Affirm debit)。这个模式有点迷,一方面看着像是套壳,一方面又朝着很有意思的ACH-based card product(Target RedCard的模式)方向进展,利弊我还得再想想。
-
银行的BNPL:比如My Chase Plan/Amex Plan It,持卡人正常用信用卡买东西,之后银行内部处理,以月费的名义收利息,变相的让你carry over balance。
8. 扩展阅读
大家可以多从商家的角度搜集资料。看看各种report,survey,行业数据,network的商家手册,gateway/processor的API和doc,挑出关心的部分之后对于泥潭的各位应该还是很readable的。
9. 后记
玩卡的人总是觉得世界跟你作对,可是现实中支付行业的规模导致可能人家根本不care你,至少是不target你。你觉得玩bug最有乐趣,但是可能一大半都是feature贡献的,而且是common feature。