通过“集成为先”的方法为支付终端构建商务平台-InfoQ

本文要点

所有支付终端都带有一个操作系统（也叫做“应用控制器”），并可通过不同程度的可编程性和访问能力让用户访问终端硬件的核心功能。

提供给开发者的 SDK 倾向于尽可能面向底层，开发者通常需要自行管理集成、安全性和认证等事宜。

Poynt 团队采用了一种集成为先的方法向外部服务提供 RESTful API。

这些 API 有助于简化集成与安全性，提供了更出色的开发者体验，使得开发者可以更容易地满足具体需求或实现与新型外设的集成。

今天的商业活动已经模糊了线上和线下的界线，可以通过任何可能的渠道开展。移动商务、语音商务、对话式商务……各种不同的商务方式组成了我们所说的全渠道商务。伴随着诸如物联网等创新技术的诞生，各种实体系统和流程相互之间的交互方式与传统的互联互通方式产生了巨大的差别。跨越物理和虚拟系统的技术和交互方式，客户的购物行为，以及构建全渠道体验的能力等技术革新不仅需要构建API，而且需要在此基础上采取截然不同的方法。商务平台所用的系统和组件在设计和构建过程中必须考虑到互联性、互操作性以及可扩展性，这样才能帮助开发者打造更新颖的购物体验。这正是我们所说的“集成为先”的方法。本文我们将介绍 Poynt 构建这种商务平台的方法。

这一切该从何处着手？

在开始详细介绍“集成为先”的方法前，先来看看支付终端的一些基本组件，以及这些组件所扮演的角色。传统的支付终端主要用于处理基于银行卡（信用卡 / 借记卡）的支付交易。
这类系统通常包括：

读卡器 - 终端的核心组件，提供了所有银行卡（磁条卡、芯片卡、NFC 卡）所需的全部物理和逻辑接口。
显示屏 - 向客户 / 商家展示数据和信息提示（如收费金额，或要求客户输入 PIN 码或支付类型）。
外部硬件接口 - 通过各种物理（RJ11/ 串口 /USB）和网络接口（以太网 /WiFi/ 蜂窝网络）提供输入 / 输出连接能力。这些外部接口是支付应用程序为商家获取支付授权，访问小票打印机或 POS 系统等外设的唯一方式。
打印机 - 大部分支付终端都会包含内置的小票打印机，用于打印交易小票。
密码键盘 - 用于安全地输入 PIN 码、金额和处理支付交易所需其他信息的数字键盘。
支付应用程序 - 让一切组件配合工作，借此让商家正常处理支付的软件。这种软件负责在读卡器、显示屏以及支付的处理方 / 受让方所需的其他接口之间进行协调。

除了终端本身，大部分终端供应商还会提供其他服务 / 功能，例如：

终端 / 资产管理 - 借此可远程管理每个终端的维护、软件更新、技术支持等工作。
安全性管理 - 借此管理读卡器配置、加密密钥等内容。

然而大部分终端都将其视作单独的组件，只向这些物理和逻辑组件提供了非常底层的访问（大部分情况下只提供设备驱动层面的访问）。虽然对开发者来说，这样的做法听起来极为灵活，可以让开发者按照需要的任何方式使用这些组件，但却会在集成、安全性、认证等方面造成挑战。

集成方面的挑战

所有支付终端都带有一个操作系统（也叫做“应用控制器”），并可通过不同程度的可编程性和访问能力让用户访问终端硬件的核心功能。通常，终端都会为应用程序开发者提供 SDK，借此开发者可以构建自己的应用程序，开发好的程序需要首先提交并进行认证，随后才允许安装到商家使用的真正的支付终端上。

每个应用程序可以提供一系列截然不同的功能，通过终端上的应用程序控制器接口供给商家使用。然而能帮助这些应用程序相互配合使用的框架或接口很少，甚至完全没有，这导致商家需要运行各种相互独立的应用程序。例如当我们在商店购物时，面对不同需求，商家必须使用不同的按键组合来调用不同的应用程序（例如礼品卡或信用卡，信用卡或借记卡等）。

安全性方面的挑战

针对这些平台构建的应用程序通常运行在安全的环境中，因此需要满足 PCI 委员会、银行卡网络以及收单银行的所有安全需求。

然而尽管这些安全需求对保护敏感的客户支付卡信息来说是必不可少的，但实现起来需要付出一定的代价。

额外的需求导致支付应用程序的开发程本激增
需要更长时间的测试和认证过程，并且
部署时间进一步延后导致新功能的效益大幅降低，而不灵活的软件管理也会对软件开发周期产生不利影响

认证方面的挑战

正如上文所述，每个支付终端必须获得不同监管机构与金融组织的各种严格认证，随后才能部署到商家店铺内处理交易。这些认证包括俗称的 L1 认证（接触式和非接触式，硬件和通信层认证）、L2 认证（接触式 EMVCo 认证，以及不同支付网络的非接触式认证），同样重要的还有运行了支付应用程序的终端需要集成到的每个收单银行 / 处理银行所要求的认证。这些认证过程需要通过额外的测试工具（相当昂贵）运行并评估支付网络所定义的所有测试案例，随后才能提交并等待必要的批准。

构建平台

面对这些挑战，考虑到我们的目标是促进更简单的集成和集成式体验，我们的方法首先会将硬件和软件组件拆分为多个抽象层，并根据集成方面的需求将相关功能以 API 的形式暴露。

这一过程中我们建立了一些核心的基本原则：

