本文是我12年产品经理职业生涯的复盘、抽象和归纳总结，以及依托于3年的写作经验和与大量优秀支付产品人的交流、探讨所获得的认知浓缩提炼而成很长，但，将帮助大家彻底搞明白，如何成长为一名优秀顶级的支付产品经理，看清方向，不再迷茫作为一名普通产品经理，我还算是成功的，咱不与乔布斯、张小龙去比，他们更多是CEO的角色我一直在想一个问题，为什么我会成功？为什么能成为支付专家、为什么能拿到百万年薪、为什么能把公众号做成现在这个样子？换句话说，怎么样才算一个合格的支付产品人，怎么样才算一个牛逼的支付产品人，怎么样才算一个大神级别的支付产品人有模型可以评判么，肯定是有的；只有有模型，我们才知道如何去成长，如何审视自己，迭代自己很多人问我该如何学习，该如何成长，不知道自己缺什么，不知道自己为什么这么难我将我的能力模型，进行详尽地拆解，从三个维度多个方面分析，一个成熟、合格、甚至优秀顶级的产品经理应该是什么样的，应该具备什么样的能力体系帮助大家迈向高水平、高职级、高薪酬的产品经理升级之路我们不妨先看看雷军，我想他是个不错的标杆，虽然他与我们不同，但从他身上能够看到一些影子雷军的小米性价比、su7的最漂亮轿跑，是产品的成功，雷军是个不错的产品经理，他设计出了好产品，他是懂产品的怎么聚集米粉，怎么饥饿营销，su7怎么吊足了大众的胃口，21万定价成就了雷神，雷军又是一个业务高手，他是懂业务的我想大家都听说过雷军善于找人，聚集那么多行业大牛，做手机，搞汽车；发布会那一鞠躬希望大家“轻点喷”，交付车时的开门、合影赢得了一众好感，雷军是懂得如何拿捏人们的情绪的，他是懂人情世故的我们做产品经理也是一样的就拿我来说，从初级产品经理一步步晋升到支付专家，那么做为一个产经理，肯定需要产品专业力，换句话说，一个产品经理要懂得如何设计产品，这是产品经理之本，不会设计产品，还是产品么你要懂得如何做调研，调研“市场、用户、竞品”；你要懂得如何分析需求；你要懂得如何规划你的产品架构；你要懂得如何设计可落地的产品方案；你要懂得如何传达你的方案；你要能够推动产品商用；你要具备保证产品不断地成长的能力.....但是，产品是孤立存在的么？当然不是，不寄生在业务中的产品是没有灵魂的，产品经理要懂得你的产品所支撑的“业务体系”如何运转，这是产品经理之魂，不懂业务，瞎设计你要知道你的客户是谁，才能设计适合他的产品；你要知道公司的商业如何实现，如何赚钱，你才能为公司创造价值；你要知道公司的战略，想干成什么样，你的产品才有方向，才不迷航；你要知道运营想怎么干，这样你才能知道，你如何融入其中，与之协力打配合......懂产品就能把产品设计出来，但这只是逻辑；又懂业务才能把产品设计的富有灵魂，这样才能焕发产品的活力但是，我们自己呢？我们是产品经理，但同时我们又是一名员工、一个人；员工就归命于一个组织，有领导管、有同事合作，有制度限制、有规范指引，这些要求我们具有一定的职业素养；是一个人，就意味着，我们在与人打交道，跟你的领导、跟你的同级、跟你的合作伙伴，那就要求我们懂得人情世故，懂得人性，能融入其中，这是产品经理之命，混的好，命才好如果你不懂如何向领导汇报，他怎么给你升职加薪；如果你不懂得如何掌控你的团队，他们怎么为你冲锋打漂亮仗；如果你不懂得如何和同事欢声笑语，他们怎么能更好的与你配合；如果你不能与协作部门愉快并肩拧成一股绳，你的产品蓝图要靠谁去实现，要如何才能顺畅的进展......因此，一个牛逼的支付产品经理，一个能获得职场成功的产品经理，一个能不断升值加薪的产品经理，所具备的能力一定是三合一的——懂产品，懂业务，懂人事；产品是基础，业务和人事是辅助，缺一不可模型总要有一个名字，我称之为支付产品经理的“三体支付人”模型，那么，这个模型究竟如何理解，如何指引我们不断提升自我那我的未来定位就清晰了，就是通过“支付产品知识、业务认知、职场心法”帮助大家一步步修炼升级成为“三体支付人”：懂产品、懂业务、懂人事懂“产品”，是立命之本产品经理肯定是要懂得如何做产品设计的，但是，产品不止是画原型、写文档这么低的维度，产品经理的专业能力模型是多维度组成的产品经理的能力“内容”是多维度分层的，应该分成三层：基础产品素养层、支付产品通用设计能力层、支付应用场景层最底层是基础产品经理素养这是所有类型产品经理都应该具备的，无论你是社交产品经理、电商产品经理还是支付产品经理，这部分能力是相通的，也是最基础的也是产品经理入门时必须修炼的，然后在此基础上不断衍生出各类型产品经理更个性化的能力模型，例如社交产品经理能力模型、电商产品经理能力模型、支付产品经理能力模型等经常有朋友问，怎么画流程图啊、这个需求怎么评估啊、这么多需求怎么安排优先级啊，其实就是这部分能力的缺失基础产品素养包括市场分析能力、商业模式创新能力、需求分析能力、产品规划与设计能力、数据分析能力、风险意识与管理能力、项目管理能力市场分析，是你要了解你所面对的市场，是三方支付市场、跨境市场、还是四方支付市场，还是清算市场，你要知道这个市场的特点，现状，发展趋势，市场还包括你的竞争对手、你的竞争产品，从而你才能从中发现机会，才能看到产品未来的可能性，才能对标对手、超越对手商业模式分析，就是你要知道如何赚钱，任何一款产品的最终目的是要为公司赚钱，要不赚手续费、要不赚会员费、要不赚广告费，懂商业也是产品经理的基础素养，你不仅要知道大家在这个市场里是怎么玩的，还要知道大家是怎么赚钱的需求分析，就是从业务开始向产品转化，我们要能够挖掘出用户痛点，产出能够满足市场和用户诉求的需求点，比如用户懒、你就“点外卖”；当然还要能够评估来自各方的需求，领导说要做这个、业务说要做那个、财务说我要批量审批，这些需求都需要做深度挖掘和价值评估基础中的基础是产品规划和设计能力，你要能定义你的产品，规划产品的定位、你要能制定产品的路线，控制产品节奏和版本；你要能将你的产品提炼出功能点，利用一系列的工具和方法表达出你的产品；你要具备产品设计技能，会做产品的架构设计、会画流程图、能画产品原型、会写产品文档前面的工作都做完了，接下来我们要具备能够将产品推进落地的能力，那就是项目管理能力，能开会评审、能拉着技术测试要排期、可以找各方要资源、出现进度异常和突发事件时要有办法平息，比如突然插进来一个需求，要能安排上线，要能发布产品，要能聚齐大家把产品推向市场风险意识和管理，是说我们要能预知风险和处理风险；数据分析要求我们要能事前、事中、事后，通过各方和各类数据分析产品效果和运转情况，以做下一步计划，进入下一个产品周期这是做为一名产品经理的基础技能，无论你是哪个产品方向，就像一个厨师的颠勺、放盐、调味的技能一样中间层是支付产品通用能力层我们是支付产品经理，因此在基础产品能力素养之上，我们要懂得如何设计“支付产品”你要知道如何设计交易体系，你要知道如何设计支付系统，你要知道如何设计清结算体系，你要知道如何设计账务体系，你要知道如何设计钱包，你要知道如何设计对账系统，你要知道如何搭建财税票体系......上面的这些能力中，我并没有提具体的场景，比如滴滴的账户系统怎么设计啊、跨境支付的支付系统怎么设计啊因为，我们要先具备通用的系统设计方法论，才能应对无限多的业务场景中的具体设计我们做能力建设一定要理清楚边界和职能，不要混为一谈，降低能力耦合当然如交易系统“架构”如何设计、账户系统“流程图”如何设计等这部分其实我们应该放在基础产品能力层，你懂了如何设计产品架构，也就自然懂了如何设计交易系统产品架构最上层是支付应用场景层有了产品基础素养，掌握了支付体系各系统的通用设计方法论以后，再谈各类应用场景例如不同的公司支付不同，滴滴的支付、京东的支付、美团的支付、四方支付机构的支付、三方支付机构的支付、银联网联的支付、央行的支付；同样，不同的领域支付不同，跨境的支付、消费金融的支付、教育行业的支付、航旅的支付、酒店的支付等不同的业务域那么，不同的公司和不同的领域的加入，意味着个性化进来了，公司带来的企业的意志、组织、战略，不同领域带来了这个行业的交易特点和支付监管政策因此，我们的支付应用场景层可以由2个维度决定，一个是企业种类、一个是行业领域这样我们就清晰的构建了支付产品经理完整的产品专业力模型我们要基于基础的产品经理素养能力去支撑支付产品经理通用的产品设计方法论，然后去应对繁杂多样的支付应用场景产品能力是分级递进的我们知道产品是分等级的，产品实习生、高级产品、产品专家、产品总监等，也有的是P5、P7、P9......每个级别对产品上述专业力有侧重性的要求，比如P5以下主要是能做简单的需求分析、原型绘制、文档编写就可以了；而P5、P6就应该要能够独立负责一个或多个完整系统的设计和项目推进了；P7以上开始要求产品规划和架构能力，除了更高的专业能力以外还需要具备一定的管理能力和领导力但是你不能说，我P7就不做需求分析了，不画原型了，肯定还是会做，还是会画，而且有更高的要求；同样P6也需要具备产品规划和架构能力；甚至你可以说P3都应该具备一定的规划能力，比如一个商品详情页也是需要做好规划的因此，不同级别的产品经理，在整个产品能力矩阵上要有更高的负责范围和能力要求我们将产品专业力模型和产品等级模型放到一起，就是我们的支付产品经理专业能力模型通过这张图，你可以分析一下，以自己现在的等级，在产品专业力上还有什么不足假如如果你一毕业就直接进入支付机构做产品，那么我相信你的基础产品能力素养一定是比较差的，因为这部分能力的构建，C端产品经理有天然的优势，因为更接近市场和用户那么，就应该加强自己的基础产品经理素养，不然，面对业务提过来的千奇百怪的需求，总是无从下手，手忙脚乱，不得章法懂“业务”，为产品注入灵魂业务是产品的目标，产品是业务的基石，如果我们不清楚公司当前的业务模式、运营策略和公司战略，那么我们做的产品就缺少灵魂产品一定是组织意识和价值观的集中体现如果一个遵从客户至上的企业，那么他的产品会更加关注用户利益和体验，比如京东，当然其中也要权衡商家利益和企业的价值实现就像我在面试技巧中涉及的经验复盘模型一样，任何一个产品功能点和项目经验，都应该在多个层次上完成复盘和总结，其中就包含了业务层因为产品是服务与业务的，你要阐述清楚产品的价值，就要明确业务的目标和公司的战略重点，甚至要考虑市场和竞品的因素，就像“仅退款”不止是业务问题，更多的是整个市场的趋势，拼多多搞了，淘宝搞了，你京东搞不搞，这是被竞品被行业推着走的需求对于业务的理解我们更多的从市场、客户、商业、公司战略、运营体系等去了解我们公司的业务，进而从更深层次理解我们要做的产品，如何定位、如何赋能、如何规划、如何做决策市场怎么样，我们处在一个什么样的市场，目前支付市场现状如何，都有哪些业务形态，整个行业的发展趋势怎么样，不同业态的模式有什么不同，竞争程度如何，商业规模如何我们是谁，我们是做四方支付的和是三方支付的，还是我们是一家银行，或者是一家保险公司；而作为三方支付机构，我们是做互联网支付的还是做线下收单的，是做跨境的，还是主打行业解决方案的，不同的业务形态必然有各自的交易特点和商业模式侧重客户是谁，假如做三方支付机构，我们主打的客户是谁，是跨境电商企业，是国内线上互联网支付，还是主打航司和机票代理商，不同的客户有不同的服务诉求，必然需要不同形态的产品做载体公司的商业模式，公司靠什么赚钱，商户手续费，技术服务费，增值服务，广告费，渠道分润，还是什么，这就意味着企业的立命之本在哪里，也是大家最关注的核心业务在哪里公司的战略怎么样，也就是我们想干成什么样，如果主要依靠商户手续费盈利，那么更低的通道成本，更多的商户，更高的商户手续费，利润是我们追逐的目标；如果公司主打商户增值服务，那么更多样化的商家支付和营销甚至是管理工具将成为重点方向，怎么管理资金啊，灵活用工啊，二清合规啊等等业务运营，也就是想怎么干，这也是主流需求的发源地，如何要主打渠道商地面覆盖，那么渠道商产品管理体系将有非常重要的产品诉求，如果想以降通道成本为全年主要目标，那么更高效智能的路由系统和低成本的通道将成为产品重点我们什么要这么做产品？是市场需求、是公司需要、是用户需要、是战略需要、是业务需要，因此，产品是业务诉求的集中体现只有懂业务，才能做好产品设计，任何一个产品、模块、功能点、决策都应该放到业务框架中进行思考和评估懂“人事”，才能平步青云做好产品就能有好结果么，不尽然，职场依然是个社交场，是个人情世故场怎么向领导汇报，怎么让团队斗志昂扬激情满满，怎么拒绝别人的需求，技术说没时间做不了，运营说这个需求很着急，领导说这个项目三天后必须上线，你怎么告诉兄弟部门要延期了，述职的时候大家会不会给你打高分......很多朋友说，这个最难，做不了其实，很多事都是要先懂，再谈会；人事虽难，但应该懂人情世故的认知和方法，进而慢慢学会人情世故我们从面试开始，就进入了一家公司的人情世故社交场，怎么在面试中给面试官好的印象，怎么跟HR谈薪酬，HR压职级了怎么样去争取等等进入企业以后，我们将彻底放飞自我，与领导、与下属、与同级同事、与产研测试、与业务部门、与高层、与行政人事、办理报销等等，庞大的社交人事体系，让你奔波于其中如何处理好每一层的关系，如何在每一类事务中打理好关系，权衡好各方的利益，调动和抚慰好各方的情绪，至关重要，如果没有系统的方法和实践，那么必然会捉襟见肘，疲惫逃避会混职场，才有好命，命才能长这是一个漫长的过程，但不要着急，一点点的学，一招招的学，一个场景一个场景的学，慢慢进步，总会越来越好让我们共同努力做一个“三体支付人”——懂产品，懂业务，懂人事有了方向，才知道如何做职场规划，有了标准，才能正确评估自己，知道不足，制定学习计划最后，三体支付人能力模型，懂产品、懂业务、懂人事懂产品是产品之本，根基所在；懂业务才能设计好产品，更精准，不迷航；懂人事混好职场是产品人之命，混到好不好在此一举，犹如久旱逢甘霖，犹如伯牙遇子期，犹如虎添双翼5大核心，极速达↓万字解析：交易系统核心3.5万字解析：支付系统核心万字解析：清结算核心万字解析：账户系统核心万字解析：对账系统核心陈天宇宙chentianyuzhou.com你

今晚20:00我会在视频号，解读这篇文章，如果阅读文章的过程中存在一些疑问，可以来视频号一起“唠唠”！不见不散账户是根据会计科目设置的，具有一定格式和结构，用于反映会计要素的增减变动情况及其结果的载体，而账户

全文共12056个字，建议先收藏慢慢看今晚20:00我会在视频号，给大家解读这篇文章，如果阅读文章的过程中存在一些疑问，可以来视频号一起“唠唠”！不见不散账目核算是财务工作的必要部分，随着线上交易体量越来越大或者说对财务自动化线上化的效率提升需求越来越高，为了提升核对效率以及准确性，要将核对业务系统化、线上化、自动化。如何构建设计一套不同业务场景下的对账系统是本文的重点。1.对账概述日常生活中每天都在对账，比如去餐馆吃饭付款，会对老板说一声“老板，钱付过去了”，老板检查收款情况或者听到语音播报后回复一声“好嘞，下次再来”，这就是一次最简单的对账。再比如在淘宝开了一个店铺，每个月几千单的交易、发货；次月末都拿着所有的订单明细和支付宝收款记录逐笔做一次核对，保证发过货的订单都收到款了，这是一次更复杂的核对。1.1对账的定义对账就是“账证实”的核对，“账”是账目，“证”是凭证，“实”是实际资金或者商品。常见的核对模式有三种：账证核对、账账核对、账实核对，确保账证实两两的一致性。如在饭馆吃了一碗面，其中点菜单就是原始凭“证”，付了10元钱是“账”，老板电脑记录10元是“账”，老板看到账户中余额增加了10元是“实”。从财务范畴来看，证就是会计凭证，比如发票、小票、出货单、收据、交易系统的支付记录等都是原始凭证；而账呢就是财务的账目，账务系统的账务记账，金蝶的科目余额等都是不同的账目；而一笔交易会记录在很多的环节，比如账务系统，金蝶等。

相比V6.0新增了14篇文章，新增内容标题后已做标注精选长文百万年薪，我做对了这8件事一文搞懂“支付·清结算·账务”全局我的“支付内核”，浓缩成了46张图支付人，3大底层能力一文搞懂“支付系统”v7.0新增宇宙杂谈产品经理靠种地，年入百万？从年薪10万到100万北漂十年，漫长岁月里的生命色彩阳了高血压遇上新冠，一定要认真对待你也可以像我一样写作嫡系最近“怎么了”我去见了一个人宇宙·支付产品交流群这把火，席卷支付圈三方支付专属群，开群咯通识产品能力3条基础思维，成为支付大师v7.0新增第一部分：支付基础理论基础入门3万字“十看支付”：开启支付之门一文搞懂62个支付名词早餐里的支付故事混合支付系统的排队模型一笔跨行转账的秘密支付的时空观“交易-清算-结算”支付体系的四个基本概念详解支付产品23个支付思维4个支付架构，61个支付名词支付全局观一张小票看透支付清结算架构（上）一张小票看透清结算（下）搭建“三界支付清算体系”掌握支付全局思维一张图，开启“上帝视角”39张支付经典这笔支付，“网联”和“银联”同时参与！上帝视角看支付，总架构解析这张架构图的2.0版本来了一文搞懂“支付·清结算·账务”全局我的“支付内核”，浓缩成了46张图支付工具支付工具让支付更高效信息流资金流“信息流”和“资金流”分析方法支付流订单专题订单系统设计方法交易专题交易系统设计方法玩转“逆向交易”“交易和支付”有啥区别？一文搞懂“交易层”计价计费18个清算计费模型物流“计价“系统设计消金的“计费系统”设计收银台专题收银台设计方法收银台前后端交互流程线下游乐“收银台”设计5个“收银台”设计案例“收银台”设计方法论另类“收银台”这一招，让收银台“骚”起来v7.0新增支付系统一文搞懂“支付系统”v7.0新增1张架构图，开启“高维”支付思维v7.0新增退款这么做，就没有退不回去的钱v7.0新增退转付，流程图解析v7.0新增一张图，搞懂“支付核心”v7.0新增3张图，搞懂“支付核心”4大处理流程v7.0新增一文搞懂“订单、账单、支付单”关系v7.0新增路由专题路由系统设计方法路由架构解析展示路由设计方法浅谈路由规则一文，讲透“20条路由规则”v7.0新增网关专题支付网关的限流原理你好，支付网关支付网关与路由详解渠道专题“支付通道”接入和管理支付通道及系统设计通道管理系统详解万字解析“通道系统设计”风控专题清结算专题“诈金花”中的清算思维工资结算可以这么做“三层式”清结算中台清结算体系设计“世界杯”的清结算模型汪小菲晒的账单你看懂了么？7个结算系统设计案例“高速ETC”结算系统详解“消费金融”的结算系统设计消金“结算系统”设计解析一个“牛逼”的清结算系统全国大清算系统，共产主义下分配模型8类结算业务，5个结算模式账户系统专题账户系统设计从入门到精通账户系统设计【拓展篇】支付产品必懂的会计基础（上）让“热点账户”清凉一夏从“账”上解决支付问题这几个财务知识帮我了大忙“账户合并”这么做，必升值加薪！如此认识和理解“账户”账务核心设计方法5个账户设计案例8个账户设计案例三户模型一文搞懂“账户系统”“账”剑走天涯一张压箱底的“账户架构图”钱包专题8个“钱包”设计案例银行电子钱包解析钱包“高阶”玩法一文搞懂“红包和钱包”对账专题银行存款余额调节对账表系统一个“地狱级账单”的解析模型“坑位解析器”的配置模型一文搞懂“对账系统”资金合规“资金合规”的产品设计方法二清资金监管户账务处理实例归集调拨专题调拨系统设计方法论线下支付专题资金线下汇入系统设计方法论支付方法论支付方法论支付的“三字真经”支付金字塔通过这个项目学会产品的“故事分析法”如何主导一个大型的结算线上化项目1点3线把握支付架构账户迁移的“兼平切”方法论支付《32真经》，Plus版我的“3端4层”设计法支付《32真经》，传你10年功力一个方法论，搞懂支付的一切天地人神，支付人一“招”搞定所有“需求”伟大的设计模式支付人，3大底层能力我的很多模型，都是这么得到的“311型”清结算架构模型

