2014 年 10 月 - 捷克共和国，布拉格。
Maria 在 15 分钟内有一个重要会议。
但她没有现金打车。
所以她打开了叫车应用 Uber 并请求乘车。
虽然 Uber 处理支付令人惊叹，但”大规模”处理支付极其困难。
以下是其中一些问题：
核心挑战
1. 安全存储支付详情
用户在移动应用上添加支付详情。
但移动设备可能被盗，或者 Uber 服务器可能被入侵……
所以在移动设备和 Uber 服务器上存储敏感信息非常危险。
2. 分账
单笔支付必须分给不同的乘车参与者：
- 司机
- Uber 平台
- 税费等
即，钱不能简单地直接从乘客转移到司机。
3. 外部系统集成
支付包括”外部系统”如银行、卡网络和支付提供商。
但存在网络故障、超时和部分中断的风险。
这可能会造成可怕的用户体验。
Uber 支付架构
以下是 Uber 支付架构的工作原理：
1. 令牌化
用户在移动应用上添加支付详情，如信用卡号和 CVV。
但对他们来说存储这些数据是危险的，因为：
- 难以保护
- 需要繁重的法律合规
所以他们使用移动应用中的支付提供商 SDK 来收集敏感详情。
软件开发工具包（SDK）不会将卡信息发送到 Uber 服务器。
相反，它”安全地”收集信用卡信息并直接发送到支付提供商，以及上下文元数据。元数据包括 Uber 账户详情、支付方式类型（卡或钱包）等。
支付提供商然后返回一个唯一的令牌，它充当信用卡的”安全引用”。令牌代表卡；把它想象成（可重复使用的）充电卡的权限。
此外，支付提供商将接收的元数据绑定到令牌以限制其使用和验证。
从这一点开始，移动应用使用令牌而不是信用卡。
即，Uber 或移动设备没有敏感数据。
重要说明：
被盗的令牌是无用的，因为它由支付提供商创建，绑定到 Uber 的账户和应用，并限制于特定用途（如仅由 Uber 进行的收费）。所以其他移动设备或应用不能使用它来充电卡。
2. 分账
当乘车完成时，支付系统必须：
- 向乘客收费
- 向司机支付
- 向 Uber 支付平台费用
- 处理税费
这需要：
- 原子性（全部成功或全部失败）
- 幂等性（防止重复收费）
- 审计跟踪（合规性）
3. 外部系统集成
支付系统必须与：
- 银行
- 卡网络（Visa、Mastercard）
- 支付网关（Stripe、PayPal）
- 反欺诈系统
这引入了：
- 网络延迟
- 超时处理
- 重试逻辑
- 最终一致性
关键设计决策
1. 令牌化 vs. 直接存储
令牌化（Uber 使用）：
- ✅ 减少合规负担（PCI DSS）
- ✅ 降低数据泄露风险
- ✅ 支付提供商处理安全
- ❌ 依赖第三方
直接存储：
- ✅ 完全控制
- ✅ 无第三方依赖
- ❌ 繁重合规要求
- ❌ 高安全风险
2. 同步 vs. 异步处理
同步：
- ✅ 即时反馈
- ✅ 简单实现
- ❌ 高延迟
- ❌ 易受超时影响
异步：
- ✅ 低延迟用户体验
- ✅ 更好的错误处理
- ✅ 可重试
- ❌ 复杂实现
- ❌ 最终一致性
3. 数据库选择
SQL（如 PostgreSQL）：
- ✅ ACID 事务
- ✅ 强一致性
- ✅ 复杂查询
- ❌ 水平扩展困难
NoSQL（如 DynamoDB）：
- ✅ 水平扩展
- ✅ 高吞吐
- ❌ 最终一致性
- ❌ 复杂事务
本文为学习目的的个人翻译，译文仅供参考。
原文链接：Payment System Design。
版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。