在新零售SaaS收银系统中，支付核心起到了至关重要的作用，这篇文章里，作者针对支付核心做了解读和梳理，想了解的同学，不妨来看一下。
支付核心，是处理不同业务线支付的核心模块。
具体做的内容就是：一笔订单由交易系统请求下单，支付系统将此账单的支付指令，传递给上游支付渠道，最终完成支付并处理业务支付结果。
这其中，在新零售SaaS收银系统中，支付核心起到了至关重要的作用。
它承载着内部业务和外部渠道支付，最终促成交易闭环。
用户在收银台完成下单支付，在整个收银系统中不光要靠线上/线下的可视化收银台，还需要一套接口收银台。
在准备封装前 ，我们先来深挖一下收银台的本质是什么?
在传统收银台前，收银台是要促成买家和卖家交易并完成支付。也就是我们常说的，一手交钱一手交货。钱从买家的钱包转移到了卖家的钱包中。
在现代收银台前，收银台可能是线下终端收银台，也可能是线上收银台。卖家将商品或服务提供给买家，钱从买家账户转移到卖家账户中。
不管在传统收银台，还是现代收银台，要完成交易，支付是其中必备的一环。
支付：就需要将钱从买方转移到卖方。其中交易媒介就是我们的账户。
当我们站在最上层结算银行的角度来看这个支付过程时，它就是对账户进行借记贷记操作。
对账户的操作有：存钱，转账，消费，退款等操作。银行方会对此封装出各类操作的接口，提供给下游平台使用。
针对这些操作，第三方支付渠道，银行等会结合下层应用的场景，封装出不同的支付产品，来供它的下游平台或商户使用。
新零售SaaS软件服务商，也需要根据自己的客户业务场景，封装出一套收银台接口。同时也需要选择适合自己业务场景的渠道支付产品进行对接。最终来为客户的收银场景提供支付服务。
收银台的API封装本质：就是根据不同的支付业务场景，传递不同的支付指令，来对买方和卖方的账户进行借记贷记操作。
只不过这其中经由多个下层，根据服务业务场景，层层封装成该渠道的支付产品而已。
那么支付核心到底要如何封装收银台API?
又该如何确定支付渠道产品是否能支对接呢？
有线上支付、线下支付、智能机具，礼品卡券等支付场景。
根据公司不同业务线的支付场景,我们需要找到合适的支付渠道产品。
结合银行、第三方提供的支付渠道产品，新零售SaaS收银行业的业务，需要B扫C，C扫B，JSAPI,APP，刷脸等支付方式。
当我们确定好所选支付渠道产品时，首要考虑的内容就是支付渠道产品的应用场景，
是否适配新零售SaaS收银系统的业务线。其次考虑通道的安全性，稳定性，手续费率等问题。
我们这里主要从接口角度，来分析业务场景是否适配。
那么我们该如何审核渠道接口文档是否适配新零售SaaS收银系统业务场景呢？
此小节，着重从开发角度来审核渠道支付接口是否符合业务所需。
接口文档中也是，只以核心参数拿出来作为判断依据。
根据上面分析的新零售SaaS收银系统业务线， 我们确定了要对接B扫C，JSAPI（小程序，扫码点餐）支付，C扫B接口 还有刷脸支付。
为了促使交易支付流程的完整性，不只是需要支付操作的接口，还需要订单查询、退款、退款查询、撤销、异步回调推送订单状态。
接下来就需要明确支付通道方提供的接口中必填业务参数， 新零售SaaS收银系统是否支持对接。
同时，新零售SaaS收银系统的支付参数必传项，通道方是否支持。
此接口需要注意的点：上游平台商户号，商户订单号，付款码， 付款金额，单品优惠详情、落单号。
上游平台商户号（必填）：这个参数是每个接口必须得，它是上游渠道判断指令来源于哪个商户的重要依据。
商户平台唯一订单号（必填）：需要注意订单号长度超长的情况或定制化规则。不同通道要求不同，开发需要单独来处理。
付款金额（必填）：单位要看清是分还是元，在实际编码的过程中，开发需要使用BigDecaimal类型转换，警惕使用Double方式进行转换，从而来避免精度丢失问题。
单品优惠详情（非必填）：渠道方或者商户想要针对商品优惠，开发需要上传此信息给上游渠道。
此字段需要格外注意商户传入的商品名称是否有特殊字符，开发需要进行单独过滤或者编码，防止支付验签报错。
回调推送地址（非必填）：接口中存在此字段建议上传，能够异步接收订单状态。不过度依赖程序定时任务查询，减轻服务器压力。
响应参数中的落单号（非必填）：此字段如果接口能返回最好也要记录下来，方便商家给客户退款时，直接扫描落单号直接发起退款。从而减少商家输入商户订单号，这种繁琐的退款步骤。
此接口响应字段中的 支付链接（必填），是预下单之后返回的付款二维码。扫描付款二维码 进入到线上收银台 进行支付。
其他字段解读同【B扫C】。
使用场景主要在微信小程序或者支付宝小程序。
如果是微信场景：接口中小程序APPID和 用户标识 是必须传入的。响应结果中会返回拉起微信支付控件的必备参数。
如果是支付宝场景：接口用户标识必传。响应结果中返回支付宝订单号，是用来拉起支付宝控件。
其他字段解读同【B扫C】。
说明：微信小程序支付 和 支付宝小程序支付；对接此方法，还需要对接回调方法。
关键点：回调地址，微信subAppId，微信或支付宝用户ID。
刷脸支付，分为支付宝刷脸和微信刷脸。
此场景下依赖前端POS或IOT小程序较多。更多的是需要前端去初始化调用官方提供的文档接口。
支付宝，是前端直接调用平台接口获取刷脸付款码，然后调用B扫C接口便可以拉起支付。
微信，是需要后台提供一个接口拉获取微信刷脸调用凭证。
最终，前端调用刷脸识别SDK，获取刷脸付款码后，调用B扫C进行支付。
这里是微信获取刷脸调用凭证的接口，核心参数展示。
订单支付状态不明确时、需要查询订单支付状态等详细信息时，需要调用此接口。
核心请求参数，通常是只需要传入两个参数即可。平台商户号和订单号（商户平台支付订单号或者是上游平台的支付订单号）。
很多渠道方支付文档，都会优先使用渠道方的订单号。但站在开发对接者的角度是有漏洞的。
比如：新零售SaaS收银系统一笔支付单，请求上游渠道方支付完成，会存在无法拿到支付响应结果的情况。
因为在支付过程中，网络波动后请求超时，导致商户收银系统无法拿到上游返回的支付订单号。
所以此时，就需要订单支付查询接口，有一个商户平台支付订单号（下文中的orderCode）的 参数。
当存在这种情况时，商户收银系统依旧可以查询到支付结果。而不是，只能依赖渠道方订单号。
我们在审核渠道接口时，如果只能根据渠道方订单号查询订单详情，一定要向渠道方要求添加上商户平台支付订单号（orderCode）此参数。
核心请求参数：
退款必备关键性请求参数:refundNo（商户退款订单号，有时候此参数也不一定） 或 orderCode（商户支付订单号）；
如果存在多次退款的情况，reundNo（商户退款订单号）最好要有，方便追踪退款记录。
其他字段解读同【B扫C】。
此接口中，优先以商户平台单号查询，原因同【订单支付查询】。
其他字段解读同【B扫C】。
涉及字段解读同【B扫C】。
对接线上JSAPI 、C扫B.接口必接。退款和支付都会存在回调信息推送。
如果支付或退款回调地址是以下拼装的后缀是订单ID这种方式，需要注意下通道退款推送规则，规则可能有不同。
如:https://www.xx.cn/pay/orderPay/xx/1 是支付推送，https://www.xx.cn/pay/orderPay/xx/2 是退款推送地址。
通道方通常会按照此地址直接进行推送，但也会有少数通道按照支付接口中传入的回调地址进行推送。
涉及字段解读同【B扫C】。
回调接口响应必备参数：
响应内容按照接口文档要求即可，通常是返回 success,fail。
一笔支付请求来到支付核心要经历那些流程呢？
本文由 @PenguinPay 原创发布于人人都是产品经理。未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。