前一段发表了一篇退转付的文章《退款这么做，就没有退不回去的钱》，文中没有流程图，特此补上按照我作图的思路和过程带着大家把这个图做出来，也算是一次绘图模拟训练了先定全局流程整个流程图有三个泳道组成，左边是退款业务发起方，右边是退款渠道，中间是支付核心的退款处理流程再定退款流程的分支退款处理流程部分也包含三部分，超过退款时效的退款处理、退款主流程、正常退款处理其中两个子流程之间有一条通路，通过退款失败是否超时效链接对流程图进行细化基于上面的设计框架进行细化，即可以得到完整的流程图，如下图所示退款发起：业务系统发起退款申请，用户取消了订单、申请退货、售后等一系列业务操作，产生了退款业务；退款请求发往支付核心退款主流程：支付核心接收到退款请求，在主流程上退款模块创建退款单，然后判断退款时效是否超期，该判断是分化出两个子流程的关键节点正常退款的处理子流程：在没有超期的情况下判定为正常退款，请求原付款通道申请退款即可，不过这里要特别注意，对于退款失败的情况，要再次判断是否因为超过退款时效，从而有一条从正常退款流程转入退转付流程的通路超过退款时效的退转付处理子流程：如果最初的退款判断出，超过了退款时效则创建退转付订单，完成收款账号信息获取以后发起付款申请退款结果通知：对于成功的退款或者付款结果通知业务方失败业务的处理：对于失败的付款或者退款根据失败原因进行处理，是调整后继续发起或者将失败结果通知业务方；比如退转付失败原因是收款账户信息有误，则返回用户进行修改后重新发起；如果是付款账户余额不足，则进行充值后再次发起本图还可以继续细化，绘制流程图的过程其实就是从主线不断分化出分支然后打磨细节的过程，切忌直接扣细节最后，2024新年第一天，祝大家新年快乐！推荐阅读陈天宇宙支付全集-跨年珍藏版V7.0陈天宇宙支付学院chentianyuzhou.com你

全文35924字，建议先收藏慢慢看支付业务，无论是收款、付款、退款、转账、充值、提现等，都离不开支付核心，支付核心是安排处理不同支付方式全局支付流程的核心系统全文将从支付架构、支付全局流程、收银台、前置路由、后置路由、退款业务、支付单据关系、支付网关模型、支付通道管理、通道等十几个方面，全方位分析支付核心的设计方法文中个别模块会涉及到支付核心相关的原型或者视频解读，会让大家对支付系统的理解更加透彻在支付核心分模块不断展开的同时，我想需要先把整个架构拿出来唠一唠，先通过全局分析略知一二，然后再去从微观上把他拆解透彻从宏观全局，看清支付系统全貌将整个支付体系进行抽象和总结，绘制成下图，在这个框架上可以基于本公司的业务规模、支付诉求、产研能力做增减和调整完美是不重要的，重要的是不完美的第一步，那个最基础的内核和框架，它是迎合市场和内部需求，走向成功的内核整个支付结构由5层组成，终端属于业务层，不考虑在内，而支付是向各终端提供支付多样化的服务，帮助业务完成收付诉求我们从下往上看1.1最底层是支付渠道层没有任何一家企业或者机构可以不依赖外部的支付服务，就可以独自完成一个支付体系的建设，所以至少要接入一家支付服务商接谁，接什么产品，至少要考虑清楚这两个问题如果只是一家刚起步的Toc电商APP，那么接一个微信APP支付、支付宝APP支付就足够用了，因此也就是2个渠道，2款支付产品，2组支付接口但是，随着业务的不断扩大，支付场景越来越多，为了提升用户支付体验势必要接入更多的支付渠道和产品，满足用户多样化的支付诉求，比如消费分期那么，可以将支付渠道层抽象出支付渠道维度和支付产品维度，总结成一句话就是“接谁的什么产品”虽然渠道不同，支付产品不同，但是支付能力大致相同因此，将支付产品的共性抽象出来，可以更好地管理支付渠道层比如可以按照收付类型抽象，抽象出收款产品、付款产品；可以按照终端类型抽象，比如抽象出App支付、小程序支付、网站支付等；可以按照支付额的大小进行抽象，比如大额支付、小额支付；也可以按照支付对象的类型进行抽象，比如对公支付、对私支付等等这样做的目的，就是看清楚渠道的画像，让渠道和产品选择更加合理和高效，避免过多的重复接入同等能力的支付产品1.2再往上就是支付网关层网关是支付核心与外部渠道通讯的关卡，也是外部多样化支付产品和接口向内部第一次统一的一层比如，简单的渠道返回码对内统一你不能指望支付核心去适应每一个渠道的不同，比如微信APP支付、支付宝APP支付、云闪付APP支付，渠道侧虽然是3套接口，但是对内完全可以抽象出APP支付一套接口，所以这是做了第一次统一支付网关还承载着支付安全、支付通讯、协议转化和处理等一系列的能力1.3网关之上就是支付核心支付核心是支付业务的核心处理层，也是基于渠道支付能力包装出内部支付业务的核心所在我们将支付核心分化出三大主要部分：支付核心、风控子系统、路由子系统，当然了，后2部分完全可以独立出去，将处理链接的服务留在支付核心内在支付核心内有2大部分第1部分是接入处理的核心流程，处理来自上游系统的支付请求，进行一系列的支付校验、参数补全、风控调用等，并将支付请求转换成最终的支付指令提交给网关完成最终的支付，以及结果回调通知业务方第2部分是支付核心的服务集群，包括支付处理、支付单处理、支付结果处理、外部服务调用模块、收银台服务、支付协议管理、支付营销、基础服务等综合支付服务的构建比如收款核心单据比如付款的核心单据比如路由的基础规则这只是可视化的那一部分，或者说是操作台的部分支付核心的大部分能力和逻辑是不可视化的，是服务化的，比如支付单的创建，支付数据的补全，要补哪些数据，从哪里获得；支付参数的校验，校验哪些，检验不通过怎么处理等等1.4支付核心之上就是统一支付能力之所以将这部分从支付核心分化出来，是因为这一部分是对外的，是支付核心支付能力产品化提供给外部的体验明确了支付核心，能为你做什么比如，收款、付款、退款、代扣、分期、绑卡、合单支付等等1.5然后就是支付的接入层支付的接入层最被熟知的就是收银台，是用户可视化的部分，也是支付的最直接入口当然，还有一个接入模式就是支付API，直接将支付能力以API的形式提供给其他业务系统调用，比如资金调拨系统对于收银台来说，最主要的就是支付方式种类的抽象，每一个支付方式背后都有一组支付通道的支持，例如微信支付，背后可能有直联微信的通道、间联微信的通道，间联通道可能来自多家提供商而，从收银台的一个支付方式发起支付，到最终从多个支付通道挑选出一个完成支付，这中间其实就是“支付核心”的使命所在每一种支付方式都有一个相同流程和个性化流程，那么支付核心就是通过相同的支付主流程完成多种个性化支付子流程的融合，形成多个支付核心流程如快捷支付在收银台中有一个用户流程同样，其他收款流程类似，但微信APP、H5支付有稍微的区别；付款流程也是如此，每个通道大体相同，但有稍微的区别，这是支付核心每一个支付流程抽象的依据将每一类支付流程，分成“主流程”“子流程”“环节”三部分比如微信JSAPI支付的大体支付流程可以说，每一个支付场景，都有一个独立的支付流程，而支付系统就是总工程师，控制这些流程的全链条和链条是环节链整个大支付体系可以抽象成12个字买、收、付、退、充、提、转、调、算、结、管、对每一个字都代表了一个大的业务，依赖某一款产品去实现比如买：交易体系的能力，支付的业务起源；收付退：支付核心的主要支付能力；充提转：钱包的支付能力；调：资金管理系统的支付能力；算结管：是清结算的处理能力；对：就是对账，确保数据的一致性当然还有财票税，咱就先剔除在外，自成一家从全局流程，看清支付流转整个支付系统产品架构可以抽象出以下的业务架构各业务终端通过收银台或者开放API接入支付核心，发起支付业务请求，通过支付核心完成自己的支付业务支付核心主要由支付处理核心、支付风控、支付路由、支付网关等4个核心部分组成当然整个支付业务的实现也离不开其他层的支持，如交易核心、清结算、账务核心、以及用户中心、商品中心、合同中心等在这样的框架下，支付的核心处理流程是什么样的呢？我们通过3张图可以展开这部分的分析2.1全局支付流程剖析站在全局的视角看支付流程，了解清楚从用户挑选商品开始，到最后支付完成，不同系统层之间是如何协调完成的，看下面第1张图横向看，代表支付的进程，包含了交易处理环节、收银台处理环节、支付处理环节、支付应答环节；该4大环节分别解决了交易单的生成、收银台的封装和展示、请求支付渠道完成支付、支付后的各方应答反馈纵向看，是支付在多层之间的协同交互，主要是客户端、交易核心、支付核心以及外部支付渠道侧的业务处理，这里我们弱化了与其他如账务核心的交互2.1.1交易处理完成业务单据生成用户支付的前提是要买东西，因此需要先选择自己需要的商品，并且生成对应的订单以后，才能进入到支付环节（1）去结算用户在购物车选择了自己要结算的商品，去结算（2）交易计价这时候需要计算出本单相关的费用，例如优惠券的使用、总优惠券金额、本单应付金额等信息（3）提交订单用户提交订单以后在交易核心生成交易单据，并完成卡券的冻结、订单的创建、账单的创建，如此完成了整个业务层交易类单据的生成2.1.2.收银台从无到有交易层业务处理完成以后，接下来就开始进入支付阶段的，支付的起点是收银台（1）跳转到收银台有了完整的业务单据信息以后就可以请求支付核心获得本笔交易的收银台的模版，然后反馈客户端，跳转到收银台页面，进入到支付流程中我们在收银台模版一文详细介绍了在客户端是如何获得可用收银台的，这里就不再详述了到了收银台页面，展示了本单支持的支付方式，用户选择对应的支付方式，例如微信支付，就正式进入了支付处理阶段2.1.3.支付处理，条条大路通罗马不同的终端类型、如网站、H5、APP等，就有不同的支付流程，比如在网站进行支付，就无法跳转到支付应用中，但可以跳转到银行网银或者扫码支付但整体来看整个支付流程应该分成三大部分的流程，客户端的流程、支付核心的流程、与渠道的交互流程（1）终端支付流程不同的终端形成了不同的终端支付流程，是展示收款码还是跳转到网上银行，支付成功后落地页是什么（2）支付核心流程是针对“终端+支付方式”所形成的支付业务处理，如APP里的微信支付、网站的快捷支付、H5内的快捷支付等，都有相似的“主流程”和“差异化的分支流程”但是支付核心的主流程如上图所示，不管什么支付方式都包含了参数的交易、交易信息补全、风控与路由处理、支付单的生成及渠道请求报文的封装、提交渠道等相同的环节（3）与渠道的交互流程不同的支付方式就决定了如何与渠道进行交互，有的渠道可能需要预下单、有的渠道可能就不需要、在预下单以后渠道就会返回不同的“支付标识”，如token、url等，这是支付下一步的关键参数如微信的JSAPI支付的交互流程第一次预下单交互，调用预下单接口，渠道返回了预付单标识通过JSAPI下单接口获取到发起支付的必要参数prepay_id，如上图，然后使用微信支付提供的前端JS方法调用公众号支付，在请求参数中使用prepay_id，封装到package参数中2.1.4支付各方应答支付发起以后，等待支付渠道的结果通知，在发起支付请求时我们预留了“通知地址”，渠道会将支付结果告知该地址支付核心根据渠道的结果通知，对各方进行应答（1）客户端向用户应答支付成功了要告诉用户，如果支付是跳转到了渠道的收银台，那么用户在渠道的支付应用内已经知道了支付成功的结果只不过，用户调回商家应用以后会到达商户应用的支付成功通知页面至此，客户端的支付流程就全部结束了，但是整个支付还没有结束，支付系统还要进行各方通知（2）通知交易支付结果支付核心需要将支付结果告知交易系统，毕竟人家是业务方，支付成功后还要进行订单履约等一系列后续动作交易接收到支付成功的通知以后，会更新交易单、订单、账单等的单据状态为成功然后对卡券发起核销处理，订单进入到履约阶段卡券的处理一般是下单成功以后进行冻结，支付成功以后进行核销，也就是如上图中券状态变成已使用或者已核销（3）通知路由，进行数据累加因为有些渠道需要计算累加交易，以进行交易的分流，就是每个渠道都提供的交易，不能0交易此时路由就需要记录每个通道的累计交易情况，以便后续进行通道筛选时使用（4）通知账务记账当然，支付成功以后记账是少不了的，这一点就不过多描述了2.2支付核心主流程的11个环节上面我们介绍了全局视角的支付流程，当然还能进行细化，比如每一个支付方式的具体支付流程在第1张图中进行展开细化了解了全局流程以后，应该支付支付请求到了支付核心以后的处理流程是什么样的这里要清楚，每一个支付方式，路由筛选出了不同的通道，都会形成一个独特的支付处理流程，快捷支付、网银支付；A支付机构的快捷支付、B支付机构的快捷支付等所形成的支付核心的处理流程是存在差异的当然，要想把控好每一个支付方式在每一个通道的处理流程，首先要先把握“主线流程”主线流程不会因为支付方式的不同，选择的渠道不同而不同真正不同的是渠道的差异化造成的，所以我们把支付核心主流程抽象出11个环节，这就是第2张图可以根据实际的业务需要，对该图的环节进行增加或者删减，但大同小异上图的11个环节可以再次划分成客户端支付请求处理、支付核心请求报文处理、请求渠道发起支付、支付应答处理等4个阶段2.2.1客户端支付请求处理客户端或者内部业务系统按照支付接入接口要求传入支付请求，需要进行一系列的校验和信息补全处理如上图所示，应该判断该请求是否有当前支付业务的请求权限，并校验请求参数是否合法，比如必填参数是否正确、参数格式是否正确、枚举类参数的枚举是否正确等然后对交易信息进行补全，比如增加交易状态、其他一些交易信息补充，为后续的请求路由系统以及生成支付单做准备2.2.2支付核心支付报文处理交易信息完整以后，接下来就是请求路由获取可用支付通道通过路由系统返回的通道编号，补全渠道信息，例如该渠道的商户号信息、通讯协议信息、以及一些其他差异化数据2.2.3请求渠道发起支付支付单生成以后，并且补全了渠道需要的参数以后，就开始准备向渠道发起支付申请了按照渠道的协议要求，封装协议参数，进行加密、签名，封装成渠道要求的报文格式然后，请求相应接口发起支付并且，通知支付单模块、路由系统、记账系统等内部系统更新状态以及下一步业务的预处理2.2.4支付应答将支付报文提交给渠道以后，就等着渠道返回支付结果了接收到支付结果以后，更新支付单相关状态，并通知交易系统、业务请求系统、账务系统等内部系统进行支付成功后的业务处理至此，一笔支付的处理就结束了以上的主流程，可以在每一个支付方式上进行差异化调整，细化2.3支付单据结构，2单号模型因为支付不一定请求一次就成功了可能第一次用户取消了，要重新发起支付，或者第一次失败了，系统要再次发起支付从而，一笔支付可能需要与渠道交互多次2.3.1渠道的多次请求要求而不同渠道对于重复请求，对单号有不同的要求，有的可能需要取消原单，以新单发起支付，以避免重复支付或者付款，有的可能没有这个要求，需要使用原单号发起支付这一点要跟退款重新发起区别开，渠道对重新发起退款的要求是使用原单号进行退款，不需要更换退款单号，这一点与重新发起支付请求有区别2.3.2支付核心的单据结构设计考虑到支付的重新发起情况，我们可以将支付单的结构设置成两层结构，由支付单和支付流水组成，一笔支付单对应对比支付流水支付单与业务请求一一对应，支付单与支付流水一对多，支付流水与渠道请求一一对应该结构如下图所示，这是我们要关注的第3张图这样的机构下会产生至少3个单号，业务订单号、支付单号、支付请求号（支付流水号），形成的表结构和对应关系如下图所示以上就是支付核心的全部支付流程分析，具体的支付方式的差异化流程，大家可以自主研究在上述的框架上，具体的支付方式的流程相对比较简单，就不再展开了支付从收银台开始收银台，从字面意思“收银台=收+银+台”，顾名思义就是收取银子的台子3.1初识收银台传统收银台在古代你去饭馆吃饭喝酒吃肉，酒足饭饱后到柜台掏出50两的大元宝拍在了“收银台”上：老板结账，不用找了；最原始的收银台就是那个柜台，柜台的特点就是结账的场所，你把钱放上去，有专门的人员核实账款与商品，无误以后，交易就完成了。结账场所最核心应该具备的内容应该包括以下点商品信息：消费了什么价格信息：应该多少钱支付方式：如何结算，现款还是赊账核实人员：核对货款的一致货款交割：付款结账，宣布完结这些信息构成收银台应该具备的基本元素以及职能，而且这些职能是在实际执行过程中逐渐形成并固定下来。对于电子支付收银台的设计具有参考意义。线下收银台近代在电子支付出现之前，我们去超市购买商品，挑好货品后拿到结账处进行清点，工作人员告诉你“一共10斤粮票”