终端的每个组件都有 API（API 为先的方法） - 从渲染自定义的 UI 消息并显示在屏幕上，到通过处理银行处理交易，一切都通过 API 的方式进行。
数据和 API 可扩展到终端之外 – 可以通过简单的 RESTful 外部接口供任何需要的系统或应用程序使用。
应用内部，以及应用与外部组件的互操作性是必备条件。
应用之间不进行一对一的自定义集成。
与生俱来的安全性 – 安全性不再仅仅是可选项。
简化集成 – 无需自定义工具，开发者可以使用任何主流的现代化开发和排错工具。

按照这些原则，我们定义了下列核心服务来抽象必要的功能：

（点击放大图像）

读卡器服务（Card Reader Service） - 我们并未直接提供底层的读卡器访问接口，因为这会让任何人均可访问敏感的银行卡数据，相反我们会为需要的应用程序提供处理银行卡数据的功能 API。例如执行卡片交易进行支付，读取非银行卡中的会员信息等。读卡器服务内的所有数据都被加密，因此可彻底杜绝将任何敏感数据暴露给应用程序，进而需要进行 PCI 合规认证的情况。
商务服务（Commerce Service） - 为各种与商务有关的功能提供支持，例如订单管理、交易管理、客户管理、分类 / 产品等，并且通过这种方法可以用一致的方式呈现与商务有关的各类数据源。这些商务服务也成为终端中运行的所有应用程序相互实现互操作，实现不同商务活动的核心集成点。
支付体验（Payment Experience） - 为所有支付方法提供标准化的体验，同时省略了为每个集成分别进行支付验证所造成的不必要的负担。
配件管理服务（Accessory Management Service） - 提供了包含不同服务的目录，借此处理连接到终端的各种外部附件（例如打印机、磅秤、现金抽屉、登记簿、POS 系统等）的连接，并通过更简单的方法与其交互。我们为不同类型的配件定义了不同的 API 合约。例如现金抽屉配件的接口只提供了简单的"open()"和"isOpen()"方法，并不提供向所连接的抽屉发送打开指令的底层 USB 命令。
能力管理服务（Capability Management Service） - 为平台安装的不同能力提供了一个统一的目录，借此可直接连接并使用不同能力。涉及到的能力包括交易处理、小票打印、会员忠诚计划、折扣、客户管理等。在跨越终端上运行的各种应用程序提供互操作性方面，能力管理功能扮演了重要的角色。
外部连接器服务（External Connector Service） - 通过这样的一个接口将终端可用的大部分接口暴露给通过 USB、蓝牙或网络连接的外部应用程序。
云服务（Cloud Service） - 通过必要的接口将终端上运行的服务扩展至终端范围之外。这些服务可用于访问同样的功能，但更重要的是，可用于通过云平台访问同样的商务数据，借此即可轻松访问云端运行的应用。云服务还为读卡器、安全密钥管理等组件提供了必要的配置管理功能。

为了从实现以及集成的角度展示这些组件的配合方式，我们将以 Poynt 智能终端上进行的一次端到端支付交易流程为例进行介绍。

在终端上，每次交易始于商户经营业务所用的应用程序。下列流程示意图展示了 Poynt 智能终端上处理交易时的所有步骤和阶段。红色高亮显示的内容代表相应服务提供的功能 API。

（点击放大图像）

总结

虽然整个过程看似十分冗长，但尤其需要注意下列几个重点：

功能 API（Functional API） - 通过更高层的抽象大幅降低了集成的工作量。
服务发现（Service Discovery） - 发现终端上可用服务的能力使得开发者可以灵活查找最能满足应用程序需求的服务。无论是用于发送邮件的服务，或处理交易的服务，甚至渲染一个界面向顾客收集信息的服务，以编程的方式发现并连接服务的能力不仅为应用开发者带来了巨大价值，而且大幅提高了整个平台的可扩展性。
资源模型（Resource model） - 取决于组件 / 服务的具体类型，虽然每个组件的 API 在协议格式上可能有所不同，但跨越不同组件 / 服务提供并维持一致的数据模型对互操作性的实现起到了极为重要的作用。
- 这不仅有助于无需太多转换即可跨越不同 API 传输数据，而且有助于将数据模型扩展为 RESTful API 供云中运行的应用程序使用。
通过标准化 API 接口实现互操作性 - 虽然服务发现能力可以帮助我们在需要时方便地找到可用服务，但如果服务接口没有实现标准化，并且并非由平台预先定义的，那么在集成方面所起到的价值将非常有限。为整个平台所支持的全部能力和配件服务定义并提供标准化接口框架是让整个平台获得更高扩展能力的关键步骤。我们不可能预测出未来的所有需求和可能需要的功能与配件，因此这也是一个持续发展的步骤，借此可以帮助开发者通过形成一个生态体系自行定义自己需要的内容。

这种以 API 为先的方法对任何公司或产品来说都有一定的必要性，借此可以更好地专注于系统和（内部与外部的）应用程序相互集成和互操作的方法，进而推动整个平台获得更大的成功。

关于本文作者

Praveen Alavilli 是 Poynt 的资深创始工程师，一举促成了 Poynt 智能终端及其开放式商务平台的技术基础，并通过努力让该平台面向支付技术的未来做好了准备。在加入 Poynt 之前，Alavilli 曾在 PayPal、eBay、Amazon 和 AOL 等支付、身份、身份验证和安全领域的不同公司担任架构师和技术主管职位。Alavilli 长期拥护开放式标准和开放的开发者生态系统。