支付网关测试用例：类型和检查清单
托马斯·汉密尔顿
支付网关测试
支付网关测试 是针对用户在线购买和交易的系统中的支付网关的测试。支付网关测试的目的是通过加密和保护用户和商家之间的支付详细信息来确保支付网关的安全性、可靠性和性能，同时提供顺畅的支付体验。
支付网关系统是一种 电子商务应用服务 批准在线购物的信用卡付款。支付网关通过加密敏感信息（如信用卡号、账户持有人详细信息等）来保护信用卡详细信息。这些信息在客户和商家之间安全传递，反之亦然。现代支付网关还可以安全地批准通过借记卡、电子银行转账、现金卡、奖励积分等方式进行的付款。
因为支付网关位于购物者、商家和银行之间，所以网关出现任何故障都会立即停止收入。
支付网关系统的类型
不同支付网关的区别在于购物者输入卡片详细信息的位置，如下所示。
托管支付网关
托管支付网关系统在支付过程中将客户从电子商务网站引导至网关链接。付款完成后，它将把客户带回电子商务网站。对于此类付款，您不需要商家 ID，托管支付网关的示例包括 PayPal、Noche 和 WorldPay。
共享支付网关
在共享支付网关中，处理付款时，客户会被引导至付款页面并停留在电子商务网站上。填写付款详细信息后，付款流程将继续进行。由于处理付款时客户不会离开电子商务网站，因此这种模式简单且更受欢迎，共享支付网关的示例有 eWay、Stripe。
自托管、API托管和移动钱包网关是其他变体。
为什么支付网关测试很重要
结账页面是顾客完成购买的最后一步，因此任何缺陷一旦出现都会造成经济损失。系统化的测试能够防患于未然，在顾客遇到问题之前就发现并解决它们，从而保障这一环节的安全。
- 保障收入： 交易失败或速度缓慢会导致购物者放弃购物车，而放弃的购物车很少会再次被购买。
- 建立信任： 卡片信息经过掩码处理，流量经过加密，确认信息清晰，让买家放心，他们的资金得到了妥善处理。
- 防止欺诈损失： 通过验证 CVV 规则、地址验证和速度检查，可以在货物发货前阻止欺诈订单。
- 确保商家合规： 信用卡系统需要强大的客户身份验证，而测试结果可以证明这些控制措施是有效的。
- 降低支持成本： 重复收费、收据缺失和退款卡住都会导致高额罚单和拒付。
- 及早发现缺陷： 在沙盒环境中修复集成错误所需的成本远低于在生产环境中断后修复该错误的成本。
这些益处取决于测试类型的正确组合，如下所述。
支付域的测试类型
支付网关测试应该包括
功能测试：这是测试支付网关基本功能的行为。它是为了验证应用程序是否按照预期的方式运行，例如处理订单、计算、根据国家/地区增加增值税等。
之路：测试与您的信用卡服务的集成。
性能：确定各种性能指标，例如特定日期通过网关的最大用户数，并将其转换为并发用户
安保防护：您需要对支付网关执行深度安全检查。
添加 本地化测试 就货币和语言而言， 兼容性测试 对于设备，以及 回归测试 每次提供商 API 更新后。
如何测试支付网关：完整清单
开始测试之前 –
- 收集 maestro、visa、master 等虚拟信用卡号的适当测试数据。
- 收集支付网关信息，例如 Google 钱包、PayPal 或其他
- 收集带有错误代码的支付网关文档
- 了解通过应用程序和支付网关传递的会话和参数
- 理解并测试通过查询字符串、变量或会话传递的相关信息量
- 除了支付网关语言外，还请检查应用程序的语言
- 在支付网关的各种设置下，如货币格式、收集订户数据。
提示： 将每个预期故障映射到已记录的提供商错误代码，以便将模糊的“付款失败”缺陷变成可重现的工单。
如何搭建支付网关测试环境
可靠的测试结果始于一个模拟生产环境但不涉及真实资金流动的沙箱环境。几乎所有服务提供商都会提供一个沙箱，该沙箱镜像了真实的 API，但不进行任何实际交易，而大多数支付网关测试都应该在这个沙箱中进行。
- 请求沙箱凭证。 获取单独的商户 ID、API 密钥和密钥，并将它们存储在源代码库之外。
- 将应用程序指向沙盒端点。 从网络日志中确认没有请求到达实时网关主机。
- 加载官方考试卡片。 每种方案都会公布一些数字，这些数字会导致一个固定的结果：批准、拒绝、资金不足、卡片过期或卡片丢失被冻结。
- 绝对不要复制生产数据。 PCI安全标准委员会 规则禁止在测试环境中使用真实的持卡人数据，因此需要屏蔽所有记录。
- 启用3D安全测试模式。 触发无摩擦流程和挑战流程，以便执行重定向、超时和取消路径。
- 注册一个 webhook 接收器。 付款状态通常是异步到达的，因此请确认收款、退款和拒付通知已更新订单记录。
- 模拟网络故障。 通过代理放弃或延迟响应，并确认购物者重试时不会出现重复收费。
- 运行间重置状态。 清除购物车、会话和存储的令牌，以免过期的会话掩盖缺陷。
维护一份简短的沙箱运行手册 URL测试卡号、测试卡编号和预期响应代码。它允许新测试人员立即重现任何场景，并可作为审计证据。
警告： 切勿使用测试套件直接访问真实凭证。即使是真实卡片上的一次误操作，也会造成财务损失和合规性违规。
支付网关测试用例示例
以下是检查支付网关的重要测试场景/案例
| 先生＃ | 测试用例 |
|---|---|
| 1 | 在付款过程中尝试更改支付网关语言 |
| 2 | 付款成功后，测试所有必要的组件，无论是否检索 |
| 3 | 检查如果支付网关在付款期间停止响应会发生什么 |
| 4 | 在付款过程中检查会话结束时会发生什么 |
| 5 | 在支付过程中检查后端发生的情况 |
| 6 | 检查支付过程失败时会发生什么情况 |
| 7 | 检查数据库条目是否存储信用卡详细信息 |
| 8 | 在支付过程中检查错误页面和安全页面 |
| 9 | 检查弹出窗口阻止程序的设置，并查看打开和关闭弹出窗口阻止程序时会发生什么情况 |
| 10 | 在支付网关和应用程序检查缓冲页面之间 |
| 11 | 检查付款是否成功，成功代码将发送到应用程序，并向用户显示确认页面 |
| 12 | 验证交易是否立即处理或由银行处理 |
| 13 | 交易成功后，检查支付网关是否返回到你的应用程序 |
| 14 | 付款成功后检查所有格式和信息 |
| 15 | 除非你没有支付网关的授权收据，否则不应发货 |
| 16 | 通过电子邮件通知所有者任何交易的处理情况。加密邮件内容 |
| 17 | 检查金额格式与货币格式 |
| 18 | 检查每个付款方式是否可选 |
| 19 | 检查列出的每个付款方式是否按照规范打开相应的付款方式 |
| 20 | 验证支付网关是否默认为所需的借记卡/信用卡选项 |
| 21 | 验证借记卡的默认选项显示卡选择下拉菜单 |
下一个决定是：这些场景中哪些值得写成剧本？
手动与自动支付网关测试
两种方法都适用于付费方案，关键问题在于哪种方法更适合哪种场景。人工操作在新集成和任何需要人工判断的环节最为有效。而自动化则更适合处理每次构建都必须经过的稳定、重复性流程。
| 方面 | 手动测试 | 自动化测试 |
|---|---|---|
| 最适合 | 探索性检查首次集成、视觉和文字审核 | 每次部署都进行回归测试和冒烟检查 |
| 速度 | 速度慢；一次只能由一名测试人员运行一个测试场景。 | 速度快；许多场景并行运行。 |
| 成本概况 | 前期投入少，后续投入高 | 前期投入高，后续投入低 |
| 典型工具 | 浏览器开发者工具和沙盒控制面板 | Selenium, Appium, Postman API 检查 |
| 主要弱点 | 难以扩展到多种卡片类型或负载级别 | 对布局和可用性问题视而不见 |
一个切实可行的方案是，针对每种卡类型，自动处理成功、拒绝和退款流程，而将手动处理流程保留给新版网关。分别驱动负载配置文件。 JMeter.
购买网关套餐前需要考虑的事项
- 如果你买了一家店铺ping 购物车包装，了解其兼容性
- 如果商店ping 支付网关套餐到期后，请向支付网关提供商索取支持的应用程序列表。
- 网关必须提供地址验证系统保护
- 了解所提供的交易保护类型
- 检查您选择的支付网关接受哪些类型的借记卡或信用卡
- 检查支付网关征收的交易费用
- 检查网关是否在表单上收取付款或直接转到另一个页面完成购买
