一、 收银台及付款方式介绍
收银台俗称付款处，是顾客付款交易的地方，也是顾客在“商店”最后停留的地方。
顾客要完成付款，需要知道付款金额，即：先生成订单，零售业生成订单的角色目前有两种：顾客、收银员。
根据生成订单的角色，整理目前的收银台以及付款方式如下：
顾客成单并支付，能够解决客人排队付款。
二、收银台管理
收银台除了解决客人用各种方式付款的需求外，还需要解决公司各个业务线，不同场景对收银台提供的支付方式不同的需求。所以在后台我们对收银台进行了两层的管理。
分别为目前能够提供的收银台方式，以及各种收银台上能够支持的支付渠道以及支付方式的定义，如下图：
另外一层是：公司各个业务需要哪种形式的收银台，以及各种收银台上需要的支付渠道和支付方式
各个业务需要的是公司目前已经实现能够支持的范围的子集
这样做的考虑是：公司新业务多且发展快，有时候为了快速，只需要最简单的方式去试验。
另外，未来在收银台做促销活动的时候，可以控制到 业务+收银台+渠道+支付方式.
零售行业高峰期收款排队现象比较严重，这也是我们 目前考虑解决的，解决方法是采用移动收银，但还是试验阶段。
三、Q&A
Q：这里收银台场景是当面收单么？
A：我把收银台理解为广义的，只要是实现收客人钱的，都叫做了收银台，只是载体或者承载收银台的应用不同，所以可以是当面收单（即：收银员成单客人支付），也可以客人先通过app下单&付款，到店取走
Q：另外一层是：公司各个业务需要哪种形式的收银台？比如超市（现金），ktv（记账），收银台是硬件加软件？还是只是软件？
A：软件，比如：便利店业务需要的收银台有：app收银台，pos收款机收银台，微信app等。收银台会有各种业务线的产品打包支付，在规则配置上可能会冲突，这是个好问题！目前我们将会员卡和便利店算做两个业务，会出现你说的情况。但没有出现两个业务收银台冲突的情况，如果出现，我考虑的方案是：将两个业务打包后，算做一个新的业务，配置收银台。这个方案的问题是：收银台管理会复杂
Q：嗯，是啊，收银台模型来自于支付产品和业务线规则配置的组合，如果有冲突可能会干扰用户
A：是的，目前我们还刚刚起步，复杂需求还在路上，so感悟不是很深，这个设计也是借鉴电商行业的模型
Q：这种我记得可以根据业务配置支付产品（用场景来区分）吧？类似微信哪种？当面付，公众号付，APP支付？只是微信持牌，底层账务，通道，账户通用，中间层区分逻辑？比如用户购物，使用外部工具面对面扫码。或用户购物刷银行卡
A：我是按照承载收银台的应用定义为不同的收银台
Q：我可能是按照场景细分，工具面对面，线上付款，刷卡现金，会员卡消费
A：是的，外部工具 – 第三方收银台，面对面扫码–支付方式
Q：目前收银台是给自己公司用还是也提供给第三方？
A：自己公司用，目前还不具备提供给第三方的能力。
Q：目前下订单(锁定预占)和收银台合二为一还是分开的呢？
A：分开，下单占库存。
Q：现在你们有组合收银没？比如我用会员卡加支付宝？订单里你们怎么设计？
A：目前还没有支持，但后续需要支持
Q：这种估计允许用户一个订单允许多次支付，订单估计只有人为关闭，现在退款也是各个渠道原路返回？
A：组合收银，个人观点是放在支付系统处理，定义优先级，然后每一种都成功后，订单支付成功，否则失败。涉及到会员账户的，应该是先冻结，然后在做外部的支付，比如支付宝，支付宝成功后，在做作会员账户的消费；如果支付宝失败，作会员账户的解冻。
Q：我有点没理解，你的收银台是将一种方式方式展示出来，还是对支付方法集中的展示出来，就像下图这种
A：以你的图片为例，后台定义的是：收银台=pc收银台， 支付渠道=招行，支付方式=信用卡，快捷，至于页面的展示就是按照需要设计的，底层是一样的，比如app的收银台是这样的
Q：你们会对所有接入的能支持该业务的支付方式聚集展示出来是吧，第一类是不是主要通过你们自己研发的工具收银（类似余额支付），第二类就是第三方支付？第三类是银行
A：因为应用不同，展示的样式不同，pos收银台就是超市里，结账收款用的带有扫码枪的那个机器，进行不同的设置
Q：就是你们可以通过后台配置增减某类收银台的支付方式？
A：是的
Q：APP收银类似欧尚APP，pos（现金）是刷的你们的会员卡？
A：可以支持，我说的会员卡不是指充值账户，指的是类似电商买了会员，可以多积分之类的，充值账户类似微信的零钱账户，是真金白银充值进来的。
Q：那你们会不会根据不同的业务在相同的收银台（比如app收银台）上展示的不同的支付方式，这种是配置的模板，还是自动路由？
A：会，收银台管理配置，不是路由。我理解的路由有两种，应用到收银台的引导路由和支付通道选择的通道路由。
Q：就是每类业务都要有一套自己的配置是吧？
A：是的。
Q：自动路由估计悬，又不是支付通道，其实就像不同终端配置支付方式不同（APP和PC）
A：是的，只不过在此基础上，增加了一层业务的定义。
Q：对支付方式的归类，比如下图你的【支付宝支付】，可能后面能路由到 支付宝sdk，支付宝h5，或者其他聚合支付提供的支付支付（比如二维码）。要把这多支付方式按类归集到一个前台的支付方式上，感觉有点复杂
A1：应该不是，这个归集不到一个前台（分成APP,PC），不然调用会出问题吧
A2：我把sdk的这种归到了银行或者第三方的收银台，因为收银台“不在我这边”，H5 算我的H5收银台，应该算两种不同的收银台。
Q：那比如是web收银台，有个支付宝支付，我可以跳转到支付宝的收银台，也可以自己做个页面加载个其他支付公司生成的支付宝或者万能二位码，那这个图点击后只会跳转到支付宝的sdk了？
A1： 如果是支付方式不同，比如一个用支付宝PC支付，一个用支付宝扫码支付原则上可以，但是需要分类展示就像你发最开始哪个。根据风控 费率 稳定性等因素，我理解每个前台的支付方式后面都能路由到几个支付渠道提供的支付方式上，比如快捷支付，我能用微信，也能支付宝，也能银联。这种可以，无非就是快捷支付，网银支付，认证支付，资金代付都可以多通道路由。
A2：快捷支付可以在pc收银台，也可以在app收银台上，这不矛盾。 如果我的H5应用上，调用API方式的话，需要有H5收银台，且支付流程都在我这边；如果是在我的H5应用上下单，点击去支付，调用sdk，那不属于我的H5收银台；关于sdk和h5 ，我是这样理解的。
Q：你们现在在app收银台的【支付宝支付】后面是只接入了支付宝的sdk？
A：我们是直接调用的接口，不是sdk
Q：接口是指下图的2？3？
A1：pos收银台=4 当面付 app= 3 app支付，之前确认错了，这个是对的 pos收银台=4 当面付 app= 3 app支付 sdk
A2：sdk主要给APP使用（微信，支付宝），H5更多是api方式
Q：其实只是想咨询你们的设计中会出现一个支付后面可能有多个支付产品的设计么（不知道这个算不算支付路由）
A: PC也主要是api，区分了的，APP端不会开放网关支付。支付路由是同一种支付方式（快捷，代扣，扫码，）可以使用多家支付公司提供通道，支付路由针对通道，其实扫码不算支付路由。网关就是网银支付，这种更多是PC上才有，APP不好跳转到银行且还能支付。
Q：我遇上的困难是，把这些接入的支付渠道提供的各种支付方式如何进行归集。自己没找到好的方法 A：一般支付宝，微信我都是单独分类，其他第三方按照支付方式（快捷，网银）之类分，类似支付宝那种。不然成本太高，特别是微信支付宝，那玩意手续费对你而言手续费不划算。
本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。
- 长按或者扫描二维码来打赏，感谢支持群管理工作！
- 请扫码关注“凤凰牌老熊”的微信公众号。