我们知道支付是付款人向收款人的资金转移，而支付系统就是实现这一目标的处理系统“转移”可以是用户要在平台下单购买商品向平台支付资金，也可以是平台要向商家结算经营款而发起了付款1.支付的通用模型因为要转移的资金存储在外部非金融或者金融机构的结算账户或者支付账户中，因此如果想实现资金转移的目标，就需要接入能与这类机构进行通讯的通道，通过通道发起支付指令和接收资金的处理结果从图中可以看出来，支付通道要解决2个核心问题，一个是发起支付指令，另一个是接收支付结果；收款业务发起收款指令接收收款结果，通过收款通道实现；付款业务发起付款指令接收付款结果，通过付款通道实现以上是我们知道的常规通道，三方支付机构的收付通道，网联银联的各类通道，银行的各类通道，都是支付正规军，标准化的支付业务2.支付核心架构及通道广义化可以看如下的支付架构图，在通道层的常见通道位置，以此实现上述的收付业务图中有一个标红的通道种类，也就是有没有非正规军或者非常规的支付通道呢？为了完成“支付业务”，能不能跳出三界之外，不拘泥于传统，在保持上述框架的基础上，而更加灵活多变这就是接下来要谈的“广义通道”，即只要能实现“广义收付指令发起”“广义收付结果接收”二者中的任何之一的职能，我们都称之为“通道”我们举例能查账户流水通过系统匹配实现支付确认，其中的“查询流水的接口”，可以认为是一种通道可以人工导入线下凭证以确认待收付单据，其中“线下凭证的导入”，可以认为是一种通道可以人工确认支付结果、其中“确认按钮”的结果确认，可以认为是一种通道接入账户系统发起余额增减并接收增减结果、可以认为“账户系统提供的接口”是一种支付通道接入仓储，可以通过变更寄存商品的归属权，进行债权转移以完成价值交换或者应收应付的核销，其中的接入仓储可以认为是一种通道因此，支付是资金的转移，交易是价值的交换，而支付其实就是资金与价值的交换，因此广义支付就是构建价值交换的通路，而广义的通道就是价值交换通路的交换信息发起和交换最终结果的接收那么回到上面的支付架构图，将红色带“？”地通道模块展开高维支付思维架构图如此架构，可以将更多的支付“相关类似业务”兼容到支付系统的架构中，让支付系统架构更具灵活性，并为支付业务的拓展提供了在架构上的指导和设计规范图中的某些处理在常规情况下，我们一般不会放到通道层，比如调用内部账户系统的余额支付，很多时候我们会直接由支付核心去调用，而不是通道层去调用，这时，支付核心将会在主流程之外构建一个特殊的分支，就像在人的体外插了一个输液的管子一样，这样做，看似没什么，但总归是对“整体架构的损害”下面通过1个例子来强化上面的5类或者更多特殊支付通道构建支付业务的思维3.线下汇入，模拟支付通知有些场景用户会直接汇款至对公户，即线下支付，最大的弊端就是资金处理和线上的业务单据割裂这部分款项的核对以及领取相比全流程线上交易来说，比较繁琐，一方面是核对困难，另一方面就是款项和业务单据对应上比较麻烦当线下汇入体量较大时，该部分工作成本更高；如果线下进行汇款，而需要线上履约时，这部分匹配工作如何提升效率，能否自动化实现而依托“广义通道和支付架构”的引导，我们将对账能力认为是一种支付能力，通过支付核心构建出来，因此就形成了这样一种结构即业务系统请求支付核心，支付方式为“线下汇入”，支付核心创建线下汇入待支付单通过银企直联获取银行账户流水作为支付结果信息，在线下汇入支付的处理中进行结果的匹配，从而获得线下汇入支付单的最终支付结果，并将该结果告知业务系统，业务系统收到结果后进行后续的业务处理那么，我们怎么将线下汇入业务融入到整个支付核心的架构中呢？如下图在支付接入层增加线下汇入支付方式，业务系统可以进行调用，在支付核心创建“线下汇入支付方式的支付单”，最初的单据状态为待支付线下汇入的支付处理关键处理是“线下汇入结果匹配”而通道层的“广义特殊通道”为“查询银行流水”；是建设在银行通道的“银企直联”之上大家看一段视频，加深对构建一种特殊支付业务的思路陈天宇宙支付学院chentianyuzhou.com你

产品经理除了专业的系统设计方法论，还需要大量的基础产品素养这些基础的产品素养往往是最底层的，会直接影响到上层的专业能力的表现比如，挖掘用户痛点，分析需求，很强的目标感，产品效果评估等等方法，虽然不如“怎么设计对账系统”

前几天有朋友在群里发了一个问题，挺有意思，张三卖了一套房，最后一分钱没拿到？怎么回事张三的房子和120万去哪了？这类思考题常常通过一些假设制造迷惑性，常用的手段是偷换概念、多算少算、与现实不符等截图中的问题明显是与现实不符，除非张三是个傻子，要不他不会这么干题中明显存在一定的隐含假设从而对大家造成了误导第一个隐藏假设就是：现实假设，你看到该题后，心里明显会与现实联系上，房子能住70年，这样才觉得张三的房子卖亏了第二误导性：违背客观事实的假设，现实中张三绝对不会这个干，房租一个月1万，租十年就等于当前房价了，那张三肯定会往外租，而不会往外卖因此，我给出了下面的一些思路这只是从理性的角度分析其中的缘由，那么从财务或者数学角度算一算，反映到账面上，究竟问题的症结在什么地方帮张三找一找他的120万去哪了？这里需要做一个假设，就是张三的房子不会凭空出现，要不是自己买的，要不是自己盖的，无论是买或者盖，其实都需要花钱而，这个钱哪里来的，要不是原来银行卡里就有，要不就是从银行贷的这里，我们假设是从银行全额贷款，买了这栋房子；即使是自己的钱，那么这个钱也有来源，比如省吃俭用攒的如此，我们根据问题描述，可以做出以下的会计分录最开始就是张三贷款买房子的分录借

昨晚支付核心原型解析直播中，答疑环节有同学提出一个问题比较典型，可能是很多同学的疑问点整个交易、支付、清结算、账务体系柔和到一起，会产生很多的单据、单号，他们之间存在着错综复杂的关系如果再把正向、逆向考虑进来，他们之间的关系就更加复杂了下面我们就把订单、账单、支付记录、支付单、支付请求、卡消费记录、券核销记录等单据，他们在交易正、逆向中是如何联系的，又有怎么样的数据关系我们先设定个场景，比如在某平台购买了一次做饭保姆服务，总价是120元，并且分2次支付，“先预付80元，再后付40元”，预付时用了一张20元的优惠券，微信支付了60元以上场景的发生并不是依赖一个系统实现，而是通过3个核心实现，分别是交易核心、支付核心、卡券营销核心，每个核心内会产生相应的单据交易核心交易核心安排交易流程，包含了订单子系统和账单子系统其中订单子系统内会生成订单，订单记录了平台跟用户的本次交易信息，买了什么商品、一共多少钱、用户要用什么支付等账单子系统会产生账单，账单记录了订单要如何结算的信息，为后面的支付、卡券核销等做准备，案例中会产生2笔账单，预付账单和后付账单一笔账单需要被用户支付（结算），而账单中的支付方式是广义的支付方式，包括卡、券、满减、积分以及渠道支付等，如案例中的预付账单优惠了20元，渠道支付了60，假设用户选择了微信支付，则账单的支付记录如下因此在交易核心有3个单据，分别是订单、账单、账单支付记录，他们之间是一对多对多的关系，如下所示卡券营销核心券系统内记录的用户的券绑定信息、冻结及核销记录；卡系统记录了用户卡余额的消耗记录、卡余额退回记录而卡券的变动记录依赖交易核心的推动，交易核心如何推动卡券建立联系呢？靠的就是账单支付记录单据案例中因为用了一张20元的券，所以券系统核销了该券，我们假设有一笔核销记录而这条记录与账单支付记录之间建立了关联支付核心上述案例中有60元走微信支付，也就是请求外部支付渠道完成支付，这部分支付走的就是支付核心支付核心是处理走外部支付通道的支付处理业务而在支付核心会产生2类单据，一类是正向支付的支付单和支付请求明细；第二类是退款单和退款请求明细而一笔支付可能会请求渠道多次，因此我们还会建立一个支付请求的明细支付单和支付请求之间是1对多的关系上述就是本案例支付在3个核心内产生的全部单据，那么他们之间形成了如下的关系上面讲清楚了正向所形成的单据，以及单据之间的关系；那么再考虑逆向订单退款就容易多了因为逆向是正向的反方向，所以涉及到的依然是3个核心，依然是上述的单据维度，只不过单据变成了逆向单，即订单变成了退单，账单变成了退款账单、账单支付记录变成了账单退款记录、支付单变成了退款单等如下图所示，这是直播过程中直接的板书，这里的关系看得更加直观一些，上面的用表结构标识，这里就直接可视化了，更能看出单据之间的关系逆向单据需要了解这样几个关键点逆向都是基于正向没有正向的单据就不会有逆向的单据，比如用户没有下单，就不会取消订单、也不会操作订单退回，支付也是如此，没有原来的支付成功，就不会有退款支付退款基于原支付单支付核心的退款，必然是支付单，不能摆脱原支付单的控制，退款可以全部退、部分退或者分多次退，但都不会超过原支付金额逆向由订单发起订单是逆向的起点，就是只有业务产生了逆向处理，比如退了部分商品、或者订单差评产生了部分退回等，才会产生支付的逆向因此，退款不一定有订单逆向，也可能是订单产生的差评罚款或者其他原因，但不管怎样，都是基于订单，所以说，退款基于订单发起交易需要控制逆向的顺序订单产生了逆向，因为订单用了卡、券、积分、微信支付等多种支付方式那么逆向发生以后，先处理谁，先退券还是先退积分，还是先退微信支付的金额如果是全额退还好说，毕竟最终都会逆向处理，但是部分退呢？支付了80，用了20元的券，微信支付了60，现在要退40，怎么退？是退20的券微信退20，还是微信退40？因此需要一个逆向顺序的控制，如案例中，我们设置了这样的顺序，以及设置了券不返还的策略这样的规则下，如果预付单只退50元，那么看预付单的情况按照“券>卡>渠道”的退款顺序逆向的话，先处理20元的券，因为券不返还，所以就只是将券变成以取消即可，这样就会从营销成本中核销掉而，30元从微信支付退所以，用户部分退50元，在这样的逆向策略下，只能拿回30元如果以上的文字看起来比较费劲，那么以下是直播关于该问题答疑的回放片段，看视频更简单，听我解析各单据之间的关系，总时长11分钟陈天宇宙支付学院chentianyuzhou.com你

前几天我们解析了支付核心的产品架构，整个产品架构可以抽象出以下的业务架构各业务终端通过收银台或者开放API接入支付核心，发起支付业务请求，通过支付核心完成自己的支付业务支付核心主要由支付处理核心、支付风控、支付路由、支付网关等4个核心部分组成当然整个支付业务的实现也离不开其他层的支持，如交易核心、清结算、账务核心、以及用户中心、商品中心、合同中心等在这样的框架下，支付的核心处理流程是什么样的呢？我们通过3张图可以展开这部分的分析站在全局的视角看支付流程，了解清楚从用户挑选商品开始，到最后支付完成，不同系统层之间是如何协调完成的，看下面第1张图横向看，代表支付的进程，包含了交易处理环节、收银台处理环节、支付处理环节、支付应答环节；该4大环节分别解决了交易单的生成、收银台的封装和展示、请求支付渠道完成支付、支付后的各方应答反馈纵向看，是支付在多层之间的协同交互，主要是客户端、交易核心、支付核心以及外部支付渠道侧的业务处理，这里我们弱化了与其他如账务核心的交互1.1.交易处理完成业务单据生成用户支付的前提是要买东西，因此需要先选择自己需要的商品，并且生成对应的订单以后，才能进入到支付环节（1）去结算用户在购物车选择了自己要结算的商品，去结算（2）交易计价这时候需要计算出本单相关的费用，例如优惠券的使用、总优惠券金额、本单应付金额等信息（3）提交订单用户提交订单以后在交易核心生成交易单据，并完成卡券的冻结、订单的创建、账单的创建，如此完成了整个业务层交易类单据的生成1.2.收银台从无到有交易层业务处理完成以后，接下来就开始进入支付阶段的，支付的起点是收银台（1）跳转到收银台有了完整的业务单据信息以后就可以请求支付核心获得本笔交易的收银台的模版，然后反馈客户端，跳转到收银台页面，进入到支付流程中我们在收银台模版一文详细介绍了在客户端是如何获得可用收银台的，这里就不再详述了到了收银台页面，展示了本单支持的支付方式，用户选择对应的支付方式，例如微信支付，就正式进入了支付处理阶段1.3.支付处理，条条大路通罗马不同的终端类型、如网站、H5、APP等，就有不同的支付流程，比如在网站进行支付，就无法跳转到支付应用中，但可以跳转到银行网银或者扫码支付但整体来看整个支付流程应该分成三大部分的流程，客户端的流程、支付核心的流程、与渠道的交互流程（1）终端支付流程不同的终端形成了不同的终端支付流程，是展示收款码还是跳转到网上银行，支付成功后落地页是什么（2）支付核心流程是针对“终端+支付方式”所形成的支付业务处理，如APP里的微信支付、网站的快捷支付、H5内的快捷支付等，都有相似的“主流程”和“差异化的分支流程”但是支付核心的主流程如上图所示，不管什么支付方式都包含了参数的交易、交易信息补全、风控与路由处理、支付单的生成及渠道请求报文的封装、提交渠道等相同的环节（3）与渠道的交互流程不同的支付方式就决定了如何与渠道进行交互，有的渠道可能需要预下单、有的渠道可能就不需要、在预下单以后渠道就会返回不同的“支付标识”，如token、url等，这是支付下一步的关键参数如微信的JSAPI支付的交互流程第一次预下单交互，调用预下单接口，渠道返回了预付单标识通过JSAPI下单接口获取到发起支付的必要参数prepay_id，如上图，然后使用微信支付提供的前端JS方法调用公众号支付，在请求参数中使用prepay_id，封装到package参数中1.4支付各方应答支付发起以后，等待支付渠道的结果通知，在发起支付请求时我们预留了“通知地址”，渠道会将支付结果告知该地址支付核心根据渠道的结果通知，对各方进行应答（1）客户端向用户应答支付成功了要告诉用户，如果支付是跳转到了渠道的收银台，那么用户在渠道的支付应用内已经知道了支付成功的结果只不过，用户调回商家应用以后会到达商户应用的支付成功通知页面至此，客户端的支付流程就全部结束了，但是整个支付还没有结束，支付系统还要进行各方通知（2）通知交易支付结果支付核心需要将支付结果告知交易系统，毕竟人家是业务方，支付成功后还要进行订单履约等一系列后续动作交易接收到支付成功的通知以后，会更新交易单、订单、账单等的单据状态为成功然后对卡券发起核销处理，订单进入到履约阶段卡券的处理一般是下单成功以后进行冻结，支付成功以后进行核销，也就是如上图中券状态变成已使用或者已核销（3）通知路由，进行数据累加因为有些渠道需要计算累加交易，以进行交易的分流，就是每个渠道都提供的交易，不能0交易此时路由就需要记录每个通道的累计交易情况，以便后续进行通道筛选时使用（4）通知账务记账当然，支付成功以后记账是少不了的，这一点就不过多描述了上面我们介绍了全局视角的支付流程，当然还能进行细化，比如每一个支付方式的具体支付流程在第1张图中进行展开细化了解了全局流程以后，应该支付支付请求到了支付核心以后的处理流程是什么样的这里要清楚，每一个支付方式，路由筛选出了不同的通道，都会形成一个独特的支付处理流程，快捷支付、网银支付；A支付机构的快捷支付、B支付机构的快捷支付等所形成的支付核心的处理流程是存在差异的当然，要想把控好每一个支付方式在每一个通道的处理流程，首先要先把握“主线流程”主线流程不会因为支付方式的不同，选择的渠道不同而不同真正不同的是渠道的差异化造成的，所以我们把支付核心主流程抽象出11个环节，这就是第2张图可以根据实际的业务需要，对该图的环节进行增加或者删减，但大同小异上图的11个环节可以再次划分成客户端支付请求处理、支付核心请求报文处理、请求渠道发起支付、支付应答处理等4个阶段2.1客户端支付请求处理客户端或者内部业务系统按照支付接入接口要求传入支付请求，需要进行一系列的校验和信息补全处理如上图所示，应该判断该请求是否有当前支付业务的请求权限，并校验请求参数是否合法，比如必填参数是否正确、参数格式是否正确、枚举类参数的枚举是否正确等然后对交易信息进行补全，比如增加交易状态、其他一些交易信息补充，为后续的请求路由系统以及生成支付单做准备2.2支付核心支付报文处理交易信息完整以后，接下来就是请求路由获取可用支付通道通过路由系统返回的通道编号，补全渠道信息，例如该渠道的商户号信息、通讯协议信息、以及一些其他差异化数据2.3请求渠道发起支付支付单生成以后，并且补全了渠道需要的参数以后，就开始准备向渠道发起支付申请了按照渠道的协议要求，封装协议参数，进行加密、签名，封装成渠道要求的报文格式然后，请求相应接口发起支付并且，通知支付单模块、路由系统、记账系统等内部系统更新状态以及下一步业务的预处理2.4支付应答将支付报文提交给渠道以后，就等着渠道返回支付结果了接收到支付结果以后，更新支付单相关状态，并通知交易系统、业务请求系统、账务系统等内部系统进行支付成功后的业务处理至此，一笔支付的处理就结束了以上的主流程，可以在每一个支付方式上进行差异化调整，细化因为支付不一定请求一次就成功了可能第一次用户取消了，要重新发起支付，或者第一次失败了，系统要再次发起支付从而，一笔支付可能需要与渠道交互多次3.1渠道的多次请求要求而不同渠道对于重复请求，对单号有不同的要求，有的可能需要取消原单，以新单发起支付，以避免重复支付或者付款，有的可能没有这个要求，需要使用原单号发起支付这一点要跟退款重新发起区别开，渠道对重新发起退款的要求是使用原单号进行退款，不需要更换退款单号，这一点与重新发起支付请求有区别3.2支付核心的单据结构设计考虑到支付的重新发起情况，我们可以将支付单的结构设置成两层结构，由支付单和支付流水组成，一笔支付单对应对比支付流水支付单与业务请求一一对应，支付单与支付流水一对多，支付流水与渠道请求一一对应该结构如下图所示，这是我们要关注的第3张图这样的机构下会产生至少3个单号，业务订单号、支付单号、支付请求号（支付流水号），形成的表结构和对应关系如下图所示以上就是支付核心的全部支付流程分析，具体的支付方式的差异化流程，大家可以自主研究在上述的框架上，具体的支付方式的流程相对比较简单，就不再展开了陈天宇宙支付学院chentianyuzhou.com你

