增值服务是什么意思是收费的么_增值服务是什么意思( 八 ) _百科达人

一点：收银台，也是支付的起点。
三线：
内线“订单- 账单-清结算-账务账户”外线“路由-风控-支付核心-渠道清算-通道方”联动线“内线和外线的支付信息交互线”内线是为内部服务，从交易发生以后最终到达会计系统记录本次经济活动的整个链条，从订单开始走向计费、内部记账、内部会计等。
外线是为清算服务，将支付指令发送给服务机构并接收反馈的过程主线；从订单开始到达支付网关，通过路由选择合适的支付通道，然后交换支付指令，完成支付。
联动线是为内外线通讯服务，内线的进程和外线的进程相互通讯和推动，支付成功了就可以进行记账，计费成功了就可以分账。
那么我们就得到了如下的支付架构，如图15所示：
图10-15 支付架构
4. 架构就是远方把握好“一点”的设计和“三条线”的设计，就可以搭建起一个完整的支付体系。该设计方法不仅适用于一家三方支付机构，同样适用于一家普通的交易平台，四方聚合支付。只不过支付通道的不同，三方接入的是银行通道，普通商家和四方聚合公司接入的是三方通道。
架构的意义是什么，那就是可以确保未来不会频繁重构，确保在每一个维度都具备足够的可拓展性，确保每一个模块和细节都为整体服务，同样确保产品不被业务牵着鼻子走，这是产品的顶层设计，也是走向远方的那盏灯塔。
5. 产品的意义在于解决问题产品的意义是什么，是做出一个“厉害”的系统么，是做出一个“正确”的功能么，是遵守一个通用的规范么？我想都不是，何为正确，何为规范，谁又是标准？
产品的意义应该是用可用的手段解决当下甚至是未来的问题，所以，产品应该聚焦问题本身或者需求本身，不是系统或者功能本身。
就像很多朋友会问，账户的流水用体现“-负号”？我们总是习惯站在功能角度去设计产品，负号是一个功能；而常常忽略了，我们所面对的问题，而这才是根本。产品应具备通过功能灵活解决问题的能力，而不是仅仅是设计功能本身。
我们再看要体现流水的“负号”么？要不要呢？其实我们不应该问要不要体现负号，而是要问自己，负号要解决什么问题，进而问自己“我在面对一个什么问题” 。
而这个问题就是“我需要用一种方法反映出流水的方向”，面对这个问题时，你就不应该用“用不用负号这个功能去回应”，而是“如何反应流水的方向”，当触达最本质的问题时，我们才能到达最关键的十字路口“选择”，一个产品面对问题时应该具备选择的能力。为问题选择答案，而不是仅是论证一个答案的正确与否。
反应流水的方向就不仅仅可以用负号了，可以用收支字段、借贷标识，这个时候你还会问我，流水里用不用反应负号么！当你再思考这个功能怎么设计的时候，不妨回到起点，问问自己我要解决什么样的问题，期望达到什么样的效果，我有多少可选的方案，当下的这个让我百思不解的功能是唯一答案么！放弃对模板和对权威的痴迷，而是探索自我的设计风格，培养追寻未知新事物的好奇，产品设计可以很自由且很潇洒……
六、账户迁移方**账户部分在之前我们讲得比较详细了，而且在线课堂也有账户的专栏，所以在此基础上我们来观摩一个实际的账户相关的案例。
这是一个大型且高危的项目，危险程度要看涉及到的资金属性、账户数量、资金体量。比如你要是几十万，那闭着眼就做了；但是如果是千万用户，百亿资金情况下，小心脏就要时刻蹦蹦跳了。
我们知道企业在发展过程中到了一定阶段，难免需要进行一些系统的重构或者数据的迁移；比如要做中台，那么业务的统一势必要将一些系统下掉，业务以及数据迁移到新的中台服务中去；我们要讲的就是“旧账户服务迁移至新账户服务”如何做，如何实现用户无感知的服务迁移
我相信，这个案例可以让你把账户掰开了揉碎了再认识一遍；而且对账户的把控力上升3个台阶；这也是高端面试过程中容易问到的问题，也是一个很容易脑子一片空白哑口无言的题目；当然这个案例也可以作为简历中一个经典的颇具竞争力的实战项目
这次我计划采用半讲解半方案文档的模式书写这篇文章；既可以让大家理解，又可以作为半成品文档提供给各位拿来即用；好了，价值讲清楚了，你准备好开始了么……
1. 项目概述为了构建统一中台账户服务，围绕中台统一账户管理支持各业务线客户账户以及账务处理能力，需要将各业务线分散的账户业务全部切入中台账户服务中心，并且稳定后下线旧账户服务。