本文档从“支付产品技术交流群”的2017年5月24日聊天记录整理出来，感谢@雷敏 同学的整理工作。
主题分享：C端账户设计
知识点
注册登录
1、 方式：用户名、手机号、邮箱或联合登录 手机号和邮箱的一个好处是接收通知，比如用户完成重置密码等敏感操作后通知用户。 联合登录的风险，应对方式：二次校验，通过短信验证码等方式校验身份。
2、 验证码登录还是密码登录 建议后者，短信验证码的风险：因为手机信号、短信下发通道等可能延迟；因为达到日接收次数上限、停机等可能收不到。换号导致老用户无法登录，运营商二次放号后导致新用户可以登录老用户的帐号。
3、 移动时代的登录 你的微信、支付宝通过短信验证码或密码登录过几次？ 就我而言，基本不登录，支付宝都未设手势密码（本身手机就有解锁密码），都不太记得密码了，忘记了也可以找回密码。 验证身份的方式发生变化：手势密码、指纹等登录。
意义: 实名是业务的需求（比如购买理财），是风控的基础，也是符合央行对第三方支付机构的监管要求/趋势。
认证方式
1、 四要素鉴权（姓名、身份证、银行卡号、银行预留手机号） 目前微信、支付宝都是快捷绑卡后默认帮用户完成实名认证，但实际绑卡和实名是两码事。
2、 打款认证，用户体验略差且有风险。 打款认证实际只验证了姓名、银行卡号、手机号三个要素，并不能确认证件信息和操作者的对应关系。举例，填的信息是张三（操作者的）、卡号0001（操作者的）、身份证号1234（另一个张三的）、手机号（操作者的）。首先我作为操作者获取并填写验证码，验证通过后触发系统给该银行卡打款0.12元，然后我登录网银获知打款金额并提交实名，但结果实名成的另外那个张三。
3、 公安网（姓名、身份证），不算完全实名，因为只是验证证件信息的真实有效性，存在盗取身份证做实名的风险。
规则
最好一个自然人对应一个用户实名，避免投机分子薅羊毛。
绑银行卡
目前快捷绑卡是主流。
安全中心
1、不同的安全要素的安全性/被破解的概率不一样，根据操作的敏感性程度选择适当安全性的的验证身份方式。
2、身份验证，规则只是一方面，同时还有大数据等方式验证身份，如果确定是该用户，可以降低验证要求。
TIPS
研读监管层的法规，央行的监管是趋向严格，提前进行产品上的准备。
Q&A
Q1：身份验证走的什么渠道？
A1：银行提供的快捷接口
Q2：目前不是要求都要5要素验证账户么？求解答，现在需要上传证件的流程都要做么
A1：三方支付的话 目前还是四要素。五要素一般指的是账户等级、卡号、户名、身份证号码、手机号码。
Q3：卡Bin如何获取？
A1：银联每个月会免费推送一版。如何平台有维护bin好，就可以区分所属银行，发往对应的银行去做核身。
Q4：关于四要素验证，用户在柜台开的新卡，可以存款取款，但是通过支付公司做四要素验证却不通过（请求的四要素肯定是正确的），收到用户名或卡号错误，这一般是什么原因
A1：没开通快捷支付
A2：是没有开通在线支付
Q5：核身一般走啥渠道呢？
A1：银联和第三方
Q6：有对接火车票飞机票实名的么？
A1：需要发的。快捷实名的基础是信任银行，认为四要素验证通过，即可实名为该身份证对应的自然人。
Q7：是一律由银行发还是自己发呢？
A1：都有，一般是商户主动发起。
Q8：想问一下，一般绑一张银行卡就成二类实名账户了，那升级成三类账户，除了采取再多绑两张银行卡的方法，还有别的方法升级实名账户吗？
A1：一方面余额买理财其实没那么多吧，大部分人应该还是银行卡快捷支付；如果单纯为提高支付账户等级，那么考虑公安网或运营商，就是需要付费。
A2：为用户进行公安网和运营商验证，还有面对面核实
Q9：请教个问题，京东有个小金库理财金账户，那么通过银行卡充值进去的资金假如说是30万，那小金库里面的资金都可以投资理财么，那相对于小金库账户来说，假如说是三类户，这个怎么理解？
A1：20万限额那个仅针对支付账户余额，小金库户非支付账户。小金库账户属于余额账户。央行发文仅对支付账户有限制。
网友补充：基于四要素的验证基础上，有些电商平台要求上传本人手持证件照片。但是人脸识别问题也有，光线，操作都比较麻烦，如果加上时间限制更坑。关于认证，个人认为只有生物识別或间接依赖银行的强认证比较靠谱，其他的只能说是信息核对，算不上认证。
一、POS机收单
Q1：POS机收单，怎么才算一笔单子有效呢？比如：信用卡刷卡，没有打印小票或收银台显示这笔单子未确认，但用户手机已经收到扣款信息
A1：我们是按异步通知，未收到通知按第二天的对账单
Q2：但是如果这笔订单第二天清结算后，把钱退给用户了，咋办？
A1：我们只能从单子上确认这笔订单是否交易成功，但是商户那侧可能会面临损失。
A2：以小票为准，没出小票会冲正
延伸阅读：收到扣款短信，没出小票怎么办
A3：第二次交易后，也会存在没有冲正的情况，最终导致收款成功两笔，这时就需要商户第二天核实后进行退款操作
A4：冲不冲正不是关键，关键是对于收款业务冲正失败也没有风险，出现问题，肯定是以小票为依据，没有小票，可以不结款给商户
二、预付卡、优惠券
Q1：有没有用预付卡，优惠券的类似文章？
A1：预付卡和银行卡规则相同，没有类似的文章，业务逻辑相同，你就把预付卡优惠券抽象为银行卡处理
A2：优惠券一般不是单独使用的，都是与主交易搭配使用。
A3：分支付优惠券、业务优惠券。如果是跟业务强相关建议在支付之前做，若单纯是成本性质的，那样就在支付的时候去做扣减。
支付相关的优惠券有一个账户做成本，所有的优惠券生成使用都是那个虚拟账户中的资金。（网友补充：A3属于会计领域，有成本核算）
A4：券一般是定额的，满多少减多少，也有时候是商户发的，涉及到商户联盟，这个就不是成本了
Q2：优惠券的资金使用的那个虚拟账户大家是怎么使用的。有对接银行的电子账户没？
A1：优惠券如果是自己发的，其实就是一个欠条，等支付成功后，欠条才生效，结算的时候，拿自己的钱结给商户，清偿欠条。 所有清欠的欠条加起来，就是一个营销费用，这部分费用是要从自有资金账户上打到备付金账户上的。
Q3：嗯，这种是自己发的。有那种支付公司先出一部分营销费用给到商户的营销账户，商户再使用这部分费用进行发券的吗？
A1：待解答
三、第三方支付机构短款
Q1：如果第三方支付机构发给银行一笔扣款请求，银行返回扣款成功的结果给第三方支付机构，第三方支付机构由此通知发起扣款请求的商户给用户账户上账，但是后面与银行对账发现，银行这笔款实际上没有扣款成功，所以这笔钱没结算给第三方支付机构，但是第三方支付机构根据银行返回的扣款成功结果已经将这笔钱结算给了商户。这种情况大家有遇到吗？一般是怎么处理的呀？或者说如何规避这种问题？
A1：短款还是挺好规避：确保银行扣款是成功的，我们现在的做法是接收到银行的扣款成功响应后，再调用银行的查询请求确认这笔交易确实成功了再将该笔交易置为成功。
支付宝的协议和一部份银行的协议中都有明确的建议： 接受到成功响应后，再调用银行的查询接口查询该笔交易是否成功
A2：这种情况下银行应该认损的，不过要看合同。其实不用再查询了，只要有明确的报文通知其实是可以做为依据的。
A3：首先确认短款，确认后要么追偿要么认损，看具体情况不同的差错处理流程
A4：报文本身确实可以作为依据，但加入一道查询机制后一般可以减少或者规避这种情况 当然，极端情况下这种流程可能也存在短款，这个可能只有看与银行的协议了
网友补充：每笔交易都进行查询，性能会下降，在通道没有达到满负荷的情况下，性能减低<50%。有的公司为了避免短款依然会在对接的每个通道中都设这种机制。建议：与其用技术手段去弥补，不如让技术参与到合同评审。
A5：这个是系统架构设计的问题了，涉及到两种理念，一种是悲观理念，一种是乐观理念，悲观理念就是在明确成功之前，给外部系统的承诺是交易失败，最后内部处理掉，乐观理念是，在明确失败前，认为是成功的，这个会带来风险。
Q2：对接了一个国外的银行，只有页面定向的网银付款，有很大机率无法返回支付结果， 并且只能通过对方提供的查询接口查询状态，每次查询需要3-5秒钟，这个问题很头疼， 不知道有没有好的解决方案？
A1：走代理服务器，找一个连接这个银行最快的代理，我们连海外的一些通道也很慢，找代理，特别是amazon的。
A2：布专线
提问者补充：非洲应该找不到代理，我的服务器是部署在美国
A3：Amazon的aws，有免费1年的服务器，你可以申请，好几个地区，每个地区去试，看哪个地区最快。
A4：如果客户端直接提交到银行就没办法，通过自己网关提交到银行就可以做代理 自己优化网络
网友提问：布专线意义何在？
A5：我们也很多客户接专线，我觉得有可能更安全，速度更快，但为什么我不知道
A6：走专线相对稳定
A7：非洲连接欧洲快点吧，找专门做路由优化的这个好解决。美国、欧洲的都有，看起来欧洲近一点，找个最近的服务器作为代理。
提问者补充：当地也有IDC机房，但因为这些国家没有固网，全部走移动通信，所以价格贵，华为都搞不起来。
网友补充提问：这种银行可以走万事达这种第三方通道吗？
A：待补充
延展：境外本地支付技术集成商，例如：computop,相对比较全面，主要是集成本地支付通道。另外有一些拿到各区域v/m资质的 如payvision safecharge等。
四、支付系统设计
Q1：请教下公司多个业务，支付系统是分业务线进行做还是做整体的支付系统？
A1：建议整体做。不然分开后面很苦的
Q2：支付整体做的话，后期其他业务有冲突的时候改动就很麻烦，做一个抽象的好像又不实际，具体的就太限制业务，你们是怎么操作的？主要是有时候业务改动（新产品），后端通道选择或者改动其中的逻辑，有时候会冲突
A1：支付系统只做支付业务，不跟业务耦合，支付系统对外是服务化，内部是模块化
Q3：支付系统模块化，每一块独立分工，能在细说下吗？
A1：这个老熊的文章里有写过，可以去翻翻。
A2：基本上，在公司内部把支付独立处理，就相当于做一个聚合支付。
A3：系统模块化涉及的面比较多，主要是看业务切分，业务高内聚，系统构耦合
A4：系统架构上也要分层、分模块的，一般基础支付平台上 在构建业务系统，基础支付平台提供整体的支付服务，上层业务流程可以按业务行业等划分。
基础支付服务：
五、POS小票
Q1：这段话怎么理解“（银联每晚固定在11点到12点之间清算，如POS未收到反馈信号，系统将会默认此交易不成立，将会把款项退回发卡行）”？
pos收到银联的打印小票消息后，会把打印小票成功的信息再传给银联？银联以这个“打印小票成功”状态为准，作为交易成功的最后状态？
A1：POS机没出小票就是没交易成功
提问者补充：如果是这样，如果网络异常，银联会轮询查pos上的“打印小票成功”状态？
A2: 日切时间点，有3分钟左右上送的交易会失败处理，失败是不出小票的
A3：没出小票不代表交易未成功
A4：没出小票商户测是不做交易成功，银联侧如果交易成功应该做了撤销吧
A5：银行卡收单是以小票是否成功打印为基础的。若未出小票，而交易成功（后台成功），POS机具会主动发起冲正。若因网络故障、冲正交易失败，则进入其他处理流程。
一般为啥不出小票会让商户做一笔查询或者1分交易，就是为了冲正掉上一笔。当然，因为套现太多，很多通道查询余额不开放。就做一笔最低消费，带动冲正回去。
延伸阅读：银盛课堂｜pos刷卡不出小票，但客户收到扣款短信怎么办？
A6: 冲正失败，下次交易时，POS会带着上次冲正交易一并上送
Q2：这个4方（持卡人，商户，银联，银行）交易的状态是怎么翻转的？哪些地方做了异常的补偿？
A：待补充
Q3：用户通过pos机刷卡的时候，pos 小票出了，通道也告诉我们交易成功了，我们通知了业务放交易成功，可是过了一会通道测又通知我们交易冲正。但是实际上我们的业务端已经出票了。这种情况群里的小伙伴有没有相应的解决方案？
A1：尽量接1手通道，不要接N手的，因为你的支付成功是依赖于上游的。长短款很正常啊，但是好的通道几率非常低。
Q4：这个接1手怎么判断是不是1手？
A1：接通通道，拿POS做一笔交易，然后打开微信，关注银联微信号，输入查询。你就能看到神奇的东西。
Q5：只要出了小票就好办，可以不搭理，用户已经把东西拿走了，你通道告诉我冲正我，我再去抢回来？
A1：出了小票不能冲正，只能走退货退款。
A2：见了小票，通道无条件结算。退款的前提是货物你拿回来了，退款的前提是有退货
A3：这种问题就是要在对接通道时风控/运营要跟上游沟通的事情了
A4：这种问题纯技术解决不了了，只能与通道约定。
A5：这个涉及到认损的问题了，需要公司财务及高层的确认，没那么简单。 大公司都是一切以合同为准，如果合同上没有体现，需要后期走补充协议
六、交易记录查询
Q1：支付宝的全部分类的交易记录查询，涉及到10来分类型的交易记录，如果这些是分表设计的话。 分页联合查询，它是怎么做到这么快的？
A1：实现上，提供分页查询功能的库可以是一个库，它的数据都是其它业务库写成功后再回写过来的，这个库中的交易记录数据比业务库多几个代表类型的字段。
这个库可以是传统数据库，也可以是nosql，也可以干脆是缓存。
A2：感觉他们用的不是关系型数据库吧，如果用的数据库，也是按不同维度进行划分，先是按用户、商户分，也就是同一个用户的交易基本上在一个库里，分页的话应该是各自查询后，再将结果合并。
缓存成本有点高了，估计在查询前有一层预处理，能快速定位，其实一次查询的数据还是有限的，不可能全查出来吧。
A3：各自查询，再将结果合并的方案我个人觉得还是慢。查询要查每个业务库的所有时间发生记录，然后再汇总在一起重新排序分页，效率上即使第一步异步，第二步也会有效率问题
A4：不用查业务库，查询库是业务库同步过来的，排序的话，如果设计的好的话，分表本身查出来就是有顺序的
Q2：高难度的方案现在吃不消弄，同步到一个读库，这种方案在初期，考虑到各方面成本是否可行？
A1：如果只是查询的话可以用GP是一个分布式数据库。目前阿里也在用。
A2：这个分页查询，看看是不是硬实时要求或者数据准确度要求100%一致的。如果不是这种硬实时需求的，可以用索引库。分表分库在架构上仅用于线上的支付流程处理， 即按照订单号或者用户号的读写。各种条件的查询，可以将数据同步一份到Elastic 中，在Elastic上查询。elastic中保存全量数据。
A3：支付宝应该用得是类似hbase的东西
A4：是，同步到elastic， 在elastic上做查询，开发成本比在分表分库上做查询要低。
延伸阅读：elastic
Q3: elastic做各种历史数据花样查询, 分库分表，只用在当前交易的业务逻辑中:, 这当中的时间间隔是怎样？
A1: 这个就是读写分离的概念了，就是写操作是在分库分表中了，单纯的查询接口走只读就可以了，时间上我个人认为没有太严格的要求，基本上都是很快能同步就可以了。
A2: elastic相关的几个东东，我们用的简单，就日志、报表, 我们一个主，挂3个只读。
A3: 你可以从接口上去区分, 理念是一样的
Q4：elasticsearch用在什么场景？是否有个最佳时间，比如只操作1天前的历史数据的？
A1：没错，就是读写分离，专库专用。elastic主要用于不定条件的查询，底层就是以前的lucene， 很多搜索引擎就基于这个来做。优点就是可扩展性好，加机器就能上容量和上性能。 能查询多久的数据取决于这里放多久的数据。
一般是直接把线上数据异步地同步到这个库里面，这样就能支持所有数据查询。
Q5：百度 e应用场景，e可能比较适合nosql查询，之前那位兄弟说的分页，估计不适合吧？
A1：nosql和分页不冲突。
A2：es也可以做分页，做好深度查询优化即可
Q6: 除了延时是客观搞不定的，其它情况elastic能满足任何业务场景？
A1：elastic应对不了高并发场景。至于延迟，得看架构，可以控制在秒级延迟。
A2：目前flume->kafka->es能做到秒级，所以延迟的问题不大
Q7：你们分库分表怎么做的？
A1：查询分两种情况，固定条件和非固定条件。比如排行榜之类，条件是固定的，访问量又高，在es上做就不合适。我们好多数据用到分表分库，策略不同。
A2：支付中，分表分库主要是应对支付流程中的数据读写，检索不在分表分库上玩，所以实现起来就比较简单。 不需要分表分库中间件来搞。有些公司提供分表分库的jdbc封装，大部分实现是为了解决检索的问题。我们用es来规避这个事情。
Q8：你提到的es不支持高并发，你这里说的并发量大概是多少？
A1：es 系统的sharding设置，影响读写。 写的性能上去了，读的性能就下来了。 所以这个就不好说是多少。 一般情况，SSD硬盘加上大内存， 大几千的QPS是没问题的。
Q9：想了解下es的秒级延迟怎么做到的？
A1：待补充
七、CQRS和EventSourcing
Q1：各位支付系统中有用CQRS和EventSourcing吗？
A1：点融支付系统架构的演进丨ArchCon2017中国架构师大会
八、第三方充值，资金到帐问题
Q1：一个商户他有需要为其客户提供余额充值，现在他如果使用微信，支付宝通道充值，能够做到资金实时到账嘛？银行扣款成功应答能够实时告知商户？
A1：资金不实时到，应答可以实时
Q2：应答了，万一银行最后扣款失败呢？
A1：我理解支付宝应答了，说交易成功，但实际扣款成功还需要银行应答，然后支付宝把这个成功状态给改成扣款成功。是不是真正做到扣款成功实时应答的，是因为支付宝通过备付金操作。
A2：银行给支付宝成功应答，支付宝给你成功应答。银行给支付宝失败应答，支付宝也不敢给你成功应答
A3：银行给支付宝应答，这个不一定实时哈。客户说我要实时这个不可能哈，除非支付宝通过备付金内部调剂，这样能做到实时
补充：任何交易从发起到收到应答都有时间差，不可能做到真正的实时。
Q3：支付宝给商户的应答，只能在银行给支付宝应答后才产生，若银行应答不实时，支付宝如何做到充值实时显示成功的呢？毕竟支付宝只能同步应答交易成功，扣款还得看银行啥时候给应答，状态不可能变成扣款成功吧
A1：电子支付中交易和结算分离了，以前一手交钱、一手交货时，交易和结算是同时进行的。举个栗子，用户通过支付宝使用工行卡购买某电商商品，支付宝收到商家订单，将支付指令转发给工行，工行校验核身成功且卡内资金充足，实时扣减用户工行卡内资金，并返回扣款成功信息至支付宝，支付宝接收后，调增商户支付宝企业账户余额，并异步通知商户支付成功。这里面有个前提，支付宝调增商户企业账户余额，是因为相信工行T+1日一定会把资金清算到支付宝备付金账户。你看到给商户充值实时显示充值余额，只有两种情况，标准模式就是如上的信息流；或者支付宝垫资。发卡行侧失败，正常情况下支付宝也会返回失败，支付成功与否依赖于上游渠道的结果通知。
Q4：有些商户说我要用户体验，不能让用户充值后一直看的状态是充值中，商户后台看到的是待银行答复或者待银行扣款。这种情况怎么解决呢？只能让商户耐心等？
A1：上游有同步和异步的，而且有时会自动切换，没办法，只能忠实反映通道情况了。
A2：异步通知+主动查询，双保险。
九、银行退款到帐状态
Q1：银行退款，有退款到账的状态吗？微信和支付宝的退款，都会反馈一个最后到账的状态
A1：应该是以银行给的清算状态吧，我记得以前是这样的
Q2：比如用户支付是工行，收单时建行。建行退款的时候能知道工行已经到账的状态吗？
A1：我认为是不知道的，上账都是批量的，什么时候上是工行的事，建行只知道这个批次清算完了，也就是自己的钱被扣了，上没上到用户账上，不关自己的事
Q3：那这个流程是什么样的呢，在退款提交申请的时候，建行的钱就已经被扣了？还是批次清算的时候，再扣款？
A1：正常为了不短款，先扣
A2：如果是支付的话，在退款申请的时候 ，建行先把这笔账从商户账上实时下下来，清算的时候，由Cnaps从自己的备付金上扣
Q4：这种情况下，工行和建行之间，会有消息传递吗？
A1：有，失败了还会告诉你失败原因。
十、支付记录模型
Q1：看了熊先生的关于账务处理的一篇文章，其中讲到支付记录模型， 这里有一个不是很理解的地方，支付记录反应了，某人的某账户通过哪个渠道支付了多少钱到对手的某账户。 这里对于用网银充值这个业务，交易主体账户，交易对手账户，渠道账户，分别是什么？
A1：网银和快捷是一样的。主体也是发起支付的人，对手是收款人，渠道就是这个网银。
Q2：这个主体账户，是这个人的余额账户吗？还是对应这个人在本系统对应的绑定的银行卡的账户？
A1：绑定的银行卡的账户
Q3：对手的话，我们虚拟了一个平台充值商户，用这个商户的账户，这样行吗？
A1：可以。
Q4：商户账户是对应到银行存款或应收账款账户吗？
A1：是的
十一、p2p存管系统
Q1：有人了解北京银行的p2p存管系统情况吗？是不是信雅达做的？
A1：是的
Q2：P2P是存管只是要托管啊？
A1：按银监的发文，p2p是要银行存管
A2：目前基本是存管，除支付公司备付金，信托基金类产品外，大都没有明确的托管要求。托管费用太高了，但确实更合规
Q3：p2p银行存管，具体不合规在哪些地方啊？
A1：可以约束平台的资金流向
十二、spark做清算
Q1：有没有用spark做清算的朋友？
A1：我们拿mr做对账和清分。mr= mapreduce+Hadoop。Spark内存要求很高，不适用实时结算。
Q2：spark做清算有优势吗？
A1：用spark做计算，用hadoop存储
A2：用spark做计算，存储到hive/hbase上。
网友补充：现在清分我们其实也是分布式的，但是没用hadoop，各跑各的，变相分库分表，最后汇总，但是清分是单独的清分库，和交易是独立的。
Q3：那对账是否需要数据库，如记录差异、对上的数据？ 还是只需要把产生的差异记录在文件里，然后通知账务挂账？
A1：对帐不需要单独的数据库，可以共用清算库。
A2：如果对账用mr其实就是一个新库。对账有两层对账，商户对账和通道对账，商户对账直接以清分结果为依据就可以。通道对账一般是日终对，增量落就可以，没必要实时。
Q4：增量落实什么时间？
A1：定时批量
A2：我们是交易时异步同步数据到hdfs上
Q5：用mr的目的是什么？
A1：节省对账时间，hadoop基本就是定时跑批了
Q6: 异常的挂帐存哪里
A1：出现异常，输出到文件中，汇总后，灌到数据库。
A2：异常挂账要看异常原，业务系统异常甴业务系统发起，账务落账。
Q7：那挂账合适销账？ 业务系统人工排查，通过其mis后台通知账务取消挂账？
A1：先挂帐，差错处理要对挂的账进行核销。找到原因，处理了异常，就可以核销了。
Q8：若已经跨日，发现对账文件不全，是否重跑对账？
A1：跨日理论上也可以。
延伸阅读：支付系统架构
感谢您对本文的关注，如需要及时收到来自“支付产品技术交流群”的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。本文档来自“支付产品技术交流群” 的聊天记录整理，由志愿者整理并发布到本网站。文中部分链接不可用，请点击“阅读原文”查看原文详情。