一个公司接的通道多了，路由就成了必需品即使不做路由系统，完全依靠代码实现，但依然需要路由模型和逻辑那么，路由筛选最优通道就需要一系列的筛选规则，路由规则就成了路由系统的重中之重我们就来梳理一下，常见的路由规则有哪些，以及这些规则的内容是什么路由规则可以分成2大类，分组规则和筛选规则分组规则顾名思义就是对通道进行分组为什么要分组呢？我们知道，路由筛选是多种类的，不仅仅是筛选收款通道，还有付款通道、鉴权通道、实名通道等等因此，如果一笔请求是付款业务，那么你就完全没必要去判断鉴权通道，否则你将全部通道都做一次判断，那路由的效率损失和性能消耗是非常大的这样的话，在请求来了以后，通过分组条件对通道快速进行分组筛选，先精确过滤掉大部分通道以后，再进行精细筛选，效果就更好了分组维度如何设定呢？其实分组条件一般不会太多，就如对人群进行分组一样，可以通过性别进行分组，男性、女性；可以通过籍贯进行分组，南方人、北方人通道分组条件常见的如：交易类型，账户类型，卡种，银行等你看我们在收银台选择银行卡付款时，会有2个分组，B2C还是B2B，信用卡还是借记卡，这就是明显的分组因此，如果用户是信用卡，那么仅支持借记卡交易的通道就肯定不适用分组条件的设置就是这个原理进行分组以后，剩下的更少的几个通道，再进行筛选规则的筛选比如通过卡种做了分组以后，剩下的全部是支持信用卡的通道，再进一步筛选，这时候的要筛选的通道数量明显减少每经过一个筛选规则的过滤，都会剔除掉一部分通道，直到最后剩下1条通道或者0条，如果是0条的话，这笔交易可能就无法完成支付了上面我们讲了通道规则往往会分为分组规则和筛选规则2大类，二者共同构成一个逻辑链条一个平台只有一个规则链吗？不一定如果你是一家非常小的公司，或者支付业务非常单一的公司，只有收款业务，那么一条链就够了，就是判断这笔收款走哪条收款通道但是，如果你是一家业务种类非常多，通道种类非常多的公司，一条链可能就不够了比如从支付产品来看，可能不同的支付产品需要的规则链不同，例如网银支付、快捷支付，通道的属性不同，需要校验条件不一样；但大部分条件是一样的，比如快捷支付设置了用户等级筛选条件，只有VIP用户才配用快捷支付，而网银不受这个限制，那么快捷支付的规则链中就多了一个“用户VIP筛选”从业务种类来看，支付、付款、鉴权、实名等不同的业务，其分组条件和筛选条件就完全不同例如，鉴权类业务，需要路由筛选出最优的鉴权通道，那么，鉴权类筛选里就有如“鉴权项数量”的筛选过滤，你要鉴权3项，而一条仅支持2项鉴权的鉴权通道就不满足了因此，需要将整体业务进行抽象，抽象出多条规则链条不同类型的企业通道类型不同，整个规则体系的设计方法论一样，只不过具体规则内容不同为了更好分析下面的内容，我们假设是一家三方支付机构三方支付机构的通道来自网联、银联、银行以及其他的三方机构，通道种类非常多，数量也比较多，能分析的规则就比较多就更容易覆盖普通企业的路由条件路由的基本逻辑是匹配，根据交易参数，匹配通道的属性，以获得最合适的通道所以，研究路由规则就不得不研究匹配逻辑，而研究匹配逻辑就不得不了解交易参数和通道的基本属性交易传入的参数其实就是路由的请求接口要求传进来的参数，可能不同的路由业务要求的参数不同，比如支付传参和鉴权传参就不一样比如支付参数，你必须传进来商户号吧，这样路由系统才知道是哪个商户的交易，你必须传进来银行卡种吧，毕竟借记卡和信用卡所能用的通道不同，等等当然了，传什么不是机械的，是由你的路由规则决定的，换句话说就是路由需要什么就传什么通道属性通道属性也可以认为是通道的画像，支持什么类型的支付，支付什么行业，什么时候维护，哪家银行的通道等等有了这些属性，才能与交易的特征进行匹配分组规则前面介绍了，是为了快速缩减通道范围分组条件往往是交易在请求路由系统时的必传参数，而且多是通道的可枚举的离散属性什么是离散呢，就是一个一个的，比如卡种，就是信用卡、借记卡相对于离散就是连续，如时间，成本，就是连续条件，你不能用成本对通道进行分组，除非通过设定成本区间将成本这种连续的属性，变成离散属性如将通道成本分成三个区间[0,0.5)[0.5,0.8)[0.8,+∞)，就可以通过成本区间将通道进行分组常见的分组条件有交易类型，是消费支付、还是付款、还是鉴权；也就是这条通道支持的交易属性是什么，是支付通道、付款通道还是鉴权通道账户类型，是对个人还是对公账户；就是这条通道是支持个人支付还是企业支付卡种，是借记卡还是信用卡，这也是通道的属性之一，支持借记卡支付还是信用卡支付，当然，有些通道两类卡都支持银行，这是哪家银行的，招商、工行还是农行，因为像银行卡类交易或者付款，往往同行支付体验更好，成本更低，跨行的支付成本更高一些通过上述4个分组条件对通道进行分组，可以快速缩小要筛选通道的数量不同的规则链可以选择对应的分组条件，如鉴权规则链，如果接的都是银联的服务，那么就不需要银行这个分组条件了在通道完成分组以后，那么就需要在剩下的通道当中进行更精细的筛选了筛选规则就是指定通过哪些通道属性来过滤通道比如，通道状态可不可用啊，需不需要报备啊，有没有白名单限制啊，营业时间到没到啊，有没有行业限制啊，这个商家有没有特别定制啊......其中，有些是通道的固有属性，例如有效状态；有些是需要进行加工计算的属性，列如本笔交易在某一条通道的交易成本经过一系列井然有序的筛选以后，能用的通道越来越少，最后几条筛选规则彻底杀死筛选比如成本最低优先，会出现一个排序，除非有2条通道的成本一样，否则一般能选出唯一的通道如果最后所有规则都执行完了还没选出唯一的，还剩3条，怎么办那么这个时候，要不就是你的路由规则设定有瑕疵，要不就是通道过于重复，这时候就需要优化路由规则链，比如对同类通道强制性增加一个优先级排序，当都满足时，谁最优先常见的筛选规则有以下这些通道状态这是通道的固有属性，配置在通道信息中，一般是开通、关闭两个值，每次交易要过滤掉处于“关闭”状态的通道营业时间不管怎样，你得等别人开始营业才能去办理业务，也就是通道的营业时间维护，7*24小时的通道就不用说了，那些有固定营业时间的通道不是所有时间都支持交易的，比如人行的大额系统就有固定的营业时间鉴权过滤项在银行卡支付时，需要填写付款卡信息，用户填了多少决定了能走哪些通道，有的通道可能需要都填，有的通道可能不太严格；一般可以执行，必填必验，可填可验，必填不验银行短信验证有些通道会下发短信验证，有些通道不会，根据业务的诉求可能有些交易需要短信强验证，那么根据交易是否需要验证来过滤通道；如果你选了一个不会下发短信的通道执行一个需要进行短信验证的交易处理，那么通道就选错了行业准入过滤通道有时候也术业有专攻，有些行业的交易风险高，可能就不允许，所以需要根据交易的行业类型，过滤掉不支持该行业的通道过滤掉签约过滤有些通道需要用户的卡进行签约，没有签约的卡的支付便不支持对于经过一系列筛选剩下的通道去看其需不需要签约，如果不需要那么就直接可用，留下该通道；如果需要签约并且不需要短信验证，那么也留下；如果需要签约也需要短信验证，那么就通过交易传进来的卡号判断该卡在此通道是否已经签约，如果没有签约，就过滤掉该通道限额过滤每一类通道都有限额，不是所有金额的支付都能走所有的通道根据交易传进来的金额，和通道本身的限额区间进行比对，决定该通道是否可用商户白名单有些通道需要设置商户白名单，名单之外的商户的支付请求不能走该通道通过交易传进来的商户编号来判断该商户在不在通道的白名单里，如果在则可以走该通道，如果不在则不能走该通道通道卡黑名单过滤有些卡比较奇怪，在某些通道就是支付成功率低，就是老出问题，那么就强制性把该卡种或者一张具体的卡添加到通道的卡黑名单中只要是交易传进来的卡信息在某条通道的卡黑名单中，那么就不走该通道了最少鉴权项优先肯定是鉴权项越少越便宜，用户支付体验越好，支付成功率越高所以，都满足的情况下，选择验证项少的通道，根据通道属性的验证项进行筛选签约通道优先优先选择那些需要签约的通道，这个可能不太好理解，不是签约就比较繁琐么，为啥要选需要签约的通道呢？这个还是长远考虑，签约以后今后的支付体验会更好，更容易成功优先级最高优先通过通道优先级这个属性对通道进行排序，选择优先级最高的通道通道优先级的设定一般根据通道的历史支付成功率、成本优势等等完成，优先级越高越说明通道质量越高，选择高优先级通道往往可以提高支付成功率降低支付成本比如同样是快捷支付通道，同类卡种，某些通道就是好，成本低，支付成功率又高，那么它的优先级就更高这个就像选择供应商一样，商品质量好、价格低、配货时效快，如果同一个商品多家供应商都能提供时，那你肯定优先选择该供应商成本最低优先支付机构肯定要赚钱，所以支付成本越低利润空间就越高那必然会选择成本最低的通道完成支付请求，根据通道的成本维护和交易传进来的金额，实时计算该笔交易走该通道的成本是多少然后在剩下的通道中选择计算出的成本最低的那条通道当然还有一些其他的规则，比如商户定制、银行定制、行业定制、直联签约优先等等，可以根据实际的需求，设置更多的分组规则和筛选规则不管怎样，无论多少规则基本逻辑都是一样的，就是通过交易特征去匹配通道特征或者进行某方面的优先性判断陈天宇宙支付学院chentianyuzhou.com你

前几天发布了2篇“支付核心”局部模块相关的文章，一篇是收银台配置相关，一篇是退转付的支付处理能力相关，文章链接我放到了底部在支付核心分模块不断展开的同时，我想需要先把整个架构拿出来唠一唠，我的习惯就是先通过全局分析略知一二，然后再去从微观上把他拆解透彻将整个支付体系进行抽象和总结，绘制成下图，在这个框架上可以基于本公司的业务规模、支付诉求、产研能力做增减和调整完美是不重要的，重要的是不完美的第一步，那个最基础的内核和框架，它是迎合市场和内部需求，走向成功的内核整个支付结构由5层组成，终端属于业务层，不考虑在内，而支付是向各终端提供支付多样化的服务，帮助业务完成收付诉求我们从下往上看最底层是支付渠道层没有任何一家企业或者机构可以不依赖外部的支付服务，就可以独自完成一个支付体系的建设，所以至少要接入一家支付服务商接谁，接什么产品，至少要考虑清楚这两个问题如果只是一家刚起步的Toc电商APP，那么接一个微信APP支付、支付宝APP支付就足够用了，因此也就是2个渠道，2款支付产品，2组支付接口但是，随着业务的不断扩大，支付场景越来越多，为了提升用户支付体验势必要接入更多的支付渠道和产品，满足用户多样化的支付诉求，比如消费分期那么，可以将支付渠道层抽象出支付渠道维度和支付产品维度，总结成一句话就是“接谁的什么产品”虽然渠道不同，支付产品不同，但是支付能力大致相同因此，将支付产品的共性抽象出来，可以更好地管理支付渠道层比如可以按照收付类型抽象，抽象出收款产品、付款产品；可以按照终端类型抽象，比如抽象出App支付、小程序支付、网站支付等；可以按照支付额的大小进行抽象，比如大额支付、小额支付；也可以按照支付对象的类型进行抽象，比如对公支付、对私支付等等这样做的目的，就是看清楚渠道的画像，让渠道和产品选择更加合理和高效，避免过多的重复接入同等能力的支付产品再往上就是支付网关层网关是支付核心与外部渠道通讯的关卡，也是外部多样化支付产品和接口向内部第一次统一的一层比如，简单的渠道返回码对内统一你不能指望支付核心去适应每一个渠道的不同，比如微信APP支付、支付宝APP支付、云闪付APP支付，渠道侧虽然是3套接口，但是对内完全可以抽象出APP支付一套接口，所以这是做了第一次统一支付网关还承载着支付安全、支付通讯、协议转化和处理等一系列的能力网关之上就是支付核心支付核心是支付业务的核心处理层，也是基于渠道支付能力包装出内部支付业务的核心所在我们将支付核心分化出三大主要部分：支付核心、风控子系统、路由子系统，当然了，后2部分完全可以独立出去，将处理链接的服务留在支付核心内在支付核心内有2大部分第1部分是接入处理的核心流程，处理来自上游系统的支付请求，进行一系列的支付校验、参数补全、风控调用等，并将支付请求转换成最终的支付指令提交给网关完成最终的支付，以及结果回调通知业务方第2部分是支付核心的服务集群，包括支付处理、支付单处理、支付结果处理、外部服务调用模块、收银台服务、支付协议管理、支付营销、基础服务等综合支付服务的构建比如收款核心单据比如付款的核心单据比如路由的基础规则这只是可视化的那一部分，或者说是操作台的部分支付核心的大部分能力和逻辑是不可视化的，是服务化的，比如支付单的创建，支付数据的补全，要补哪些数据，从哪里获得；支付参数的校验，校验哪些，检验不通过怎么处理等等支付核心之上就是统一支付能力之所以将这部分从支付核心分化出来，是因为这一部分是对外的，是支付核心支付能力产品化提供给外部的体验明确了支付核心，能为你做什么比如，收款、付款、退款、代扣、分期、绑卡、合单支付等等然后就是支付的接入层支付的接入层最被熟知的就是收银台，是用户可视化的部分，也是支付的最直接入口当然，还有一个接入模式就是支付API，直接将支付能力以API的形式提供给其他业务系统调用，比如资金调拨系统对于收银台来说，最主要的就是支付方式种类的抽象，每一个支付方式背后都有一组支付通道的支持，例如微信支付，背后可能有直联微信的通道、间联微信的通道，间联通道可能来自多家提供商而，从收银台的一个支付方式发起支付，到最终从多个支付通道挑选出一个完成支付，这中间其实就是“支付核心”的使命所在每一种支付方式都有一个相同流程和个性化流程，那么支付核心就是通过相同的支付主流程完成多种个性化支付子流程的融合，形成多个支付核心流程如快捷支付在收银台中有一个用户流程同样，其他收款流程类似，但微信APP、H5支付有稍微的区别；付款流程也是如此，每个通道大体相同，但有稍微的区别，这是支付核心每一个支付流程抽象的依据将每一类支付流程，分成“主流程”“子流程”“环节”三部分比如微信JSAPI支付的大体支付流程可以说，每一个支付场景，都有一个独立的支付流程，而支付系统就是总工程师，控制这些流程的全链条和链条是环节链整个大支付体系可以抽象成12个字买、收、付、退、充、提、转、调、算、结、管、对每一个字都代表了一个大的业务，依赖某一款产品去实现比如买：交易体系的能力，支付的业务起源；收付退：支付核心的主要支付能力；充提转：钱包的支付能力；调：资金管理系统的支付能力；算结管：是清结算的处理能力；对：就是对账，确保数据的一致性当然还有财票税，咱就先剔除在外，自成一家本来就想介绍一张图，写着写着就刹不住车了，本文只是对支付核心做了一个整体的概述，后面会有更多单独模块的剖析讲明白支付，非一日之功，也非一文能概括，细水长流，慢慢来一个点，一个点，地徐徐道来！开头提到的两篇文章这一招，让收银台“骚”起来退款这么做，就没有退不回去的钱陈天宇宙支付学院chentianyuzhou.com你

退款是一个比较常见的逆向业务但是退款不是说什么时候想退就能退，不同的渠道不同类型的支付有不同的退款时效过了退款时效，还能把钱退出去么？或者说，过了退款时效，怎么样才能把钱退回去呢？渠道的退款时效是渠道开放给商户的权益，而商户和用户的退款协议是另一回事，二者难免存在错配比如，某平台就是敢承诺，永久可退，那么我想没有任何一个支付渠道可以满足他这个诉求，怎么办？产品经理的神奇魔力就是，交给他，啥事都能给你办，不就是把超退款时效的款退回去么既然原渠道退不了了，那么......就得整点幺蛾子了退款的本质就是“把钱给他”，真想退，那就打破原路退的禁锢支付的逆向是退款，而退款也有几种基础的模式，我们先把这个了解清楚怎么退一笔订单的内容构成是多样化的，那么也必然造成一笔退款的构成也是多样化的订单包含多个商家，多款商品，多种费用，那么退款的花样就多了从退款的基础能力上来说，一般的渠道会提供以下几种退款模式，我们可以把每一种退款模式当成一种退款产品对于平台来说，又可以基于渠道的基础退款模式，封装出更多场景的退款产品比如，可以将按商品退封装出一个按“商家退”的模式，将一个订单中的同一个商家的商品打包进行退款，从效果上就是按商家退这种处理手段，就是产品经理在设计上的灵活性；没有出路，也要基于手头的能力创造出新出路从哪里出钱钱不一定都在一个篮子里，那退款也就不一定从一个账户往回退退款的本质也不是必须原路退款到指定账户，而是将钱从收款者手里退回付款者手里那么，对于收款者来说，就没必要必须从收款的账户出在渠道签约产品时，往往会开通多个账户，比如基本户、运营账户、手续费账户、营销账户等，都属于该商户而同一个账户也可能有多种资金属性，比如可用余额、冻结余额、待结算余额等所以，在退款时，有的渠道会提供指定出款账户和资金类型的能力当然，对于一个交易体量很大的平台来说，对这一能力并没有太强的诉求，从原基本户退回足够了退回哪里前面我们讲了，退款的本质是退给付款的人，而不一定非得是付款的账户因为付款人在该平台可能有多个收款路径，比如在微信有绑定的银行卡、也有微信零钱，如果原路退回绑定的卡失败，那么微信可以决定退回用户的零钱账户这样我们就把退款的基础能力梳理清楚了开头介绍了，退款有退款时效，过了这个时效，原支付不再支持通过渠道退回但是，本身的业务存在这样的超时效退款场景，比如平台的退款协议就是比渠道的退款时效长比如家政行业，有的客户一次签约3年，那么其中的客户服务费就是在三年内可退，当2年半时要退剩下的半年单子，那么服务费就需要退回半年的这个时候很明显已经过了渠道的退款时效了，但是从业务上来说又必须退款怎么办基于退款的本质是退回付款人这一点，我们不难想到——走付款构建一个新的退款产品——退转付该退款产品的核心职能就是将超过退款时效的退款申请，转换成付款，将钱付给付款人要想实现这一退款产品能力，还有几件重要的事情要做，毕竟你要打破常规打破常规，往往需要更高的成本将退款转为付款的第一个难题就来了，钱付到哪里？因为原渠道退回本身就有一个隐藏属性，那就是我们知道用户用哪个账户付的款，渠道就会退回这个已知的账户但是，付款给用户，难度就大了，因为我们不一定知道用户的收款账户信息将退款业务转换成付款要做的第一件事就是“采集用户的收款账户信息”如此，就将第一个难题转换成了一个可落地的需求，采集用户收款信息有了目标，实现起来就容易多了可以客户人工采集银行卡信息也可以在用户订单中心增加一个提示：已超原路退款的时效，需要您提交银行卡信息，平台将在3个工作日以内将款项打到该卡中以上的问题就变成了“采集入口”问题一个真正的产品难题会被一层层的分解，直到找到了答案，产品设计的过程其实就是这样一个过程那么怎么发起上述的采集动作呢？就是当后台点击“退转付”时，当然这个发起动作可以是人为触发，也可以是系统自动触发当退款失败的原因是“超过退款时效”同时用户退款协议约定又可退时，自动触发该退款路径当然了，在发起采集时可以先判断平台有没有用户的收款卡信息，如果有的话可以选择合适的付款通道将钱支付出去触发以后，在原退款订单基础之上生成一笔付款单该付款单是明确的“退转付”，与原退款单关联，付款类型定义为“退款转付款”还有非常重要的一个问题需要解决，就是付款与原退款在信息上的强关联，特别是状态的联动为什么因为退款业务是受到原支付单强制性限制，就是总退款金额不能超过原支付金额，而且，退款付的付款发起的前提是原退款单失败是由于超时效了如果退转付的付款业务不受上述条件的强制约，那么就可能发生资金损失，产生超额退款基于上述的控制链，那么退款状态和付款状态之间应该构建起联动性，退转付的状态去更新原退款失败的退款单的状态，原退款单的状态开始了新的流转最后要说明的是，退转付的付款业务应该归属于“退款”模块，或者说退款业务，而不是付款业务更精确的描述这个能力，我觉得应该是“基于付款能力的退款产品”大家可以思考一下这一点陈天宇宙支付学院chentianyuzhou.com你

