探讨某企业支付平台在网页支付网关方面的架构设计及其用户体验的改进策略

开题

随着网络支付手段的日益成熟，它们已经不可避免地开始与各种信息技术系统相融合。在那些财务管理制度较为健全的地区，对这类资金入账实施统一管理显得尤为重要，确保资金流动的有序性。若由各个业务系统自行申请接入网络支付接口，统一管理将变得极为困难，同时也会带来诸多不便。

因此，必须构建一个统一的企业级支付平台作为桥梁，负责连接各个业务系统与网络支付。通过这种方式，不仅能够简化财务数据的集中提取和账户核对流程，还让企业支付平台能够代为所有业务系统与网络支付接口进行沟通，确保业务系统无需直接接触企业网络支付的总密钥，从而提升了安全性和可控性。

实际上，这类情况我们日常生活中屡见不鲜。比如，购买车票时进行的支付操作、教育部考试中心收取的考试费用支付，都采用了中间层技术，以此接入众多网络支付渠道。

此刻，企业级支付平台的作用相当于一个中介，它帮助业务系统处理支付流程，并妥善保管相关资料。目前，这类“中介”的架构尚无统一标准，因此其具体实现存在细微差异。企业级支付平台（以下简称企业层）与业务系统各自职责的界定，将直接决定架构的具体构建方式，进而对支付业务的执行效果产生重要影响。

的实现思路

这里将向大家展示一个正在运营中的企业级支付系统，该系统现已与微信企业版中的微信支付功能实现对接，并且未来计划将支持更多网络支付方式。

每个业务系统都将获得一个“子商户”的分配，此子商户将配备专属的ID和密钥。这样，当业务系统通过这些子商户发起支付请求时，它们将自行管理网络支付接口的密钥。与此同时，应用系统仅能通过这些子商户来获取网络支付的相关结果信息。

当前的架构和支付流程

上图的流程实际上运作得相当顺畅。应用系统所承担的任务并不复杂，只需生成并保存应用端的订单详情，随后将订单信息一次性通过前台POST至指定网页，该网页将协助应用系统完成支付环节，而应用系统只需负责接收支付结果即可。

在此处，该角色的定位远不止是“代理”那么简单，它还需协助应用系统完成支付流程，并在其中对支付环节进行监管。为了方便称呼，我暂且将它命名为“富代理”。

为了更清晰地阐述“纯粹代理”的具体情形，我构建了一个新的操作流程。在这个流程中，业务系统将视为网络支付的服务器，因此传输给该系统的ID可以是具有独立编号的子商户。在将请求提交至网络支付平台时，还需使用网络支付平台统一的密钥。

如果变成一个纯粹的代理，会变成这个流程

代理与否，其利弊显而易见。事实上，目前市面上普遍采用的是“富代理”的解决方案。

富代理“富代理”角色可以多做这点判断

企业面临诸多任务，在这种角色定位的前提下，对于每一笔支付业务，系统究竟需要向企业层传递多少参数呢？

依据内部公开的资料，目前在进行支付订单的创建过程中，必须向该系统传输一系列特定参数。对此，我进行了详细的分类整理。

订单内容（必须）订单内容（增强）

实际上，这套接口的参数设置大多源自微信支付，主要是进行参数的转发，采用现成的参数名称并无不妥。

您留意过这个“参数”了吗？实际上，它是用于微信支付的。目前微信支持的数值包括：微信内浏览器、用户扫码支付、APP（手机应用）、MWEB（微信外手机浏览器）以及商户条码支付。我们的系统会根据业务系统提供的参数，向浏览器反馈不同的界面，以实现相应的功能。

那么，这个参数真的要靠业务系统来给定吗？

尤为关键的是，这三种模式与特定的网络支付接口紧密相连。若未来需接入新的网络支付方式，最佳策略是业务系统无需关注具体支付模式的参数，而是让用户自行选择，如此一来，业务系统无需进行大规模的修改，岂不是更加有趣。

结论是，该模式有必要进行整合。考虑到MWEB、、和这三种模式在本质上都属于网页支付，我们可以在前端将其统一命名为（例如HTML），并由前端进行选择，而不应让业务系统负责这项选择。若业务系统仍传入这三个序列，则统一导向新的HTML模式即可。关于该APP及其相关功能，目前来看，本系统并未采纳，故此，此类方法暂且留作备用。

支付中间层如何判断支付模式？

既然我们提出了这一方案，便需思考，若缺乏业务系统数据支撑，支付层是否能够高效独立地确定支付方式？答案显然是肯定的。

在处理支付中间层的问题时，最棘手的环节往往是事先必须与网络支付平台建立订单，而在这一过程中，还需明确选择恰当的支付方式。

有这样一个可靠途径，即先在前端对微信的可用性及手机（微信）的存在性进行核实，随后根据实际情况进行订单的异步开启。然而，这种方法无疑较为繁琐，因此，采用较为直接的后端用户检查方式，便能在大多数情况下实现正确且及时的判断。

所以是：

所有其他情况均遵循订单流程；或者，若您愿意尝试兼容MWEB（在此模式下，手机浏览器可直接启动微信，体验更佳），则需在UA判断中检查是否包含“或”“/iPad”标识，若存在，则进入MWEB，若不存在，则需扫码操作以确保100%的可靠性，为此，我们需在“端”提供模式切换功能，但切换模式时必须关闭订单，并重新生成订单号以供网络支付使用，这一过程颇为繁琐，因此，我们认为没有必要进行EOF操作。

本文所引用的资料均源自网络公共信息，插图系本人亲手绘制，未涉及任何保密内容。如今，我得以放下心来，专心投入到学习中。

本篇文章遵循知识共享“署名-非商业性使用 4.0”许可协议进行发布，如需获取额外授权，请与我取得联系。

最后编辑于 ：2017.12.10 04:40:56

©著作权归作者所有,转载或内容合作请联系作者