海外支付：抵御信用卡欺诈的CyberSource
吴剑 2014-06-04
原创文章，转载必需注明出处：http://www.cnblogs.com/wu-jian
吴剑 http://www.cnblogs.com/wu-jian
前言
最近技术文章写的很少，不是因为不热爱技术了，而是因为随着年龄越来越大，各种压力也随之而来，无法做到像刚毕业那会儿，纯碎的学习和研究一个技术话题。
在深圳搬过很多次家，家具换了很多次，但一直没变的是大书架上的书越堆越多，有时在书架前徘徊一会儿，看着.Net Framework从1.1到了4.5、看着Web Service成了WCF、看着Javascript风起云涌......我在想，对于一个开发者来说，他不断追寻技术的最终目标到底是什么？为了一个程序诞生那一瞬间心理和身理的愉悦？为了工作为了生活为了养家糊口老婆孩子？
在中国12年算一轮回，如果前12年我在乐此不疲学习，那么后12年我希望在学习的同时能用所学干一些有意义的事情。最近在整理一些商业应用的文章，最近两年都在做海外支付，好吧，那么就从海外支付说起：
吴剑 http://www.cnblogs.com/wu-jian
概述
在欧美地区，Paypal与信用卡为两大主要在线支付方式。Paypal大家都很熟悉，而信用卡，相信做海外电商的企业在这上面都吃过苦头，因为信用卡会面临一个严峻问题：欺诈风险。
Visa 于2010年以20亿美金收购了 CyberSource 成为它的全资控股子公司。在中国大的在线支付平台背后，几乎都有CyberSource提供的反欺诈服务，如阿里的支付宝、腾讯的财富通......
<图1.CyberSource支付流程>
吴剑 http://www.cnblogs.com/wu-jian
Secure Acceptance
图1描述了CyberSource信用卡支付的完整流程（使用CyberSource支付网关，使用CyberSource Decision Manager），同时本文针对非PCI认证商家（即信用卡信息必须存在于第三方）。
OK，第一个步骤是采集用户的设备指纹，即通过一些CyberSource提供的API来唯一识别一个用户；然后通过Secure Acceptance接口向CyberSource发起信用卡的授权请求。在这个请求中包含了支付相关的所有信息，比如支付币种、金额、账单信息等等，以及如果使用CyberSource Decision Manager附带的风控所需数据。
此处，需要特别注意如下几点：
1、CyberSource会对Secure Acceptance的请求数据进行验证（如字段长度，字段特殊字符等，在API开发文档中有相关章节，但由于开发文档版本迭代频繁，此处需要测试用例的合理覆盖），如验证未通过，不会进行银行授权，直接Return一个“Request parameters are invalid or missing”至商家页面。因为未进行银行授权，所以Return回来时不会包含网关ID这个关键参数，后续也就无法进行Capture或Reversal动作。
2、如果用户的Secure Acceptance请求经过了Decision Manager，Return回来时会包含DM的决策结果，同时在DM API中会再次将决策结果通知到商家（见Decision Manager章节）。
3、Secure Acceptance的结果由CyberSource商户后台配置的URL进行回调，这里可能会存在一个中断，比如因为网络原因导致Return结果未到达商家服务器，因此后面需要一个单独的程序来定期进行查询和处理（见对中断的处理章节）。
吴剑 http://www.cnblogs.com/wu-jian
Decision Manager
CyberSource的强大之处在于它的反欺诈服务，这个服务称之为：Decision Manager。
CyberSource DM系统很容易让我联想到西蒙斯和他的文艺复兴公司（Renaissance Technologies Corp），通过大数据，通过算法，通过数学模型玩转对冲基金，收益甚至把巴菲特甩了几条街。CyberSource Decision Manager也干着类似的事情，首先它有足够大的用户交易行为数据，一旦你使用CyberSource，你也成为了它的数据源贡献者，然后它构建数学模型，对用户的行为进行分析，揪出欺诈用户，当然，最重要的是按次计费。但不可否认CyberSource在在线反欺诈领域还是赫赫有名的。
OK，看看CyberSource Decision Manager的大至工作流程：
<图2.CyberSource Decision Manager逻辑>
CyberSource Decision Manager提供一个庞大的后台，在这里面你可以配置非常多非常复杂的规则。为了清晰描述Decision Manager的工作流程，例举一个最简单自定义规则：当用户来自俄罗斯，自动拒绝交易；当用户来自美国，自动允许交易；当用户来自日本，需人工审核来决定是否允许交易。如上图所示，Decision Manager的工作流程就很清晰了。
当收到CyberSource Decision Manager结果时，代表了Authorization（银行授权）已通过，授权通过后用户信用卡里的金额会被临时冻结，此时用户如果查询会发现卡内余额减少， 因此当授权通过后应尽快进行后续动作，要么对这笔金额进行收款，即发起Capture；要么把这笔金额归还给用户，即发起Reversal。当然，如果你什么都不做，一段时间后银行会自动Reversal把冻结的款项归还给用户，只是这个时间段如果用户查询余额会觉得困惑，因为在商家网站付款未成功，而卡内余额却减少了。
需要注意的是CyberSource Decision Manager结果通知可能因为网络或其它原因中断，无法送达商家服务器，而CyberSource不会像Paypal一样会有重试机制，因此后面我们同样需要一个单独程序来定期询问CyberSource，有哪些支付在DM中已有结果而未送达商家的。
吴剑 http://www.cnblogs.com/wu-jian
对中断的处理
在图1的第6步和第7步，由CyberSource将结果发送至商家服务器，中间可能因为各种原因（如网络故障、接收程序异常）导致消息未送达。此时如果不及时处理会带来糟糕的用户体验，如果拖延时间太长，即使最后付款处理成功，也极容易导致用户的Chargeback，而Chargeback过高，收单行就会拒绝与商家的合作，所以不论何总支付方式，总会考虑处理意外中断，合作不易，与银行长期稳定的合作更不易，且行且珍惜。
<图3.授权中断处理>
Secure Acceptance可能存在结果未响应的情况（根据个人经验，实际每天都会有一定数量的交易出现该情况）。如上图所示，我们通过一个单独程序把每笔未收到结果的交易拿去CyberSource查询比对，然后按响应结果进行后续逻辑处理。需要注意的是CyberSource提供的查询API以银行授权结果为前提，当一笔交易未进行银行授权时，返回的结果类似于NULL；另外当一笔交易在DM结果为Review，并且已人工处理完成时，在此处拿到的结果仍为Review状态，如要正确处理，就需要另一个针对Decision Manager的中断处理程序。
<图4.DM中断处理>
当Decision Manager进入人工审核，同样通过商户后台配置的一个回调URL回传审核结果（见图1中的步骤7）。此处如果商户不能接收到结果，就会导致该收的款未收，该退的款未退。我们做电商，知道用户从选择商品、下单、再到支付，是一个逐渐流失的过程，每个用户到了支付环节都是来之不易的，如果在最后一步因为技术原因导致用户付款失败，实在是一件极不划算的事情。
需要注意的是CyberSource在此处提供的查询API，是针对Decision Manager中人工审核的结果，交易如果被DM中的规则自动拒绝或自动通过，是在Secure Acceptance中断程序中来处理的。如果很不幸，一笔交易在步骤6和步骤7处同时发生了中断，因为两处API分工不同，就必须保证Secure Acceptance中断处理程序先执行，DM中断处理程序后执行。
吴剑 http://www.cnblogs.com/wu-jian
后记
关于CyberSource的服务，他们的技术团队在美国，售前在香港，所以一些具体的技术问题沟通较消耗时间。接入上线后，技术沟通就只能与他们美国方面进行，很是不方便。他们中国地区的售前和风控团队还算有问必答，只是一些技术相关的细节问题，需要中转至美国，效率会偏低一点。
关于海外信用卡支付，国内也有不少公司在做，但曾经有过惨痛的教训，最终迫不得已选择了CyberSource。
关于支付的风险控制，相信每个商家都在做或计划在做，但因为没有大数据的支撑，比如一个用户第一次来你的网站支付，你无法知道他之前在别家网站是否有欺诈行为，而CyberSource有这方面数据，所以他提供收费服务。对商家来说能化繁为简，专业的事交给专业的人去做，也未偿不是件好事。
关于收单行，令人遗憾的是国内的各大银行，目前都很难在国际上得到认同，香港是一个不错的选择。
最后稍说明一下，因为涉及到交易与安全，本文并未涉及到具体技术细节，如有需要，欢迎与本人取得联系。
吴剑 http://www.cnblogs.com/wu-jian
| 如果您觉得本文对您有所帮助，可用微信扫描左侧二维码向作者捐赠。您的支持是原创的源动力！
作者：吴剑 |