全文10980个字，建议先收藏慢慢看交易是一切的基础，编排着整个业务的流转，本文重点介绍交易层的交易系统和订单系统，以及单独分析交易的逆向处理，并分析交易跟支付的区别。让每一条交易流都井然有序就像电影台词里常说的“今晚码头交易”“我要跟你做一个交易”“交易被终止了”，交易是一个司空见惯的词语，但是用在互联网产品领域，我们谈论的更多是一个狭义的交易概念，即消费购买行为。什么是交易、什么是交易系统、如何从宏观上把握交易系统框架以及从细节上完成交易系统的设计建模是本小节的重点。

在购物支付时，你有没有发现，这次的收银台提供的支付方式和上一次不一样了这是什么骚操作想了想，可能是自己换手机了，上次用的安卓手机，这次换苹果手机了，收银台多了一个苹果支付同样，在我们进行超大额支付时，收银台所提供的支付方式也不一样了，这一点容易理解，毕竟有些支付方式本身能支持的限额就非常小所以，一个平台是怎么实现收银台支付方式组合的多样化呢？为什么同一个平台，支付场景不同，看到的收银台不一样呢？主要有以下几个原因终端不同，支持的支付方式不同最直接的，安卓手机里所有App都不支持苹果支付就如微信支付分app支付、H5支付、小程序支付等等，所以不同的终端类型，单单微信支付就如此多样，所以难免在不同的发展阶段，不同终端能做到的支付方式也是有差异的在H5应用里为了快速上架商用，可能初期就仅支持支付宝一种支付方式，微信支付、绑卡支付等其他支付方式稍微再接入这样的安排，就会造成App内的收银台和H5内的收银台支持的支付方式不一样，如下图京东的pc端收银台仅支持银行卡和微信支付，相比其App端，少了很多支付方式如果平台就2个终端，总共也就微信、支付宝、银行卡三种支付方式，那么收银台的展示完全可以在终端通过代码逻辑实现商品不同，支持的支付方式不同有时候用户选择的商品不同，也会造成支付方式的不同举个例子，有些企业存在多条业务线，独立公司、独立团队运作，那么开通的收款商户号复杂多样，有的业务线可能压根就没有支付宝收款账号，那么收银台里怎么会有支付宝收款方式呢？比如我们原来新上线了一款服务品类“做饭保姆”，做为早期的验证阶段，为了尽快上架，仅开通了微信支收款商户号，没有开通支付宝，那么针对做饭保姆这个品类用户就支付用微信进行支付了这就是商品的不同造成了可选择的支付方式不同支付场景不同，支持的支付方式不同就比如开头的京东收银台，进行分次付款时，微信支付和数字人民币就不支持了这就是不同的支付能力造成了支付方式不同，也可以认为是不同的支付场景造成了支付方式的不同因为，不同的支付方式支持的场景是有限的一些特殊的合作，造成支付组合不同比如跟某些渠道达成合作，将50%的交易，让其放在收银台支付列表的第一位，会提供一定的手续费优惠，这种情况下，收银台策略发生了变化，不同的用户，或者同一个用户不同的支付，收银台支付方式排序不一样了还有一些其他原因也会造成收银台可用支付方式不同，比如支付限额，当超大额支付时，明确超过了某些支付方式的限额时，那么就应该屏蔽或者置灰该支付方式，避免在后续过程中支付失败我们前面介绍的支付方式是用户侧在支付时，收银台能看到的，常见的支付方式有微信支付、支付宝支付、云闪付、银行卡支付等等用户能看到什么是由“前置路由”决定的，也就是我们本文重点介绍的，它决定了收银台的内容还有一个路由是后置路由，也就是当用户选择了“微信支付”，并提交支付以后，后端如何决策这笔支付应该提交给谁你可能会说，用户不是已经选择了微信支付么，肯定提交给微信侧啊提交给微信没问题，但问题是，仅仅是微信么，或者只能是微信么？别忘了有很多三方机构或者聚合支付支持微信支付这种方式，也就是我们可以通过多渠道实现“微信支付”那这个时候，你就要想了，我怎么选择提交给那个微信支付？这就是后置路由要解决的问题它为每一笔支付选择最优的支付渠道，这部分我们在路由相关文章里有非常详细的介绍因此前置路由决定用户看见什么，渠道路由决定支付提交给谁进行处理当然，用户看到什么样的收银台，完全可以靠代码把逻辑写出来，比如判断什么终端、什么品类，展示什么支付方式组合但是，随着公司的发展，业务越来越复杂，终端种类越来越多，支持的支付方式越来越多，收银台支付方式组合的逻辑更加复杂这时通过逻辑代码实现不再是一个好选择因为，你不能频繁去调整非常重要的支付入口收银台的展示，不能因为一个小的策略变动，就把收银台代码改一遍，这肯定需要变革那么就可以通过“收银台配置模版”实现将平台支持的支付方式抽象出来，比如经过分析，共接入了下列的支付方式这些支付方式由于开头的那些原因需要进行不同的组合和排序每一种组合和排序都可以认为是一个收银台模版，而支付场景我们可以认为就是一组条件，有的是可以抽象和固化配置的条件，有的可能是需要逻辑和策略实现的条件上图中每一条就是一个收银台模版，其配置决定了本次命中支持的支付方式，支付方式的排序等内容应用不同支付方式不同，业务线不同、品类不同、交易类型不同支付方式也可以不同，我们甚至可以为某一个具体的用户或者商家提供个性化的支付方式组合根据新的策略去配置新的模版，让收银台的丰富性变得更加灵活从配置中可以看出，我们可以进行更加多样化的策略配置，可以配置支付方式的可用性，可以配置不同的排序，可以配置支付方式的推荐等等只要有了这个框架逻辑，很多想法，都可以添进去陈天宇宙支付学院chentianyuzhou.com你

很多场景下，我们会要求对方开发票，住酒店时，购买某种服务或者商品时，用于后续的报税或者报销这是我们作为发票需求方，而如果我们作为平台方，如何实现对用户的开票和发票提供呢？比如你是一家外卖公司，要给平台商家提供某项费用的增值税发票广义上去看，“票”的种类很多，不止是增值税专票或者普票，我们可以将一种“凭证”都可以认为是一种“票”，比如电子回单、消费小票等等他们实现的底层逻辑和方法是类似，可以共用一个抽象模型在要实现自主开票之前，我们要先确定这是一个什么“票”这张票的样子，也就是板式，票上需要展示的数据，这些数据来自哪里，是业务系统里还是从用户那采集得到如下图这张增值税普通发票，其中的纳税人识别号就需要从用户那里采集得到，在开通获得发票以后，又可以得到发票代码等数据因此，先分析你要实现的发票版式和数据参数，以及数据获取方式要实现一个开票系统，怎么做，要先“心中有框架”先把大的逻辑和结构搞清楚，再去分块去实现，从宏观到微观的过程，如下图框架首先就是“数据准备”要明确开的各个票种的源数据是什么，从哪里获取，是账务数据、账单数据、还是税单数据并且，该票种所需要的开票数据也不一定从一个地方就能完全获得，可能是一个字段来自一个地方，比如税号来自用户中心，从客户端采集的，而开票金额字段从账务中心获得因此，源数据是要“拼出来”然后就是开票的模式、发票的模版等基础配置，不同的开票模式流程不同，例如你要开“消费小票”那么就不需要发票服务商，完全可以自主闭环开出来，而要开正规的增值税发票，就需要依赖外部服务商所以，发票模式跟支付模式类似，对私和对公有区别，快捷支付和网关支付也有区别接下来就是开票主流程，所有票种的开具都可以通过这个流程实现，三大步：开票规则解析、开票数据封装、提交开票申请其中提交开票申请，类似提交支付申请，可能不同国家、不同票种要提交给不同的发票服务商发票系统要重点想明白和管理好4个核心发票的数据，就是最原始的发票单据，可能每个商家每个结算周期一条数据，这条数据记录了开什么票、开票金额是多少、商家的税号等信息开票的状态，每条数据的开票状态是什么，是待开、开票中、冲销了、还是已开票开票的能力，不同的票种或者接的不同服务商所需要的开票能力不同，首次开票、冲销能力、重开能力、下载发票能力、开票调整能力，这些能力的接入和实现依赖实际的需求最后就是开票历史，每一章开好的票以某种形式存储在数据库中，方便用户或者后台管理人员查看，pdf形式、xml形式或者是图片形式如果某票种需要接入发票服务商，那么就需选择一个适合自己的服务商，不同国家、不同票种可能适合的服务商不同但是，无论什么服务商，其服务接入逻辑是类似的，提供的能力也是类似的这一点跟接入支付渠道商差不多无论是接入哪家开票服务商，其实现的逻辑都如下图类似，下图以Gosocket为例，而且这家服务商是全球性质的，比如你接入了墨西哥这个国家，那么在另一个国家也有可能不需要重复接入，只需要修改几个传参、语种即可整个逻辑流程图里要搞清楚这几个主要问题开票的能力，图中包含了“申请开票”“下载发票”“冲销发票”三个主要能力然后就是通过开票结果对发票源数据的“开票状态”的更新，开票成功则更新为已开票、开票失败则保持“待开票”的状态，冲销成功以后将“已开票”状态更新为“待开票”针对不同的开票状态，可以进行不同的操作，例如自动开票、冲销发票、手动开票等然后就是下载获得了发票以后，将发票进行存储，提供给后台和用户查看和下载，或者邮件自动发送给用户比如我们在滴滴App内选择“开票”，勾选对应订单以后申请开票，就需要填写一个收票“邮箱”该邮箱，就会存储到发票系统的“用户邮箱”中，用于向用户主动发送电子发票好了，通过上面的努力，我们终于可以实现自动开票了最后一步就是想明白你要如何将发票提供给需要的用户比较常见的就是发送用户指定的邮箱同样，对于商家来说也可以在其后台提供发票自主下载的能力以上就是如何实现一个发票管理系统的方法论陈天宇宙支付学院chentianyuzhou.com你

在平台向商家结算的业务中，最终会有三个非常重要的产出物——账单、付款、发票商家需要知道一个结算周期内，自己的账单、付款、发票，三者有着紧密的联系，商家对账也是要核对清楚“账、款、票”的一致性账单就是提供给商家的本结算周期的交易记录，买了多少货、收了多少钱、退了多少款，以及平台抽了多少佣金，代扣代缴了多少税，本期应结多少钱等等付款就是根据账单结算的最终资金，把钱打到商家签约的结算银行账户中，商家就会拿着自己的账单来核对自己的收款，账单里告知商家要结算20万，那就应该收到20万的付款然后就是发票，这里的发票可以是广义的票据，比如消费的小票、增值税发票等，所以不同的款项可能要开不同的发票，不同的对象可能要开的发票也不同，而不同的国家需要的发票种类也不同，这要看这个国家此类活动需要什么税种税种也不是一成不变的，如下图就是在某国根据其法律要求进行的按期税改，从图中可以看出开票跟账是分不开的，同时开票跟付款也分不开开票就需要接外部的开票渠道，这个在不同国家也有不同的服务商，按其标准去接入即可，如智利、墨西哥等可以接入gosoket、vender等发票服务商其中有一个特别的税，就是增值税，平台收了商家的佣金，佣金是平台的收入，所以这部分是需要平台缴纳增值税vat，但是这部分平台可以转嫁给商家，这时候就需要帮助商家代扣代缴，并且帮助其开vat增值税发票上面介绍的是一条结算产出物的主线“账单、付款、发票”那么拆开看，账单、付款、发票还有更精细的属性，比如一个独立的小店铺和一个全国数千家连锁的麦当劳对“账单、付款、发票”的模式诉求大为不同也就是普通商家和连锁商家有不同的需求，所以我们将商家分成三个等级“KA、CKA、普通商家”KA就是大型连锁商家，无论是连锁酒店、连锁超市、还是连锁餐饮，普通商家就是一个独立的小商家，就一个门店；而cka就是介于二者之间，例如有十几个门店，但并非大型连锁还有品牌一说，一个KA下可能有多个品牌，一个品牌也可可能有多个连锁业务等等，有很复杂的关系同样，还有法人主体一说，有的多门店共用一个法人主体，有的每个门店是一个单独的法人主体，那么这样的话，就有了更复杂的组织关系，也会造成结算关系的复杂，对平台来说，账单生成、付款处理、发票开具的模式就复杂了比如，对于大型连锁来说，就存在总部和门店的关系，比如有的KA要合并付款到总部，总部统一收款，那么账单、发票要进行合并，但是每个门店又要统计自己的经营，所以每个门店又要单独的账单信息；而有的KA可能需要单独付款给每个实际经营的门店，但是要给总部合并账单上述的账单生成，结算付款，发票开具都有独立完整的主模块而如何生成账单、如何进行付款、如何开具发票，就需要考虑是不是需要合并，合并那一块业务此时就需要一套规则的配置，来促成这一“是合是分”的实现其实在合并上有很多合并逻辑，主要是要抽象出“合并维度”，我能实现以谁为合并维度，或者按照法律法规我必须以谁为维度，或者按照法律法规我不能突破什么维度而合并，例如我能不能突破法人主体而合并付款给总集团？这些都需要财税法团队的支持以满足当地的法律法规和商户的诉求假如，我们合并的上限是法人主体，只能针对同一法人主体下的门店合并其付款和发票，也就是多个门店的营收可以一笔付款，和开一张票；但是账单我可以任意合并出具；当然其他按照品牌合并或者更多维度也可以实现，方式类似这样的假设之下就需要构建一个门店合并关系我们通过配置化实现这层合并关系，在账单生成、付款单生成、发票数据处理时，调用这个关系，去判断该门店是否在一个合并关系中，该业务是否需要与其他门店进行合并这里的合并关系，是建立一个主体下的多个门店之间在“账单、付款、发票”三个业务之间“是否合并”的关系，如下图中的合并关系，仅仅是合并了3家门店的付款，而发票和账单并没有合并关系所以还是按单门店执行那么为什么会存在一个法人主体下仅部分门店合并了付款呢？这里的合并诉求要看商家具体经营情况，可能是这3家门店是同一个运营团队在运作，而该企业是以运营团队为单位进行核算的如下图的配置关系规则，明确了哪些门店进行了合并，在什么场景上合并了，这里的场景主要是3个，就是“账单场景、付款场景、开票场景”在新增合并关系时，必须选择一个法人主体，该法人主体下的门店可以自由组合这时，一个法人主体下就可以配置多条合并规则，一条合并规则可以约定了这些门店是合并了什么场景账单、付款、发票都是独立的业务，他们未来都会有独立的文章单独介绍，各自的详细业务介绍本文就不过多说明了本文主要说明的就是他们合并的原因，合并方法，以及合并关系的逻辑实现陈天宇宙支付学院chentianyuzhou.com你

我想大家对保证金都不陌生，从最早的淘宝开店要缴纳店铺保证金，然后的共享单车要缴纳骑车押金这也是平台为了增加商家、用户的信用等级或者风险兜底，而向收取的一笔担保资金车坏啦、商家被投诉啦，这笔钱就排上用场了平台一般会基于不同场景，缴纳不同类型的保证金，这就是保证金的种类所以在设计保证金系统之前先了解清楚贵司的保证金种类以及拓展性01.定种类比如内容分销保证金，是基于分销市场场景而设立的，主要是为了提高分销商的信用担保再比如店铺保证金，是为需要开店的商家设立的，为提高店铺的信用，兜底平台和用户的基本权益因此，不同的业务种类或者普通的场景需要设定不同类型的保证金就需要一个“保证金类型”管理，来不断地拓展保证金类型02.立规则有了保证金类型以后，接下来就是保证金的缴纳规则，也就是制定一份规范谁，在什么时候，什么地方，做什么事，要缴什么保证金，缴多少钱比如可能不同的城市消费水平不同，那么缴纳的金额可能就不一样不同的城市可能不一样，比如同样是跑滴滴，在一线城市缴纳的保证金和一个五线城市就可能不一样不同的服务品类可能不一样，比如同样是在一线城市，跑快车和跑专车要缴纳的保证金金额不一样比如下图是某电商平台针对不同品类及商家主体类型设定了不同金额的保证金为了通过系统化实现上述保证金的充值、缴纳、管理等一系列业务，就需要一个保证金系统接下来，我们从业务框架、产品架构、具体模块设计展开对该系统的设计分析要先搞明白，我们做这个系统要实现哪些业务种类和对外能力系统没开始，业务先想明白，业务想明白了，系统也就清晰了01.关系架构第1个架构是关系架构，我们看清楚整个系统与外界“基于服务”的联系，谁会通过什么服务来与我建立关系，我就明白了，我要做这些能力从图中可以看出，保证金需要依赖商家中心的通知进行开户，然后基于自己的规则告知商家需要缴纳什么保证金，缴多少钱，以及后续的业务发生后对保证金缴纳情况的检验查询、违规扣除、风控冻结、审批等一系列的业务关联02.业务架构第2个是业务架构，通过这个架构看清楚保证金系统与各系统之间更清晰的业务关系从图中可以更清晰的看出来，保证金的什么服务模块为哪些上下游系统提供什么样的服务，比如为钱包提供查询服务、为支付系统提供交易服务、为商家中心及风控系统提供基础服务，而自己的所有服务都是基于保证金规则和账户为基础03.产品架构第3个架构就是产品架构，看清楚保证金系统的所有功能模块，便于后面的详细产品设计和项目落地整个保证金划分为5大模块，分别是保证金服务管理、保证金规则管理、保证金交易能力管理、保证金账户管理、保证金操作记录这里要特别说明的是保证金账户管理，如果说保证金账户由账户中心承接，那么这一部分就应该是“保证金账务处理”的管理，与账户中心形成交互，而保证金系统就成了一个单纯的业务系统，管理保证金业务相关的事务接下来就应该针对上述的每一个模块做详细的产品设计01.服务标准化对于保证金服务模块其实就是抽象出的服务种类，以标准接口的形式提供给外界系统调用例如开户、销户就是来申请开通保证金账户，并匹配对应的规则，知道这个账户需要缴纳多少金额的保证金交易服务就是充值、提现、扣除、解冻、冻结保证金的能力，这是保证金能力的核心所在，毕竟有了保证金你是要辅助业务做事情的，去兜底的状态查询是保证金是否已缴纳的查询，提供给业务侧做业务的判断，比如商家要上架商品时，需要判断有没有缴纳足额保证金，以控制商家能不能正常上架商品账户查询是提供给钱包使用，获取保证金的账户余额、流水数据报表服务是提供给财务使用，用于保证金业务的会计记账02.规则配置化保证金规则，关键是规则模型前面也介绍了，不同的业务及场景需要缴纳的保证金种类和保证金金额不同，所以需要一套规则配置工具，灵活的配置出保证金的规则条目这里将规则引擎设置成2层模式第一层是规则模版层，是为每一个保证金场景，设置一个规则模版，也就是这个场景下的保证金规则需要哪些维度的参与决定比如条目1的含义就是分销保证金的规则只需要配置一个参数即可，也就是品类，不同的品类保证金规则不同所以，一个条目能配置出多少条规则，跟该条目的参数数量以及每个参数的枚举值有关系所以需要一个定义“参数”的配置，例如增加商品、用户等级、时间等各类参数，这里就不赘述了在新增条目时，可以为每一类保证金类型增加一个条目，为该条目选择需要配置的参数有了条目以后就是为各类保证金场景设置规则了比如店铺保证金的条目是002，那么设置店铺保证金规则时就需要配置“业务线、品类、城市”3个维度的元素，他们不同保证金规则不同03.交易能力按需化这里的能力就是交易的能力，充值、提现、冻结解冻、扣除等操作保证金账户的能力这个能力都可以做成标准化的交易能力，当然可以基于实际需要去建设，比如冻结能力，如果没有冻结场景，那就不需要去建设这里特别说明一下，保证金的冻结和解冻可以做成自动化的任务，在约定好冻结和解冻的条件，定期巡检全部保证金账户，然后执行冻结或者自动解冻04.账户管理可选择这是保证金的核心，前面也说了，可以保证金系统自己管理，也可以交付给账户中心承接，不同的模式下，保证金的账户管理要做的事情不同如果是保证金自己管理自己的账户，那么就需要做一个基础的账户模块，有余额、流水、开户销户、出入账等相应的能力05.操作记录不可抵赖最后就是保证金的操作记录，这里的操作记录更详一个保证金系统的日志，记录的谁、在什么时候、对系统里的那个模块做了什么好了，以上就是保证金系统的建设方法论，如何从0到1把这个系统做出来，你学会了么陈天宇宙支付学院chentianyuzhou.com你

