如何选择合适的发卡提供商：5 大技术要素

随着市场转向在线和移动支付方式，卡类支付行业呈现出快速发展的势头。而处理提供商和发卡提供商会给销量、客户获取、留存和增长情况带来巨大影响。市面上的提供商比比皆是，比如 Marqeta、GPS、I2C，你如何判断应选择哪家呢？ 

从我们助力客户建立行业合作关系和构建数字银行产品的工作中，我们已经看到了 API 和技术评估的重要性，在寻找适合当下和未来的合适提供商的流程中经常会忽略到部分内容。 

以下是要在发卡策略（自开始之际即投入使用）中考虑的五大要素。  

1.审查平台功能时不局限于一眼可见的功能

必须彻底检查潜在发卡系统的功能，在考虑相比 I2C、GPS 和 Marqueta 等大型参与者更加实惠的选项时尤其如此。例如，大部分企业希望获得消费控制功能。简单检查下此功能是否位列于 API 清单中，还不足够。要查看与产品目标一致的特定功能。是否需要获得将每天消费上限设为 $500 的功能？或者，你是否想要将消费限于特定商户类型，例如不允许进行娱乐交易的企业支付解决方案？或者两种功能你都想收入囊中？

你需要先回答这些问题，再选择发卡服务提供商。不然，你可能需要自行构建此功能（而非直接从发卡提供商获得此功能），因此而需承担非预期费用。

2.实现 PCI DSS 合规性（不接触敏感数据） 

卡片品牌需强制执行《支付卡行业数据安全标准》(PCI DSS)（若企业在运营过程中涉及敏感支付数据，例如通常称作 PAN 的卡号以及 CVV）。 

我们许多客户属于中小企业，专注于发展自身业务，不想经历冗长且代价高昂的认证流程。你应将有限的时间和资源用于哪些方面？

如果你在运营过程中需用到敏感支付数据，但你甚至无需接触这类数据，那实现 PCI 合规性要容易许多。 

可通过以下两种方式实现这一点：

1.确认发卡机构是否提供 API 流程，可让敏感卡片数据绕过你的服务器。通常可通过以下方式实现这一点：在后端发放临时客户令牌；可通过移动应用程序使用此令牌，经由发放平台 API 直接获取完整的卡号。 

2.许多提供商不具备此类 API，但是可通过其他方式简化 PCI 合规性：使用 VGS 等厂商的标记化解决方案。从本质上而言，他们会向你提供两个代理供你安装，此后所有敏感数据在进入你后端系统的过程中会作标记化处理，在离开后端系统后即会取消标记化处理。

3.确保事件订阅 API 设立到位

可通过多种方式与处理合作伙伴实现集成。我们经常向客户推荐的一种用于构建精密银行解决方案的方式是：同步账号、卡片和交易数据至数据库。 

这种做法不仅可以改善应用的性能（与移动应用和发卡提供商之间的代理 GET 请求相比），而且所有这些数据可用于实时分析及形成业务相关见解。

若发卡企业拥有事件订阅 API（通常作为 Webhook 予以实施），是优势所在。在此种情况下，你只需订阅事件（例如余额已改变、新交易、卡片发货状态已改变等等）并存储数据。若不具备此类 API，最糟糕的情形便是：你会需要自行迭代所有财务账户、轮询更新并检查已发生的变化。 

如果你准备构建 BNPL 产品或者只是想自行管理账户和余额，则即时 (JIT) 付款 Webhook 是合适之选。你将能够按照与支付解决方案最为匹配的方式处理卡片授权事件。例如，在发起 JIT 支付请求后，你可运行快速信用核查、验证商户和交易，以及批准购买行为。 

4.关注 API 验证

大多数发卡流程提供商至少拥有基于密钥的 API 验证功能，你在服务器对服务器集成中需要用到此验证。有一点值得确认：他们是否允许构建多个密钥。凭借这一功能，能够实施零停机密钥轮替。

我们当前看到提供的另一种验证方式是 OAuth2。但是，它并非适用于服务器对服务器通信的最佳方式，原因在于你会需要在所有使用令牌的位置确保访问令牌保持“更新”。然而，如果你在找寻通过无服务器方法快速构建数字钱包的方式，而且发卡机构具备对应功能，可成为用户的验证和身份提供商，则它是验证方法的不二之选。

5.确认沙箱环境拥有你所需的所有功能

发卡与卡片处理提供商会始终提供沙箱环境的访问权，但是其是否会针对你想要实施的所有场景执行模拟？

从我们的经验来看，答案通常为“否定”。例如，在实施实体卡片发放操作时，可能无法模拟不同的卡片状态（已发送至打印机、已打印、已发货等等）。对你而言，这意味着你将仅能够在生产环境中测试某些功能，会增加缺陷检测的成本。

选择适用于长期的合适的发卡提供商 

发卡策略会影响到你的产品路线图、用户体验、合规性以及上市情况。利用这些要素来评估所有潜在和现有的厂商，找寻合适的长期合作伙伴，获得所需的灵活性、支持和工具，来发展业务以及成功开展卡片项目。