我们以收银台为例，详细说明支付的正确打开方式。 当用户提交订单后，就会被引导到收银台上。 以某东为例，手机上是这样的：
PC上是这样的：
从这里我们可以看出，用户进入收银台之后，首先需要选择默认的支付方式。
支付方式指消费时付款的方式，比如现金支付、货到付款、信用卡支付、借记卡支付、扫码支付等。
那么有哪些支付方式适合在收银台上展示出来? 这就是支付应用和支付方式的关系。在这里，收银台是一类支付应用。
支付应用指提供给最终用户在特定场景下使用的产品，比如扫码收银、二维码支付、打赏、众筹、POS支付、生活缴费、信用卡返款、手机充值等。 这些应用是建立在支付产品的基础之上，直接面向最终的用户提供服务。
每个支付应用可以用的支付方式是不一样的。比如说，扫码收银，可能仅支持微信和支付宝。POS支付，仅支持银行卡。而信用卡返款，只能从其他的借记卡上去扣款。 支付应用的设计和公司的业务有关，并需要考虑在公司业务场景下的用户支付体验。目前应用最全的数支付宝，可以参观下支付宝的应用(截止至2017年2月15日)：
在收银台这个应用中，在呈现支付方式时，哪些支付方式可以提供给当前场景下的用户来使用，哪个方式应该排在前面，这在支付系统中，是通过引导路由来实现的。
引导路由是根据支付应用、收款商户、订单额度等信息来决定提供给用户的支付方式列表。
当用户选择一种支付方式并提交支付后，支付系统开始执行扣款。比如用户选择通过招行来支付，系统就会请求招行来扣款吗? 这不一定，因为系统有可能并没有接入到招行接口。除了招行自己的接口外，第三方支付公司、银联等，也可以从招行卡上扣款。那应该使用哪个通道合适? 这是通过支付路由来决定的。
支付路由指根据用户选择的支付方式，结合费率、QOS等因素，选择合适的银行或者其他公司提供的支付接口来完成资金转移操作。
通过支付路由，我们可以定位到一个落地来执行的支付接口。
支付接口，指由银行提供的用来执行支付的接口。这里要注意，对于同一家银行，除了总行可以提供一个接口，各地的分行也可以提供这个接口。 但一般来说，同一家银行的接口规范是一样的，不同的是提供接口的服务器、费率、性能等。
比如，支付公司可以接入工行总行、工行上海分行、工行北京分行的接口。为什么要接入分行呢? 一般来说，不少分行会提供更优惠的接入费率，以及经常会举办一些活动来吸引用户接入。
支付通道，这是对支付接口的一个封装，包含合作银行以及通道成本、商户费率、QOS等信息;
银行和第三方支付等渠道提供给电商公司使用的接口，往往都会封装成支付产品。
支付产品指将支付通道打包成满足某特定支付场景需求的商品，比如信用卡快捷、信用卡Moto等。
在这里我们把涉及到的几个概念都做了定义。 当然，这些定义仅仅是从约定俗成的角度来描述，不具有学术意义。 不同的公司，对这些名称叫法还不完全一致。 比如支付通道，有些叫渠道，有些公司叫网关。这里统一一下称呼，避免混淆。 总的来说，支付系统是把支付通道提供的支付产品 使用支付路由来封装成业务需要的支付产品。这就是支付的核心流程。支付路由在其中起着关键作用。
支付系统会涉及到如下参与者。
客户指与某个商家有交易关系并且存在未清偿的债权和债务关系的一方。 客户使用自己拥有的支付工具来发起支付，是支付操作运作的发起者之一。在交易中，也成为交易主体。
商家是拥有债权的商品出售者，他根据客户发起的支付指令向支付系统发起请求，要求获取资金。 商家需要获取和支付系统接入的权限，一般是在服务器端和支付系统交互。
客户拥有账户的支付渠道。 客户需要使用支付渠道所支持的支付工具来发起支付。这个工具也意味着一种信用，保证支付工具的兑付。
商家用来接受资金的账户的所在银行。 商户将客户指令提交给其开户行后，由开户行发起支付授权的请求进行银行间清算的工作。 商家开户行是根据商家提供的账单工作的，也成为收单机构。
支付系统的运营人员除了常规的业务拓展外，还负责对支付业务状态进行监测，配置和管理渠道的密码秘钥、对账处理等日常工作。
一般风控和运营是分开的。 风控人员负责每天审核被拦截的交易的情况，发现可能潜在的风险，配置风控规则，确保支付系统的资金安全。
和钱打交道，在任何公司，都跑不掉财务部门。 那财务部门会关注哪些内容? 当然，最重要的是账务信息。 所有的交易都要记账，按要求公司都需要定期做审计，每一笔帐都不能出错。这当然不能等到审计的时候再去核对，而是每天都需要对账，确保所有的交易支出相抵，也就是所说的把账给平了。 这就有三种情况： 电商系统和商家对账;电商系统和支付系统对账;支付系统和收单机构对账。在支付系统中，我们仅关注后两者的情况。运营人员是和信息流打交道，而财务会计需要和资金流打交道，核实每个渠道的资金情况，对备付金按照运营的要求进行充值调度等。
我们以电商系统的订单支付为例，看看支付系统中需要提供的基本功能。
1.用户提交订单到电商系统，电商系统对订单进行检验，无问题则调起支付接口执行支付。注意这里支付接口是在服务器端调起的。一般支付接口很少从客户端直接调起。为了安全，支付接口一般要求用HTTPS来访问，并对接口做签名。
2.支付系统检查参数有效性，特别是签名的有效性。
3.根据用户选择的支付方式，以及系统支付路由设置，选择合适的收单机构。这里涉及三个概念，支付方式，支付路由。这又是一个槽点。简单说，用户可以选择各种银行卡支付，比如宁波银行卡，但是你的支付系统没有对接宁波银行，那对这种卡，可以选择你接入的，支持这个卡的收单机构来执行支付，如用微信或者支付宝等等第三方支付，或者银联支付等系统支持的方式来执行。这就是支付路由，根据用户提供的银行卡来选择合适的收单机构去执行支付。常用支付方式还包括第三方支付，如微信支付宝等，这种情况下就不需要支付路由了。
4.调用收单接口执行支付。这是支付系统的核心。每个公司的收单接口都不一样，接入一两个收单机构还好，接入的多了，如何统一这些接口，就是一个设计难点。
5.支付成功，收单机构把钱打到商户的账户上了。 商家就准备发货了。 怎么发货，不是本文的重点。 这里关注的要点是， 商家能收到多少钱? 比如100块钱的商品，用户支付了100块钱(运费、打折等另算)，这100块钱，还要刨去电商系统的佣金、支付通道的手续费，才能最终落到商家手里。
这是个Happy流程，一切看起来都很美好，但实际上步步都是坑，一旦有地方考虑不周全，轻者掉单频发，重者接口被盗刷，损失惨重。
如何避免攻击者修改支付接口参数， 比如100块钱的东西，改成10块钱?
调用收单接口来执行最终实际支付时，如果支付失败了，比如卡上没钱了，怎么办?
收单接口把账户上的钱扣走了，但是通知支付系统的时候出错了(比如网络闪断，或者支付系统重启了)，支付系统不知道这笔交易已经达成了，怎么处理?
还有好多问题….
从软件开发角度， 还有一些非功能性需求需要实现：
性能： 特别是秒杀的时候，如何满足高频率的支付需求?
可靠性：不用说，系统能达到几个9，是衡量软件设计功力的重要指标。 99%是基础， 99.999%是目标，更多的9哪就是神了。
易用性：支付中多一个步骤，就会流失至少2%的用户。 产品经理都在削尖脑袋想想怎么让用户赶*钱。
可扩展性： 近年来支付业务创新产品多，一元购、红包、打赏等，还有各种的支付场景。 怎么能够快速满足产品经理的需求，尽快上线来抢占市场，可扩展性对支付系统设计也是一个挑战。
可伸缩性：为了支持公司业务，搞一些促销活动是必须的。 那促销带来的爆发流量，最佳应对方法就是加机器了。 平时流量低，用不了那么多机器，该释放的就释放掉了， 给公司省点钱。
这里从流程和概念的角度分析支付系统应该支持的基础功能。 后续我们将以此为基础，探讨支付系统的设计。