滴滴又崩了，全网都在说这个事，我在同事圈刷了半天，挺热闹的别管谁的问题，先解决眼前的问题这不，我家财务大姐也疯了，倒不是因为崩的事，而是日报的事情资金部的王姐请我喝大杯咖啡，然后一把鼻涕一把泪的对我倾诉：“目前资金部每天到几十个微信、支付宝等收款账户和几百个对公账户中下载资金账单，进行人工加工处理，得到老板资金日报；人员成本大，耗时耗力，准确性差，你能不能帮我们想想办法，把我们解放了”就在一瞬间一个念头就击中了我的心弦：对账中心目前可以通过支付平台的接口或者银企直联接口获取到各渠道的资金账单，完全可以自动化生成资金需要格式的资金日报，可以通过后台下载或者邮件发送的形式提供给他们资金管理（司库）系统虽然已经提上日程，但目前大部分资金职能无法通过系统实现，但对资金管理的目标应该建立正确的认识，我觉得要逐步实现这4点能看见，能管住，能调动，能用好能看见，就是要能看得见账户余额，要能看得见账户流水，要做到这一点可以“资金可视率”作为抓手能管住，就是钱不能乱花，没有预算就不要花，有预算就不要多花，花的任何一笔钱都要做到财权、事权的审批和程序完整，任何一笔付款都需要有付款指令才能出款调的动，就是要有成熟的资金池，实现资金的上划、下拨、调拨，管理好资金的流动性用得好，就是提高资金周转效率，做好投入和产出比，不过多占用资金，让资金效益最大化真正实现资金日报自动化还有很长的路要走，但在现阶段可以折中实现资金日报的线上化，先解决手工问题那么目标就明确了通过系统自动实现资金日报的样式为什么说是“样式”，其实就是只要结果，不管过程，只按资金组的日报格式产出日报报表，不解决数据可追溯等问题简单地说就是，将资金数据拼成资金日报，不与业务数据联动那首先就需要先看看资金日报什么样，从结果往前推实现路径整个资金日报有2张报表一张是按照费用维度的汇总报表，每个资金类费用生成一条数据一张是按照账户维度的汇总报表，每个资金账户生成一条数据，很明显上一张报表按照账户再次汇总就可以得到下面的报表资金层的费用类型总结下来大概有以下这些保证金、测试款、订单收款、订单收款-券包、订单收款-对公、会员费、商家激励、微信手续费、支付宝手续费、预付卡充值、资金内转、资金内转-充值、资金内转-提现、商家提现目标报表清楚了，下面要突破的就是如何得到这两张报表资金日报的全部数据来自银行或者三方收款等资金账户的资金账单这就好办了，源数据的问题就解决了，对账中心通过银企直联或者文件接口已经拿到了全部数据，并且已经完成了解析存储那么，这里发现一个关键点，就是如何从账单数据转化到资金日报数据资金日报里的账号等基础信息可以通过主数据维护实现，本身对账中心的对账单存在银账户号，可以作为唯一标识而资金日报里的“资金类型”目前源数据以及主数据里是没有的，如何实现我们发现，资金类型可以通过账单中的“组合字段”映射得到，这个问题就突破了比如支付宝账单中的“在线支付”就对应了资金日报中的“订单收款”支付宝账单中的“收费”就对应了资金日报中的“支付宝手续费”以此类推建立一个映射关系能力，配置从资金账单数据到资金类型的映射逻辑，将资金类型字段拼到资金账单中如下图的映射关系维护，可以实现从资金账单到费用类型的映射关系配置我们从新增中可以看出来，这里的条件字段是可以灵活配置多字段去映射的，比如图中的账户号、商品名称、业务类型、以及附加字段图中的示例映射关系含义是，当账单数据是“账户号=5464、业务类型=在线支付”时，“金额”取收入金额、收支为“收入”方向、费用类别为“订单收款”这样，我们就建立了从资金账单数据到资金日报数据关键字段的映射然后，对账中心每日凌晨将解析好的账单数据，通过映射拼入费用类型以后推送到账务中心通过上面的分析可以得到这样一个逻辑关系图，从对账中心获取到资金账单开始，进行数据的解析、映射拼接、推送账务生成资金凭证、再拼接主数据得到最终的2张报表整个业务流程图如下图所示如果要落地这个项目，可以抽象出下面的功能列表用于方案的设计我们用一个数据示例来说明，怎么样从源数据通过映射一步步走到了我们的余额报表，进而生成资金日报的在对账中心获得了资金账单数据分析账单数据的数据结构，建立与资金费用类型的映射关系我们设定每日凌晨4：00的任务，将解析完成，以及映射完成的结算数据推动至账务中心，按照任务列表中的账户号推送数据推送至账务中心的数据是已经拼接上资金费用类型的数据，也就是账务中心的规范的“业务凭证数据”然后对上述数据按照“账户号+费用类型+日期”三个维度进行汇总，得到按照费用类型维度的明细汇总数据按照账户号维度将资金凭证数据再次进行汇总，并生成期初、发生、期末余额上表中有一个银行账户信息是通过账户信息映射规则拼接上去的，规则如下在规则里是通过账户号实现映射，也就是资金账单中的商户号或者账号，并且为了获得最初的期初余额，需要配置账户的启用日期以及启用时的期初余额，这个一定要准确这样，利用对账中心和账务中心的联动，初步实现了1.0版本的自动化资金日报，大大释放了资金组的手工量资金部的王姐又请我喝咖啡了，这次是特大杯，然后一把鼻涕一把泪的对我说：我就知道，你可以！系统崩了，修就完了，心态别蹦！扫码访问陈天宇宙支付学院与110427位小伙伴一起学习

产品经理是为解决问题而存在的，只不过更多的以“产品”为武器，但无论什么产品，都应该回到企业的“场景”里，给出最优的解决方案这个方案要不是让糟糕的当下变得美好，擦干净过去的屁股，要不就是让美好的未来变得可见今天讲一个我的真实故事，最后附上一个别样的账户架构图初到某厂担任中台的支付清结算部分的产品负责人，总监让我进行整个清结算中台的规划，然后团队内部进行宣讲，因为中台战略刚开始，整个部门并没有真正中台化的系统刚到职场，领导让做长期规划，不要慌，看我怎么做这是个大工程，因为初来乍到，对公司业务和产品体系一无所知，所以这里就用到了一个方法，这个方法就是这篇文章《百万年薪，我做对了这8件事》里的“02新岗位初期的蜕变心法”领导想要一个看得见的未来，让他的领导看见，所以给他就是了第一件事，向组内成员搜集了相关产品介绍，公司的业务介绍，以及引荐一些业务方进行拜访沟通，并约大家了解过去、现在所面临的问题和挑战、业务方的痛点，开通主要系统权限进行体验第一周结束后，围绕整个清结算的业务范畴，以及被框入清结算中台的相关系统做了现状说明，就是下面这张图要想看见未来，要先看清过去，未来只不过是在某种力量的推动下，历史的延续，而我们就是那股原动力当前有5大问题：系统建设分散、业务耦合严重、产品配置化弱、数据准确性差、服务抽象度低可以说，旧系统烂的不能再烂了，是在原地基上修盖，还是另起高楼我喜欢玩大的，如果基于旧系统构建大中台，那今后的日子除了“痛苦”就是“折磨”所以，一刀切，保持旧体系运行，另起高楼，并行迁移我不背历史包袱，同样中台也不应该背历史包袱问题看清了，无非就是系统分散要集中，耦合严重要拆开、配置化弱做配置、数据不准做对账、服务抽象度低服务原子化基于这样的理念，我规划了五大中心，分别是统一清算中心、统一账务中心、统一账户中心、统一结算中心、统一对账中心除了基础的中台服务颗粒以外，在未来基于这五大中心向业务提供成套的基于业务大型场景的资金解决方案，包括钱包解决方案、商家结算解决方案、B商家结算解决方案、保险解决方案、离职清算解决方案、保证金解决方案、佣金资金解决方案这样的解决方案模式，将中台触手直接伸向业务前端，更深一步为业务赋能，同时也扩大了中台的业务边界为什么要扩大边界，眨下眼睛，会心一笑，你懂得！在这套规划里有一个非常基础的基础，那就是账户中心，因为一切的资金类解决方案全部围绕该系统构建出来为了在当下即能看清未来，为了让团队看到我的雄心，便产出了标题中提到的“这张压箱底的账户架构图”这张图的特点是，不仅是表达了账户的基础能力部分，还将资金解决方案这一层以及服务的业务场景和业务边界描述清楚了有时候我们不仅要表达清楚，我要做什么，还要向全世界宣告，我为谁而做，因为这样，你才能收获信徒我们的成功不是我的产品做多好，这只是我们的小成功；而是，你服务的客户多幸福，这才是产品的效果，这才是企业的大成功就是下面这张图，这张图你可以拿去直接用，根据自己公司的业务进行简单的修改即可，非常实用，也非常有指导价值，可以看清楚要做的事情以及要做成的模样整张图有2大部分，上半部分的业务层和下半部分的账户层（1）业务层是统一账户中台要服务的业务场景以及场景下要服务的用户群体了解你的用户群体，是为了洞悉他们的喜好，处好未来的关系，毕竟不能让他们请你喝咖啡，就会有人撒你一脸灰这一层包括了钱包业务、财务处理业务、收银台中的余额支付、对公结算平台、账户中心操作台等（2）账户层账户层就是统一账户中心，从图中可以看出包含了3层底层是账户基础能力层，构建账户的基础能力，例如账户主体管理、账户管理、余额管理、交易能力管理、账户流水管理等跟人一样，先修炼好内功，有多大能力办多大事，作为中台，能力很重要中间层是服务层，也就是向外暴露出的账户基础服务，像主体变更、账户开通、信息查询等，这一层可以直接提供给账户内部使用，又可以直接提供给外部业务系统使用服务化，就是让用户看得见，可选择，可组合，可定制再往上一层就是资金解决方案层，是对服务能力的打包，组装出可以直接应用到场景的解决方案，比如结算方案、对公结算、企业支付通道等解决方案就是融入业务场景，更容易让用户共情，毕竟我们有什么能力不重要，重要的是“用户知道他有什么事能够被我们解决”所以解决方案其实就是我们站在了用户视角，使用了用户语言接下来3年的时光，都奔跑在这条路上在我离开的时候，真的是功成名退了，完成了全部规划的建设最后一个季度，我的需求量只有2个，但依然拿了A为什么，因为这五大中心都是我从0到1新起的高楼，标准化、配置化、服务集群的抽象做的太完美了只有了解过去，才能理解当下，才能看清未来只有看清了未来，才能放开手脚一图制胜！职场，无非就是通过自己的产品，相互成就扫码访问陈天宇宙支付学院与110427位小伙伴一起学习

昨天一位读者朋友问了我一个问题，很好的一个问题，直接问我方法的方法，我曾经发布了一个很好的产品方法，而她，对我怎么得出那个方法产生了浓厚的兴趣学习就应该“贪得无厌”问题中的资金流和信息流分析方法指这篇文章““信息流”和“资金流”分析方法”这篇文章我给了大家总结了一个通用的分析方法，如果你还没看过可以先看下这篇文章，然后继续往下看让过去的经验和当下形成链接所有的模型基本都是通过观察大量案例，进行分析、归纳、抽象得来，再通过新增的案例不断去迭代这个模型这个过程依赖很多知识和方法储备，他们相互作用产生，因此大量的阅读和案例积累必不可少，也可以说这是一个量变到质变的过程，看得多了，就会发现其中的规律因此，也不要指望做了一个功能就要抽象出一个成熟的模型，但倒是可以抽象出一个1.0，能够满足当前案例的模型，然后再去观察更多案例，从而迭代修正1.0的模型因为一个具体案例，他的模型是固定的，众多案例才能从特殊性归纳出普遍性所以，做一个功能或者项目，就抽象出一个小模型，然后等着新的案例进来，对模型逐渐迭代，这个方法可以让自己养成归纳的习惯，前后的经验建立的一个继承、融合、升华的机制比如做了一个需求，财务找你要增加一个批量修改的功能，你问他为什么，他告诉了你原因，你认可了，然后看了下同类产品怎么做的，做好以后你拿给财务看，他觉得可以，你就开始推进研发了......这是一个具体的实施，那么其实从中就可以归纳出一个简单的产品的生命周期的流程：需求进来、需求评估、需求调研、方案设计、方案确认、投入研发......你就可以把它固定下来，做为自己的工作方法1.0，然后又接了很多需求，发现有些环节并不能完全适应，那就可以进行调整这样的习惯和模式，会让自己的经验存在继承性，随着时间的推移，能力才会指数级增长因此，实时归纳和融合当下，是链接过去经验和推进未来进程的有效方法，让成长形成一种机制，让这个机制加速成长没有复杂的方法，都是简单的道理开头的问题中有4个关键点可以逐一解答第1点：怎么想到要分析的要素这里的要素就是指“支付场景、参与对象、参与对象的账户、支付方式、支付类型、清算模式”我不是想到的，而是归纳出来的，所以这里我的方法就是“归纳法”，其实就是先把所有涉及到的元素都拿出来，然后用放大镜看，进行分类对比，发现哪些对资金流和信息流有影响的要素先拿一笔具体的支付进行分析，然后铺开看里面有什么，然后就进行发散，比如我在吃饭时扫码支付、京东商城购物、交水电费等等，我发现不同的支付场景是会影响资金流和信息流的，那么就把场景先拎出来，这是一个影响因素，不同场景下的支付信息流和资金流是不一样的然后信息流是信息的流动，是一条线，流过一些地方，那一定是从一方流到另一方，所以参与对象肯定要考虑了，对于支付来说参与对象有很多，收付款人、支付机构、清算机构等剩下的参与对象的账户，因为是管理资金，支付方式，支付类型等都会影响资金流的流动模式所以，对经验进行归纳总结，至于怎么归纳总结，这是一个基础的方法，大家可以去深度研究一下这个方法就像面前放了一堆五颜六色的豆子，你会自然而然想到“颜色”这个要素，红色、黄色、绿色进行分类以后，你发现颜色是这堆豆子很重要的特征，这里就是通过分类看出了颜色这个要素，而豆子的形状都是一样的，所以并不是一个重要的特征，就可以抛弃掉，除非你发现里面有方形的豆子，那么形状就会引起你的注意第2点：哪些因素会影响这个其实就是找不同，在众多信息流和资金流的结果中找到大家的不同，这个不同可能就是影响信息流和资金流的因素比如你发现，用微信零钱支付和微信绑卡支付的资金流差别很大，那么支付方式就是很重要的一个影响因素所以，多拿出案例，分析他们的不同，是什么引起了他们的不同，那么这个影响点，就可以抽象出来作为一般性这就是归纳总结中提炼关键要素的方法第3点：怎么建立这个思维方式这个方式很简单，就是归纳和推演的方法，从上学就学过这个方法，只不过可能不会去深究，日常生活经常用，但不会过多去关注这个方法本身比如，你四五天都发现每次下楼倒垃圾，都会有一只白猫路过那么你就会推断今天下楼应该还能看到，这就是推演的过程然后你告诉家人，每天早上9点，楼下那个小路会有一只猫路过，这个就是归纳的过程把大量的特殊性案例进行归纳，得出普遍性的结论，并利用这个结论去推演出新的特殊性所以，并没有什么高深的方法，就是最基础的科学方法只不过，你要多用，形成习惯，熟能生巧因此，我可以说这里使用了“通过归纳特殊性而得出普遍性的方法”怎么归纳，有详细的科学方法，这里就不赘述了，只给大家介绍我用的方法论是什么，不是我特殊的方法论，而是已经很成熟的方法论，我把他用到了写作上，归纳总结了我的工作经验所以，要学会归纳第4点：换成其他的内容，而不是支付这个就是普遍性到特殊性的过程了，不是信息流和资金流分析方法的普遍性和特殊性而是“用归纳法得出信息流和资金流的分析方法”这个用归纳方法论使用技巧的特殊性归纳出“如何使用归纳法去得出一个模型”的普遍性所以，这里就是用归纳法去归纳一个归纳法让经验形成规律，让规律形成链接有很多基础的方法，不要忽视他们我们在学生时代学过很多优秀的科学方法上学没用么，有用，最大的用处就是我们学到的基础的科学方法比如归纳法、排除法、推演法、组合法、对立统一关系、从量变到质变等等要灵活地学以致用所以说，开头的问题也可以这么回答利用特殊性归纳出普遍性，再利用普遍性推演出特殊性一个很基础的科学方法，小学就学过，只不过我们忘记了，怎么加强这个方法，可以读读逻辑学比如看了很多人都会吃饭，所以我们归纳得出“所有人都会吃饭”因为“所有人都会吃饭”所以推演出某岛上的人也会吃饭，而岛上四面环海，所以又可以推演出“吃的饭大概率以海鲜为主”归纳法的好处就是可以通过特殊看普遍性，但是受到了样本数量的限制，所以是有局限性的，得出的普遍性也会随着新样本的出现而得到不断地迭代优化这就是自我的迭代的过程而要想不断实现自我迭代，就先从迭代出1.0开始，然后去吸收更多的样本案例进行升级迭代出2.0、3.0......因此，归纳出普遍性的结论也是量变到质变的过程而归纳法和推演法又是对立和统一的关系对立性体现在“一个是从多到少，一个是从少到多”而他们又是统一的，体现在相互依存，推演离不开归纳，只有通过归纳特殊性得出普遍性才能进行推演，从普遍性再次得出特殊性所以，最后我可以这么回答最开始的问题利用一定量的特殊性工作案例或者样本归纳出普遍性实现从量变到质变的过程，再利用发生质变的普遍性推演出大量的特殊性指导工作，实现从质变到新的量变的过程，从而实现归纳和总结、质变到量变、特殊性和普遍性的对立统一所以不要忽视基础学科中的基础方法，因为都是普遍性的理论，是对自己最好的科学思维的训练，让这些基础科学方法之间形成链接和应用场景的迁移最后，看了很多别人的方法论和总结，不要忘了自己在学生时代学到的那些最基础的科学方法，最伟大的科学思维的训练术很重要，但道不能被忽视大道至简，繁杂的花里花哨的术的背后，一定是最简单的道理用最基础的方法，让自己的经验形成规律，让规律形成链接，通过链接迭代自己扫码访问陈天宇宙支付学院与110427位小伙伴一起学习

