技术文章
支付网关集成入门
要让一款支付应用顺利上线运行，至少需要处理两种不同类型的集成工作：首先，您需要了解如何集成所需的硬件（即读卡器以及与之相连的设备）；其次，您需要了解如何与支付"后端"进行集成，例如在线支付网关（即负责"批准"交易并将其送交结算的一方）。
在 此前的文章我已多次讨论过此难题中的硬件集成部分，事实证明这并不算特别困难，因为使用 ID TECH 读卡器时，您可以借助我们的 通用 SDK 在高级语言环境中与设备进行通信；如果您愿意在架构中引入 Node JS，也可以采用纯 JavaScript 解决方案。无论采用哪种方式，与 ID TECH 设备通信都不算什么难事。
但问题依然存在：在让读卡器读取卡片芯片或磁条信息之后，如何将这些信息转换为已批准的交易呢？
想必您已经确定了哪家信用卡处理机构将受理您的请求。所以，问题归根结底就是要弄清楚您的处理机构或网关提供何种 SDK 支持，用以完成在线请求。
大多数网关或处理机构都设有开发者计划或在线开发门户，您可在那里获取用于构建支付应用的 SDK。这些 SDK 通常允许您构建前端和后端组件的组合，以访问处理机构的支付 API。支付 API 则支持将磁条数据和/或 ICC（芯片卡）数据通过网络提交到后端处理机构，以获取实时授权。
支付授权实际上只是您可能需要支持的几种在线请求类型之一。其他一些请求类型如下表所示。
请求类型
说明
授权
请求支付授权
确认
确认先前的授权请求
离线
结算离线 EMV 交易
预授权
通过小额交易确认卡片信息有效
退款
对已结算交易进行退款
测试
测试与处理机构的连接
语音转接通知
将语音转接请求的结果通知处理机构
撤销
用于撤销尚未结算的交易
如果您仔细研究支付处理机构的 SDK 文档，会注意到每种交易类型都对应着相当数量的结果代码和/或错误代码。如何针对所有这些可能的错误类型进行测试呢？答案是：大多数处理机构都设有一种机制，可将交易金额的分位数设为特定值，以便在测试沙箱环境中触发特定错误。（例如，如果"金额过大"的错误代码为 1243，SDK 可能允许您通过提交金额为 12.43 美元的测试交易来触发该特定错误。）具体细节请查阅您所用服务提供商的 SDK 文档。
许多支付处理机构都提供经过预先认证的（半集成式）"应用内"解决方案，能够将加密的卡片数据较为透明地直接路由到后端，从而使您的支付应用免受"PCI 合规范围"约束；而另一些处理机构则默认由您自行处理"合规范围"问题，这种情况下，您可能需要将加密的卡片数据通过网络发送到您自己位于防火墙后的服务器应用，并借助 HSM 解密卡片数据，然后再路由至收单机构或网关。
高层次的概述就到这里。下面我们来谈谈在实际操作中，与支付后端集成究竟意味着什么。
显然，这个具体示例并不适用于所有场景（任何单一示例都做不到这一点），但它应该能让您初步了解，在与后端进行集成时可能会遇到的情况。
当时，我的任务是搭建一个"虚拟终端"演示应用，将交易数据发送至 CreditCall 测试服务器，以获取 EMV 交易的实时授权。CreditCall 提供了一套后端服务器 API，可通过 HTTPS 使用其 ChipDNA Direct API进行访问，进而可使用 Java、C++、Perl 或其他语言的 SDK 进行"针对性开发"。我选择了 Java 版本。
在 ChipDNA Direct 在该网站上，我注册了一个开发者账户，并很快通过电子邮件收到了用于访问 CreditCall 测试服务器的凭证。我还下载了 CreditCall 的 Java SDK，并开始查看示例代码。我特别想学习如何提交 EMV 交易以进行授权。幸运的是，其中一个示例代码文件 ExampleAuthEMV.java 正好展示了我所需的代码类型。
我开始编写两个 Java 类：一个 servlet 类，用于处理来自基于浏览器的前端的 HTTP 请求；另一个是"worker"类，用于将（由 servlet 获取的）浏览器数据传递到 CreditCall 后端。前者最终约 250 行 Java 代码，后者为 92 行。
我不打算展示 servlet 类的代码，因为它基本上是标准的 Java servlet 代码，唯一不同的是，它接收 TLV 值（通过 AJAX 作为表单字段值提交），并在运行时将其放入一个 java.util.Hashtable 对象中。然后该 Hashtable 被传递给我的 worker 类的静态 authorize() 方法。worker 类使用 CreditCall ChipDNA Direct SDK 辅助（库）类创建一个 com.creditcall.Request 对象，该对象随后被传递给一个 Client 对象，再由其调用 CreditCall 服务器。代码如下：
这段代码非常简短且不言自明，几乎不需要进一步评论。它的精妙之处在于 CreditCall 的 请求 并 客户 类会处理好创建最终发送到 CreditCall 服务器所需的 XML 文档。作为开发者，您无需亲自查看、接触、解析或操心原始 XML（正如大自然所期望的那样）。
请注意，您需要在第 18 行和第 19 行提供您的测试账户凭证。（上面所示凭证为虚构内容，请勿原样使用此代码！）第 69 行用于设置 CreditCall 端点的 URL。第 72 行发出实际的出站 HTTPS 调用。
CreditCall 服务器对您在交易数据中发送哪些 TLV 标签并不特别挑剔，只要包含含有关键卡数据的标签即可（例如：接触式 EMV 的标签 5A 和 57；非接触式的标签 56；以及包含密文信息的 9F26 和 9F27）。作为对您 EMV 数据的响应，CreditCall 服务器通常会返回标签 8A、89 和 91 的 TLV，并可选地返回 71 或 72（如果需要向芯片卡传送脚本）。您所需的授权码位于标签 89 中。
通过反复试验，我了解到 CreditCall 服务器应用并不会仅仅因为卡片返回 AAC 密文就立即拒绝交易。（您可以通过检查标签 9F27 的高位来判断密文类型。全 0 表示 AAC，即拒绝。）这其实并不意外，因为卡片的判断仅仅是"建议"。EMV 交易最终的通过或拒绝通常由收单方决定。卡片的判断可以被（并且经常被）推翻。
正如您所见，通过实践操作，您会了解到许多关于 EMV 的有趣细节。在验证支付应用代码时，没有什么能比进行真实的授权交易更有效！
想了解更多关于 EMV 交易的建议？请访问我们的 开发者主页 （位于 ID TECH 知识库）。下载我们的 EMV 开发白皮书。或拨打我们的免费专家热线，开始使用评估套件：