全文共16846个字，建议先收藏慢慢看在职场不能总是埋头干活，还需要掌握一些职场沟通、协同、向上汇报等的软性技能，特别是专家级别，最终建立个人影响力，收获更好的职场结果。本文将从8个方面介绍一下我是如何经营自己的职场的。这8条心法，让我这样一个普通产品人加入了百万年薪俱乐部。回头看，发现，原来我做对了这些事！—用不同的思维模式，做好产品设计—在设计产品方案时经常会遇到两种思维方式，一个是基于功能的设计思维，一个是基于效果的设计思维。二者会有明显的差别，功能是可以被定义的具有明确规范的功能单元，而效果则是产品的目的或者是考量好坏的标准。1.1两种思维的区别习惯基于功能设计思维的产品经理在沟通或者表达时总是把功能、要做什么、做成什么样挂在嘴边，基于功能的好处是“明确”，比如你要做一个提交的“按钮”，这个按钮是非常明确的，无论你用什么颜色，什么尺寸，放在什么位置，都无法挣脱“他是一个按钮”的外壳。功能的选择本身是无穷尽的，这就意味着，不同的组织或者产品经理会有不同的选择，你觉得圆的好，他觉得方的好，你觉得放左下角好，他觉得放右下角好，在功能思维指导下，大家更容易产生争执和辩论，原因就是功能的可选择性很多。产品本身存在的意义不是要设计一个账户系统，账户系统里有余额，余额变化了有流水，而是这些已经被选择的功能因为什么而存在，为什么需要余额，谁需要，在什么时候需要，为什么需求，需要什么样的形式。所以产品本身是为解决问题和支持业务而存在，而不是功能本身，如果你不做账户余额而可以解决要解决的问题，那你就可以不用做。

全文共5889个字，建议先收藏慢慢看掌握了理论知识以后，应用于实践是对理论考察的最佳手段，本章以红包和钱包设计为实际案例，了解支付中架构和逻辑在设计中的应用。12.1红包设计发红包，领红包，普通红包，拼手气红包，在用户使用层面大家都不陌生，因为经常会用到红包这个功能，但红包底层的支付流程及算法规则、涉及的支撑系统都有哪些，估计很多人并不知道，本小节就分析一下“红包”背后的秘密，掌握如何设计一套红包体系。12.1.1红包概述红包对于用户来说是一种娱乐手段、生活工具，对于企业来说是一种营销手段，大家最熟悉的是经常使用的微信红包，像钉钉、脉脉等很多应用内也都有红包模块。红包实质上是用户账户之间的“转账”能力；一个用户的账户扣一笔钱，拆分后转给多个账户；至于每个账户转多少金额，就是红包金额的算法，普通红包简单，平均总金额就行；拼手气红包稍微麻烦，既要保证红包最低金额，又要保证金额随机，已经领过的不能再领，过期的红包不能再领且要退回发红包的账户，如图1所示。

业财一体也常说业财融合，为什么做，怎么做我提炼出的这三点可以高度概括业财一体化，打开业财一体的大门从圆口到方口，业财的使命业财一体是连接业务和财务的连接器业务是非标准化，不同的领域、不同的公司、不同的部门、不同的系统都各不相同财务是标准化，有严格的会计准则和法律法规，这也是为什么有全球通用及国内主流的会计软件的原因实际情况是业财分割大部分企业的业务是业务，财务是财务，业务按照财务要求提供数据报表完成记账而业财一体，让业务和财务在数据层打通了怎样将非标的业务与标准的财务连接起来呢？这就是业财一体的链接模型，从各种形状的口转换成财务的方口业财5点模型，把握落地路径从圆口到方口是从信息化系统层面对业财作用的抽象而要完整的把握业财一体，或者说是去接手一个业财一体的项目，还应该再增加2点认识，构成5点模型为什么要做业财一体不同行业，不同公司，不同部门和人员目的不同，要想做好业财一体顺利推进，那要了解各个角色的需求是什么公司想上市老板要通过业财一体吸引投资人财务想改变手工做账，提高工作效率业务想摆脱财务对业务的牵制，打通关键数据产研也有自己的需求当然，这是个决定要做就困难重重的项目，每个部门每个人都有自己的小九九，业务要投入资源配合你，财务害怕你优化掉了他们的饭碗......总之，知己知彼，事情总会更顺利一些如何实施，开展工作那么，要开始做业财一体，怎么下手，如何落地，这里给大家一个参考路径选好切口，打通数据业财连接，从哪里连接？你要数据，我给你什么数据？从业务到财务也是条条大路通罗马既然要做业财一体，那么财务那一头至关重要，它就像一个水库我业务的水要灌进去，是打通一个管道直联水库，还是建立一个车队，长途运输所以，选切口目前市面上有成熟的业财一体化解决方案，企业可以选择将订单、支付、报销、合同等业务及数据直接对接解决方案的相应模块，灌入数据，自动业财一体这是业务的连接，业财的自动实现当然，每一个解决方案模块都有成本，全局采购不是一般企业可以承受得了的，例如采购模块、生产计划、车间管理、财务管理、仓储管理、销售管理、人力资源管理等所以，还有一种方式就是直接连接财务模块，业务自研直接将业务数据转换成财务凭证数据，对接财务模块，业务部分保持自研系统这就是在中间的转换环节，做好数据转换，也就是会计引擎只有身在其中，方知何去何从扫码访问陈天宇宙支付学院与110427位小伙伴一起学习

全文共12056个字，建议先收藏慢慢看账目核算是财务工作的必要部分，随着线上交易体量越来越大或者说对财务自动化线上化的效率提升需求越来越高，为了提升核对效率以及准确性，要将核对业务系统化、线上化、自动化。如何构建设计一套不同业务场景下的对账系统是本文的重点。1.对账概述日常生活中每天都在对账，比如去餐馆吃饭付款，会对老板说一声“老板，钱付过去了”，老板检查收款情况或者听到语音播报后回复一声“好嘞，下次再来”，这就是一次最简单的对账。再比如在淘宝开了一个店铺，每个月几千单的交易、发货；次月末都拿着所有的订单明细和支付宝收款记录逐笔做一次核对，保证发过货的订单都收到款了，这是一次更复杂的核对。1.1对账的定义对账就是“账证实”的核对，“账”是账目，“证”是凭证，“实”是实际资金或者商品。常见的核对模式有三种：账证核对、账账核对、账实核对，确保账证实两两的一致性。如在饭馆吃了一碗面，其中点菜单就是原始凭“证”，付了10元钱是“账”，老板电脑记录10元是“账”，老板看到账户中余额增加了10元是“实”。从财务范畴来看，证就是会计凭证，比如发票、小票、出货单、收据、交易系统的支付记录等都是原始凭证；而账呢就是财务的账目，账务系统的账务记账，金蝶的科目余额等都是不同的账目；而一笔交易会记录在很多的环节，比如账务系统，金蝶等。

收银台大家都不陌生，但有一个有意思的另类“收银台”，你可能稍有耳闻，我暂且称他为“还款收银台”为啥有这么个玩意儿在经营过程中，因为逆向交易或者罚款等业务，会造成商家的欠款，为了资金安全降低坏账风险，及时收回资金，需要给商家提供一个用于偿还欠款的渠道这就是“还款收银台”了当然了，有了欠款也可能要做一些风控措施，比如延迟结算、禁止接单、强制下线等等，这里就不做详细介绍了，大家可以针对该问题思考一下有何与众不同之所以说它另类是因为除了可以进行通常的直接支付偿还欠款以外，还有一些特殊的偿还方式，比如保证金、以借抵债等等整个收银台可以嵌套在用户钱包里、商家端操作台、运营后台，因为还款的触发除了用户自己可以发起以外，某些时候内部员工也可以操作发起来来来，晒出来看看以钱包内发起为例，我们看整个业务框架先看钱包里的还款主流程不好意思，你欠钱了有了欠款要在钱包里进行通知，弹窗、余额为负等等方式都可以，欠钱了要让用户知道，并且告知后果，以及怎么样偿还这笔欠款这个就像我们的水电费账单一样，通知用户是第一步如果这不是一次恶意欠款，用户可能会觉得，我后面还要持续经营，那就还了吧欠钱不用怕，你可以这么还当用户选择去偿还欠款时，下一环节要解决的就是怎么还的问题，也就是有哪些偿还方式这就到了我们要说的“还款收银台”了是不是跟常说的收银台类似，唯一不同的是其他方式有点特别直接支付，又快又酷最原始的手段就是直接支付这笔欠款，这与普通的支付没有什么区别，唯一的差别可能就是支付的款项不同，支付成功后要去核销欠款，恢复商家或者用户的正常活动支付环节可以复用已有的收银台，不需要过度设计和开发，用户选择直接支付的微信或者支付宝支付时，可以跳转到收款收银台完成支付保证金，你的钱还你的债除了用直接支付以外还可以提供更加多元化的偿还方式，支付可以大胆想象，不仅可以是资金的转移，只要有价值都可以拿来做支付，本质就是价值的交换或者转移而使用保证金支付，就需要保证金系统提供服务支持，这里需要保证金系统提供至少2个服务余额查询服务：可以根据用户ID，查询出该用户的保证金余额扣除服务：可以通过账户ID，直接扣除保证金余额所以，你要想做还款收银台，那要寻求的支持方还是挺多的而用保证金还欠款，需要不需要运营人员在后台审核这个要看具体情况，如果不需要审核的话，就如下图直接就成功了，如果需要审核，那需要一个中间页“审核中”的过渡页保证金抵扣了欠款，在保证金系统内或者账户系统内，保证金的账户会生成一笔账户流水，即抵扣欠款以上就是这个另类的收银台工作中，总会有一些幺蛾子场景，非主流需求这时候，以毒攻毒，方见奇效产品不是目的，解决问题才是王道！扫码访问陈天宇宙支付学院与110427位小伙伴一起学习

最后，银行内部人员可在对账不平报表查询记录，核对对账不平原因，确认不平后可发起差错调账处理。汇总对账结果示例明细对账结果示例6.总结归纳

部分通道有预先备案的业务逻辑，未备案主体无法进行交易。备案过程可能有api或人工，api模式也行可以设定自动备案逻辑。但是无论那种方式，都需要有页面进行备案信息管理。通道备案管理，参考页面：

一个人的整个职业生涯一般会经历多家公司，到一家新公司，上任一个新岗位，加入一个新团队，接手新的工作内容；最初的2周到1个月是最关键的时期高效率接手，一鸣惊人只需3招，成为最耀眼的“新人”这个时期我想重点要做好以下三件事情；这三件事情让我们在新的工作岗位上快速获得对工作思路，对岗位，业务的熟悉，未来的规划，工作的节奏，内容，产研的配合等一系列工作必需品的掌握......知全貌，定乾坤快速掌握公司的整个产品体系，包括架构，业务流程，负责团队；从用户到商家，从收银台到支付渠道......明白相关系统之间的职能边界和上下游关系以及数据交互逻辑这对一个新人来说至关重要，“不识庐山真面目，只缘身在此山中”，在把握一件事之前能优先掌握其全貌，从宏观逐渐到微观的过程是最顺心的过程，为什么，因为舒服；心中有更大的世界，才不会因为鸡毛蒜皮的小事而一头雾水所以说，如果我们到一家新的公司新的岗位，第一件事最好是先了解公司的全部业务线情况，然后去找老人或者历史资料掌握公司的整个产品体系，自己画一个公司的“产品全景架构图”，不要小看这个图，这个图会极度的加快你融入新岗位的进程立当下，绘蓝图掌握了整个产品体系以后，我们也就找到了自己所负责产品的位置了，在这个位置上，你的产品集群所承担的职责，指标，要做什么基本就很清晰了；然后就是针对自己所负责产品部分深入研究一周，从产品架构到底层设计细节，从其发展史到当下依然面临的问题和挑战；并且找相关的研发同学了解技术视角的曾经和当下......做完这2件事情以后，基本就2周时间了，这个时候我们要做的就是，坐下来；拿起纸笔，认真思考一下“接下来半年，一年，两年这个产品应该何去何从，应该成为什么样子”，并与领导和相关团队达成共识；这决定了你下一步如何开展工作，如何进行产品的设计和落地，如何在新的岗位上做出成绩比如现在我给自己新岗位定的目标是：打造国内顶尖的资金管理系统；这不只是一句话，他可以让你有了方向，也知道了距离目标的差距，而缩短这个差距就是在产品设计方面的目标；怎么定义国内顶尖，我想对内是以极其优秀的指标支撑公司的业务发展，对外以极其高的竞争力对标竞品......定信念，勇往前好的心态，良好的状态是迎接一切好事情的基础；对于未来的期许其实越简单越好，简单是要目标简单，想法简单，手段简单；在这个岗位上做出成绩，在自我升级上再上一个台阶每一个岗位都是，认识新的人，一起做新的事，一起面对相同的困难，一起跨过同一座高山；与其说打一份工是为生活所必须，不如告诉自己，做一件有意思的事是对自我的又一次挑战高杆杠成长，十倍加速上班成长慢？那是你没掌握正确的方法工作经验的积累和自我成长是一个漫长的过程，这个过程有的人迂回且曲折，有些人，螺旋式上升，有些人脚踏实地始终如一......一切问题的根源都是“观念”使然，拥有正确的职场观念，是一切的基础就像纪录片人生七年中的这帮孩子，纵观其60多年的人生，最后做的好的都是在7岁阶段就形成对人生的清晰规划的人，上什么初中，读什么大学，做什么职业......对于职场也是一样，不同的人会经历完全不同的职业生涯，无论你的职业生涯怎样，贯穿其中的两个核心问题需要你去解决，适合自己的正确观念也需要为之早早得建立一个是职业的方向和节奏，另一个是自我升级之道简单的讲就是你想在什么领域做什么工作，要在什么时间做到什么级别，在这条路上如何自我学习和成长；我们来聊一聊这两个方面学会规划和控制自己的职业节奏万事万物的运行和发展都是有规律的，同样我们的职场也是；树立正确的职业规划方向和职业方向非常重要关于方向，一定要让自己的职业发展有一条主线，特别是我们做产品经理，3年内要找到这个主线，电商产品，策略产品，支付产品，清结算产品......3年后深挖这个方向，不建议再变化，因为任何一个方向都是无穷尽的，你永远可以再升级一步；比如我从2015年以后就在支付清结算范畴不断深挖了，直到现在依然在这个领域奋斗，虽然已经到了专家级别，但依然觉得还有很深很深的宝藏等待我去探索......关于节奏，什么是节奏，就像郭德纲说的，那个地方让你笑，什么时候让你笑，是大笑还是小笑，是不好意思的笑，还是温馨的笑，都是设计好的！是的，我们要能够设计自己的职业节奏，3年到高级，5年到资深，7年到专家，10年到高级专家，15年到产品副总裁......这是一个很明确的方向，我们不仅要为公司不断奉献着青春和年华，还要为自己不断寻求最完美的上升路线，如果节奏不对，比如到了第3年依然上升不到高级，就可以考虑为了职业发展寻求更好的机会另一个节奏就是薪资，在薪资上也要让自己保持跟市场一个步调，高级的时候就要达到25-35k，再低的话，就努力争取加薪或者寻找更高的机会自我升级是用学习超越经验工作岗位永远只是冰山一角，我们在任何一个工作岗位上做的事情对个人来说价值只能有30%，另外70%在冰山之下；怎么获得另外70%的价值呢，那就要靠自己的挖掘不满足于自己负责的那几个系统的掌握，那也只不过是前人做的垃圾，我们要做的就是阅读、与同行交流、思考，脱离现有体系的束缚，站在更高的视角去审视当下的一切以当前工作内容为轴线，横向和纵向不断延伸；就像你负责对账，那么对账的数据来自四面八方，那你何不走出对账系统，游荡于四面八方，去学习和思考；因为只有你精通于所有参与对账的业务和系统，你才能精通于对账系统的设计；对账系统不只是一个系统，更是一个产品经理逻辑和智慧的集合投资自己帽子下面那个部分永远比一顿火锅要划算；自己要有为自我升级规划，以及付出的决心，不要可惜那仨瓜裂枣，否则5年之后，面临的绝望可能是几十万都挽不回了！！！真正的实力和竞争力是我们潜意识里储备了永远用不完的系统化的知识我印象最深的是社群的一位朋友；她有很多选择，她也不是大厂背景，但是我觉得她有自己的判断，知道自己要什么，她可以拿到40k以上的薪酬，我相信是她有这个知识储备和实力，以及有自己清晰的自我升级计划，知道自己缺什么，要什么，怎么去获得，并且不惜一切代价！这样的人，不成功，那除非是她自己不想

通过《一文搞懂“账户系统”》掌握了如何设计一个账户系统，这次，将从账务视角出发，打开一些工作上解决问题的新思路。特别是企业的清结算业务，账务是其核心部分；另外现在支付体系的基础也可以说是站在账务核心之上，不同机构的账务管理着不同资金属性的“账户”，管理着不同的信用货币。

业务系统请求入账以后，基于费用类型以及入账规则就可以知道应该入哪个账户；那么问题就来了，因为账户余额也是分结构的，有冻结余额和可用余额，要是想将入账金额先冻结起来怎么办呢？这就需要冻结规则去实现。

L2全能营已经上架2年多了，虽然已经有1.3万名小伙伴加入，但是一直没有一个像样的课程介绍今天花了一下午时间，终于折腾出一个来，今后，L2全能营有“面儿”了，敬请欣赏！如此庞大的内容体系，仅665元，永久有效做完海报才发现原来，有这么多，这么多，这么多扫码报名与1.3万支付校友一起学支付↓或点击“阅读原文”直达以上为推广内容

《上帝视角看支付，总架构解析》对支付的宏观层面做了分析，详解了整个支付体系每一层的架构和业务模型，而每一层的企业内部支付体系建设是什么样的？会涉及到哪些环节和系统？每个系统会涉及到哪些单据和逻辑，是本章的重点。大家对外卖都很熟悉，因为会经常点外卖，我们以外卖场景为例，分析外卖的整个交易链路，从用户下单、商家接单、分配骑手、骑手取餐、配送到用户取餐，从订单、计价、配送、清分、记账、结算到付款，讲清楚每个环节的逻辑和内容。从一张外卖的小票入手进行分析，研究支付微观层面的业务流转、单据的生成等支付细节，最后抽象出一个可通用的支付清结算体系架构出来。

通道是什么？这个在我们进入支付行业开始，就自然而然进入我们视线的词，到底意味着什么？那么我们可以先回顾以下支付的定义：发生在收款人和付款人之间的货币债权转移的过程。而通道，就是在支付过程中进行货币债权（钱）转移的服务提供方。举个例子：我们买个早餐，用支付宝刷了我们的招行信用卡，老板的工行卡收到钱，老板使用的收款工具是收钱吧，收钱吧使用的结算通道是银联。这个支付过程中的支付通道是什么？是收钱吧，是支付宝，是工行招行，还是银联？那么从本质上来说我们的钱从我们的招行到了老板的工行卡，因为我们的货币债权是由招行转移到了工行，所以毫无疑问招行是本次的收款通道、工行是本次的结算通道。就如超市一样，超市本身并不生产商品，他必须依赖厂家或者一些批发市场供货商供货，超市才有商品可卖，才能生存，支付机构也需要一个个通道来为自己提供资金处理的能力，这样支付机构才能为收款人提供收款服务，为付款人提供付款服务。所以，三方支付机构本质上就是基于支付通道而存在，并在此基础上而为收付款双方提供安全、便捷的支付服务的机构。甚至在早期，在支付方案不够成熟的时代，很多支付机构在大家眼中就是个卖通道的。从这种说法我们也可以明白通道对于一个支付机构的价值。强如支付宝、微信，也需要客户先绑定银行卡。支付通道是三方机构的基石，没有通道，有再多客户、再强大的交易清算系统、再强大的解决方案都如空中楼阁，遥不可及。通道系统专栏大纲如下（视频总时长约2.5小时）1.通道基础1.1通道概念1.2通道重要性1.3通道的分类1.4通道管理系统基础1.5通道系统的业务架构2.通道架构2.1通道的生命周期2.2节参与方及其负责内容2.3通道相关物料2.4通道系统的产品架构3.通道系统设计3.1通道接入管理3.2通道的层级3.3通道的信息层级3.4通道的信息分类3.5节通道的数据权限3.6通道信息模块的功能架构3.7模块设计逻辑3.8通道信息管理页面3.9通道能力信息管理页面3.10通道响应码管理页面3.11通道参数管理页面3.12通道黑名单管理3.13通道备案管理3.14商户通道信息管理3.15通道业务数据上述内容归属于“L8三方战神营”加入L8战神营学习三方产品系列陈老师邀请近30位三方支付机构支付产品经理，完成下述表格全部模块的课程跟30位导师一起完成三方支付机构产品体系的全栈学习L8三方战神营价格规则首每更新一个专栏上调价格30元每次调价后仅限量30个加入名额直至全部录制完成恢复原价当前为未来最低价990元本价格仅30个名额售完30名额后停止报名有新专栏更新，以新价格再放开30名额以上为推广内容

重点组建一个三方支付专属微信群，为三方支付体系交流提供便捷进群需要满足以下条件曾经在三方支付机构工作过或者当前正在三方支付机构工作☆必须是支付产品经理如果不满足条件，请勿申请如果您满足条件，请扫码加小助手微信添加时请务必备注“三方机构名称+产品方向”例如：易宝支付-跨境支付好友申请较多，处理较慢，请耐心等待产品方向可以参考下图，例如商户后台、教育支付、付款系统、收银台、风控系统、路由系统等我和小伙伴们·期待你的加入

前一段时间，域名重新备案，停用了1个多月，这几天终于恢复了大家可以直接在浏览器访问域名（陈天宇宙全拼），电脑端和手机内都可以访问，自动适配终端chentianyuzhou.com你

昨天有小伙伴问了我一个问题，关于三户模型，以及能否适用于支付模型的设计，这是一个比较大的话题，也不是三言两语能够说清楚的，最后附上AI的回答我们先全方位了解一下什么是三户模型三户模型最早是在增强型电信运营图（Enhanced

订单拆分以后就会产生父子订单的订单数据结构，示例：宇宙购买了2个商家的ABC三个商品，总价是100元，平台优惠20元，其中A商品属于店铺1，B商品属于店铺2。订单拆分后的父子订单如表5所示。

如果你想系统性的研究三方支付机构的支付体系，并无从下手，不知道都需要学习哪些东西我这里有一张图，一张表这张图，让你看清楚三方支付机构的整个产品架构体系，先形成一个宏观的认识，有一个整体的内容画像这样心里就有数了，摆在你面前的这座大山也就看清全貌了然后，再把这张图整理成一个表格，一个个的小山头就显现出来了，只需要一个山头一个山头的去攻克即可怎么攻克山头呢？按照序号，去百度搜一搜文章，去京东找一找图书，去约做这块的熟人喝个咖啡聊一聊，要上几份资料这事就成了学习并不是一件特别复杂的事情，先有一个目标，形成一个宏观全貌的认识，然后制定一个计划列表，设定好学习闹钟和节奏，一根骨头一根骨头的啃L8首发5折福利来了L8三方支付战神营，陈老师将邀请近30位三方支付机构支付产品经理，完成上述表格全部模块的课程跟30位导师一起完成三方支付机构产品体系的全栈学习首发仅500个学位名额史无前例5折售完500份将停止招生课程交付完以后，原价开售以上为推广内容

一张全局的架构图是理解一个体系非常重要的工具，它可以将该体系所包含的环节以及环节之间的关系表达出来然后可以对架构图中的各个环节展开研究，会变得容易很多支付也是一样，需要这样一张图1.0版本很早之前，差不多2021年了，在“一张小票看透清结算”文章的最后，第一次发布了这张支付结构图后来众多文章，如对账、账户、结算等都可以用这张图表达他们在体系内的位置2.0版本在后面的写作过程中想设计出一张更加完整详细的架构图，将整个内容体系串起来思考了很久，终于完成了这张图，这张图本质上是对上面那张图的迭代升级记住这样图，如果可以默写下来，你会收获意想不到的效果大家可以找一找，在《陈天宇宙全集》中，有非常多的架构图，可以把他们倒腾到一起，做为总纲，会让支付学习，事半功倍

对于钻研整个支付来说，不简单也简单，说其不简单是因为有非常多的业务场景，也有非常多的支付组织，多维度组合出了非常复杂的支付设计，所以并不简单，滴滴的支付和美团的存在差异，同样京东的支付跟淘宝的也存在差异；说其简单也简单，因为复杂的背后总是有相似之处，通过归纳总结和抽象，精通其一便知其二，懂其二便知全部，因此，依托一个场景，去洞察其业务，研究其产品体系，并在此基础之上，形成一个完整的“知识网络”。所收获的全局思维、架构能力、规划能力等，将有益于整个职业生涯，本文将从信息流和资金流分析能力、模式化设计能力、支付架构能力等3个方面构建一个支付产品经理应该具备的最基础的产品能力。01.支付流分析能力工作和日常交流过程中经常会涉及到信息流和资金流的分析，分析信息流主要是为了了解支付指令的传输途径或者交易流程，而分析资金流主要是了解支付中涉及到的货币种类和资金在不同主体之间的流动情况。实际情况很多人并不能清晰的搞明白不同的支付活动中的信息流和资金流是怎么样的，或者根本上不知道如何去分析。接下来就聊一聊信息流和资金流的分析方法和通用模型，掌握了分析方法，就可以轻松的分析清楚任何一种支付活动的信息流和资金流。

曾经收到过一个问题，关于如何设计资金管理系统和银企互联系统，有没有成熟的页面参考一下。当然了，每一个产品经理在接到需求以后，第一感觉就是“赶紧找一个成熟产品扫两眼”，这无可厚非。只不过实际是实际，理想还是要有的，万一找不到参考可看呢？我们还是需要一个可以兜底的技能，自己能够动手搞起来！并且将这个技能逐渐训练成一个固定的设计模式，这个模式可以应付所有的产品需求。这个模式就是自己设计产品时稳定的设计习惯和方法的集合，简单的说就是：从拿到一个需求开始，会怎么做，直到产出产品方案。

工作和日常交流过程中经常会涉及到信息流和资金流的分析，分析信息流主要是为了了解支付指令的传输途径或者交易流程，而分析资金流主要是了解支付中涉及到的货币种类和资金在不同主体之间的流动情况。实际情况很多人并不能清晰的搞明白不同的支付活动中的信息流和资金流是怎么样的，或者根本上不知道如何去分析。接下来就聊一聊信息流和资金流的分析方法和通用模型，掌握了分析方法，就可以轻松的分析清楚任何一种支付活动的信息流和资金流。

支付处理中心对支付请求进行处理，通过路由选择合适的支付渠道，然后由封装支付指令，将清算指令通过支付通道提交给清算机构或者银行，该部分如图10所示：图10：提交支付请求的处理架构部分3.3清结算部分

截止目前，L2全能营已经有1.3万人加入，可以说这是众多支付人共同努力的结果大家每天在群里讨论各种问题，社群的力量已经远远超过了课程的价值宇宙之火，席卷了整个支付圈↓宇宙之火，烧到了美团内部↓↓宇宙之火，烧到了前同事面前↓↓宇宙之火，烧到了未来的领导↓↓宇宙之火，烧出了大家的口碑↓↓宇宙之火，终成正果↓2年下来，L2全能营已经从原来的对账系统，逐渐演变成了现在的9大模块24个专栏近500节课程的庞大支付理论体系模块1支付导学专栏1

如果你想系统性的研究三方支付机构的支付体系，并无从下手，不知道都需要学习哪些东西我这里有一张图，一张表这张图，让你看清楚三方支付机构的整个产品架构体系，先形成一个宏观的认识，有一个整体的内容画像这样心里就有数了，摆在你面前的这座大山也就看清全貌了然后，再把这张图整理成一个表格，一个个的小山头就显现出来了，只需要一个山头一个山头的去攻克即可怎么攻克山头呢？按照序号，去百度搜一搜文章，去京东找一找图书，去约做这块的熟人喝个咖啡聊一聊，要上几份资料这事就成了学习并不是一件特别复杂的事情，先有一个目标，形成一个宏观全貌的认识，然后制定一个计划列表，设定好学习闹钟和节奏，一根骨头一根骨头的啃每啃一根不同的骨头都需要不同的方法和工具上面的图和表也是最近才设计出来的，对我从新复盘三方工作经验和知识输出非常有帮助，可以说将成为我的底层支付框架我感觉会对大家学习或者规整自己的工作经验有帮助，所以就简单的发出来，可以长按保存，打印，贴到办公桌上和我一起，研究透三方支付机构的支付体系建设推荐阅读“三方支付”的产品体系股票，“废纸”还是“自由”

折磨了我两周的结算系统原型终于封稿了，明天正式开讲本次的结算系统兼容了很多结算模式，总的来说涉及到“8类结算业务，5个结算模式，4个结算方向”，从通用结算规则就可以看出来我们简单介绍一下这次的结算系统，首先就是整体功能，整体来说将模式进行了拆分，比如普通结算和对公分开了，这样大家可以看得更加清楚每个结算业务的结算处理路径怎么样，每个结算模式中都有不同的处理环节我们看几个页面，大家就可以脑补出整个结算框架了，比如商家结算信息部分，可以看出来不同类型的商家采用了不同的结算模式，结算方向等我们再看一下普通订单结算的几个数据处理模块，单看数据大致可以看出来结算处理的过程，但是，其实还有很多处理逻辑从数据层面看不出来以上就是L3实战营结算系统原型中的一部分，而这样的原型整个实战营有11套，还包括22个实战项目，下面是已经完成了6周的“战况”L3我是非常强烈推荐大家参加，我投入太多心血和精力了，毫无保留，如果你错过了，真的非常非常非常“又亏又冤”以上是推广内容

对账系统相关的内容写的比较多了，想全面了解对账系统设计可以阅读《对账系统设计》解析文件是对账系统设计中非常核心的一个部分，但上述文章中的解析器描述的详细程度可能有所欠缺，所以，本文单独讲一下解析器的设计方法和实现原理文件与解析获取文件并解析文件是对账系统非常重要的环节，也是后续进行对账的基础而获取文件主要指三类文件：平台的支付数据、渠道的清算数据、渠道的结算数据，平台数据可以通过SQL、MQ、接口、文件等形式获取，而渠道文件一般通过接口获取，或者人工下载并导入到对账系统内获取文件以后，如何将文件解析到数据库里形成数据库数据就需要解析处理的能力，当然可以由技术直接研发实现这样做的弊端比较明显，那就是新增渠道、或者渠道文件发生了变更，对账规则发生了变更，可能都需要走研发对解析规则进行修改，这将大大的增加研发的成本，降低了对业务诉求的反映效率所以，可以实现解析规则的配置化，这也就是本文要介绍的“坑位解析器配置”为什么叫坑位解析器呢，因为本模型的数据库表是固定的，而是将文件数据按照对应关系解析到固定的字段上去与之相对的另外一种解析模型就是将文件原样解析，保持文件的字段数量，但是，这样的解析模型会造成大量的数据表结构，后续的处理和对账设置会稍微麻烦很多文件与解析规则的关系对于三方支付机构来说，交易对账就是核对平台的支付数据记录与渠道下发的清算文件中的记录的一致性，而平台数据可以通过SQL获得，而清算数据可以通过接口获得，获得以后进行文件的解析，而解析就需要解析的规则，如下图所示一个对账项目的解析器和清算文件是绑定关系，这样就意味着该对账项目的清算文件是由该对账项目绑定的解析器所设置的规则进行解析的如何设计配置工具下图是某支付渠道的清算文件样式其中的商户订单号就是平台的请求唯一单号，也就是与平台数据进行核对的唯一标识，所以要解析出来，另外的交易状态代表了退款和支付类型，后面还有金额等对账需要的字段如何设置将这些字段解析到数据库表中的规则，就需要用到如下的配置工具整个配置工具由2部分组成第一部分是基础配置是配置该解析规则的基础信息，主要配置实现“我们需要哪些数据”，比如解析器的编号，所属对账项目，文件的格式、编码等内容其中，过滤字段设置的是“哪些数据不要”，比如示例中的含义就是通过文件中的第9列和第10列进行过滤，第9列是“未知、失败”或者第10列是01的数据不需要进行解析数据开始行的用途是指定从哪一行开始解析，因为有些渠道的文件开头有表头或者有些统计类信息不需要解析，应该刨除掉，如下面的文件就应该填“6”，从第6行数据开始解析，前5行数据不需要数据列数的配置用途其实也是用于设定解析哪些数据，可以跟“数据开始行”的配置同时使用，加强条件，比如填写了“12”，就代表只解析哪些有12个字段的数据行第二部分是解析规则的配置这部分是规则部分，主要是配置文件中的“数据如何放到数据表里”的问题配置一共有3列第一列就是数据库表的固定字段，例如银行订单号、交易类型、卡类型等第二列是字段位置，也就是这个字段取文件中那一列的数据，比如原型中银行订单号填写的是1，就是将文件中的第一列解析到银行订单号第三列是说明文件中的数据格式、单位或者数值这里要强调的是，整个规则配置主要可以分3大类第一类：取数型配置，如银行订单号等，只需要填写数据列“数”即可，不需要配置格式、单位、数值，直接将文件中的数据取过来即可第二类：映射型配置，如交易类型、卡类型，二者在数据库里是固定的枚举值，分别是“支付、退款”，“借记卡、贷记卡”，按原型示例的配置，含义就是卡类型根据第“13”列判断，如果是01则代表借记卡、02代表贷记卡，解析到数据库里时，卡类型字段会设置成“借记卡”或者“贷记卡”，而不是文件中的数值；同样原型中的交易类型字段，由第“10”列决定，当是“S13、S22、S23、S36、S37、S46、S54、S56、S64”时代表支付，当是“REFUND”时代表退款第三类：单位和格式型配置，比如原型中的金额需要配置文件中是什么单位，时间要配置说明文件中的时间格式是什么

今天用微信扫码付了一笔钱，对方让截图账单给他用于财务领款看到账单那一刻，我有点小惊喜，为啥呢？因为这是我第一次见到一个账单里，同时出现了“网联”和“银联”好嘛，付一笔钱竟然同时惊动了两位大佬帮忙这是为啥呢？这笔支付背后经历了哪些支付参与者、哪些支付业务、信息流和资金流又是怎么样呢？职业习惯让我脑子里闪出这些思绪同时，我将这个场景发到了微信群里，引起了大家的热烈讨论，确实，这个案例是一个非常好的学习案例，涉及到的支付知识点非常多，覆盖的支付业务种类也比较复杂我先把整个支付场景和过程给大家还原一下首先，对方微信里发给我一个收款码，单看这个码明显是一个聚合收款码微信内扫码以后，打开了一个收银台输入金额点击支付，调起了微信支付，选择绑定的工行银行卡进行支付支付成功后，就得到了一开始我们看到的账单了从账单里我们可以看到这些信息，收单机构是富友支付，商户是锦城沃达，我是付款人，用的微信支付，使用了绑定的工商银行卡完成了支付另外，其中还有个亮点，那就是同时出现了网联和银联其中，银联提供收款清算服务，网联提供付款清算服务为了获得更多本笔支付的信息，我看了工行APP里的账户明细，截图如下从工行APP提供的账单信息中可以看出来，收款方是财付通支付，收款账户是“财付通-备付金账户”，所以钱不是直接付给富友或者商户的，为什么呢？因为招商银行APP的账户明细有更多信息，所以我又用招商银行卡支付了一笔，然后招商银行APP的账单信息截图如下所以，从招商银行APP提供的账单信息中可以看出来，我通过微信付款，微信使用的是“网联的协议支付”，也就是银行卡快捷我大概分析了一下这次支付所涉及的一些内容，绘制了下面这张图这个案例涉及到的知识点很多，本来想详细解析一下，但是精力问题，最近比较忙，所以就把案例拿出来，大家自己可以研究研究整个支付链条涉及到了哪些支付业务和环节，信息流和资金流是怎么样的还可以拓展开去分析其中更多的业务环节，比如富友的聚合收款码怎么聚合的、商户如何入网的、间联了微信么？用户在微信如何绑定了银行卡、在扫商户的收款码时发生了什么？怎么调起了富友的收银台？又调起了微信内的收银台？微信支付时发生了什么？网联和银联在其中是什么角色，如何转接信息提供清算服务的等等后面有机会，我再写一篇类似“一张小票搞定清结算架构”这样的文章，把这个案例解构明白，而本次就暂且先把案例说明白，提一些思考方向如果你把这个案例研究透彻了，我想，会有很大的收获！