多年来，Airbnb 支持信用卡和借记卡作为客人支付住宿的主要方式。

然而，如今 Airbnb 在全球 220 多个国家运营，虽然卡片在许多地区运作良好，但仅依赖这种方法会排除数百万潜在用户。在信用卡渗透率低或人们强烈偏好本地支付方式的国家，Airbnb 正在失去预订并限制其增长潜力。

为解决这个问题，Airbnb 工程团队启动了”像本地人一样支付”计划。目标是在短短 14 个月内在多个市场集成 20+ 本地首选支付方式。

在本文中，我们将看看使这次扩展成为可能的技术架构和工程决策。

免责声明：这篇文章基于 Airbnb 工程团队公开分享的细节。如果你发现任何不准确之处，请评论。

本地支付方式

本地支付方式（LPM）扩展到传统支付卡之外。它们包括韩国的 Naver Pay 和肯尼亚的 M-Pesa 等数字钱包、整个欧洲使用的在线银行转账、巴西的 PIX 和印度的 UPI 等即时支付系统，以及 EFTPOS 和 Cartes Bancaires 等区域支付计划。

支持 LPM 提供几个优势：

  1. 提高转化率：提供熟悉的支付选项提高结账转化率
  2. 解锁市场：解锁信用卡使用极少或不存在的市场
  3. 提高可访问性：改善缺乏信用卡或传统银行访问的客人的可访问性

Airbnb 团队通过初步研究确定了全球 300 多种独特支付方式。在第一阶段，他们使用资格框架缩小列表。他们评估了前 75 个旅行市场，每个市场选择前 1-2 种支付方式，排除没有明确旅行用例的方法，最终确定了 20 多种适合集成的 LPM 短名单。

支付基础设施现代化

在构建 LPM 支持之前，Airbnb 需要现代化其支付基础设施。

原始系统是单体的，意味着所有支付逻辑存在于一个大型代码库中。这种架构产生几个问题：

  • 添加新功能需要大量时间，新功能上市时间以月计
  • 不同团队无法独立工作
  • 系统难以扩展

Airbnb 实施了名为 Payments LTA（长期架构）的多年重新平台计划。团队从单体系统转向按领域构建的能力导向服务系统。这种方法使用领域驱动分解，其中系统根据业务能力分解为更小的服务。

整个练习后，Airbnb 的核心支付域由多个子域组成：

  • Pay-in 子域：处理客人支付
  • Payout 子域：管理房东支付
  • 交易履行：监督完整交易生命周期
  • 处理子域：与第三方支付服务提供商集成
  • 钱包和工具：用于存储的支付方式
  • 分类账：记录交易
  • 激励和存储价值：用于积分和优惠券
  • 发行：创建支付工具
  • 结算和对账：确保准确的资金流

这种现代化方法减少了新功能上市时间，提高了代码可重用性和可扩展性，并通过允许团队独立处理特定领域赋予更大的团队自主权。

连接器架构

处理子域对 LPM 集成特别重要。

Airbnb 采用基于连接器和插件的架构来注册新的支付服务提供商（PSP）。

在重新平台期间，团队引入了多步交易（MST）。这个与处理器无关的框架支持跨多个阶段完成的支付流程。

例如，传统卡片支付在单步中发生，你输入卡片详情并接收即时响应。然而，许多本地支付方式需要多个步骤，如重定向到另一个网站、使用单独的应用认证，或扫描二维码。

MST 定义与 PSP 无关的交易语言来描述支付中所需的中间步骤。这些步骤称为操作。常见操作类型包括：

  • 重定向到外部网站或应用
  • 强客户认证摩擦（如安全挑战和指纹识别）
  • 每个 LPM 特有的支付特定流程

当 PSP 指示需要额外用户操作时，其供应商插件将请求规范化为 ActionPayload 并使用 ACTION_REQUIRED 的交易意图状态返回它。这种架构确保跨不同 PSP 和市场一致处理复杂的、多步支付体验。

三种基础支付流程

Airbnb 团队分析了其 20+ LPM 的端到端行为，并确定了三种基础支付流程，捕获用户和系统交互的完整谱系。

1. 重定向流程

在这种模式中，客人被重定向到第三方网站或应用完成支付，然后返回 Airbnb 最终确定预订。示例包括 Naver Pay、GoPay 和 FPX。流程如下：

  1. Airbnb 支付平台向本地支付供应商发送收费请求
  2. 供应商响应包括 redirectUrl
  3. 平台将用户重定向到外部应用或网站
  4. 用户完成支付
  5. 用户被重定向回 Airbnb，带有结果令牌
  6. Airbnb 支付平台使用该令牌安全确认并最终确定支付

2. 异步流程

客人收到提示（如二维码或推送通知）后在外部完成支付。Airbnb 通过网络 webhook 异步接收支付确认。示例包括 PIX、MB Way 和 Blik。流程如下：

  1. Airbnb 支付平台向本地支付供应商发送收费请求
  2. 供应商响应包括二维码数据
  3. 结账页面显示二维码供用户扫描
  4. 用户在钱包应用中完成支付
  5. 支付成功后，供应商向 Airbnb 发送 webhook 通知
  6. 平台更新支付状态并确认订单

3. 直接流程

客人在 Airbnb 界面内直接输入支付凭据，允许像传统卡片支付一样实时处理。示例包括 Carte Bancaires 和 Apple Pay。

配置驱动方法

Airbnb 拥抱由中央基于 YAML 的支付方法配置驱动的 config-driven 方法。

这个文件作为流程、资格规则、输入字段、退款规则和其他关键细节的单一事实来源。团队没有将支付方法逻辑分散在前端代码、后端服务和各种其他系统中，而是将所有相关细节整合在这个配置中。

核心支付服务和前端体验都引用这个单一事实来源。这确保资格检查、UI 渲染和业务规则的一致性。统一方法显著减少整个技术栈的重复、手动更新和错误。

这些配置还驱动后端服务的自动代码生成。使用代码生成工具，系统生成 Java 类、DTO（数据传输对象）、枚举、数据库模式和集成脚手架。结果，集成或更新支付方式主要变成声明式的。你只需进行配置更改，而不是编写大量新代码。这将启动从月简化到周，使持续维护更简单。

支付小部件

支付小部件是嵌入到结账页面的支付方式 UI。它包括可用支付方式列表并处理用户输入。本地支付方式通常需要专门的输入表单，并有独特的国家和货币资格要求。

例如，巴西的 PIX 需要客人的名字、姓氏和 CPF（巴西税务识别号）。Airbnb 没有将表单和规则硬编码到客户端应用中，而是在后端集中化表单字段规范和资格检查。

服务器向客户端发送配置负载，准确定义收集哪些字段、应用哪些验证规则，以及渲染哪些支付选项。这使前端能够动态适应每种支付方式的 UI 和验证。团队可以加速启动并保持用户体验最新，而无需频繁的客户端发布。

测试挑战

测试本地支付方式提出独特挑战。

开发者通常无法访问本地钱包。例如，美国的开发者无法轻松测试需要巴西银行账户的 PIX。然而，由于如此广泛的支付方式和复杂流程，全面测试对防止回归和确保无缝功能至关重要。

为解决这个挑战，Airbnb 增强了其内部支付服务提供商模拟器。

这个工具允许对重定向和异步支付方式进行真实的 PSP 交互模拟。模拟器提供简单的 UI 镜像 PSP 获取页面。测试人员可以明确批准或拒绝交易以获得精确的场景控制。对于异步方法，它返回二维码详情并在收到支付请求时自动调度 webhook 发射任务。这为不同 LPM 提供完整、可靠的测试环境。

可观察性和可靠性

维护高可靠性和可用性对 Airbnb 的全球支付系统至关重要。

随着团队扩展支持许多新的本地支付方式，他们面临越来越复杂的挑战。对外部 PSP 的依赖增加，支付行为差异很大。实时卡片支付和像 Naver Pay 这样的重定向流程遵循完全不同的技术路径。

没有适当的可见性，回归可能在影响真实用户之前不被注意。随着数十个新的 LPM 上线，可观察性成为可靠性的基础。Airbnb 构建了一个集中监控框架，统一所有层的指标，从客户端到 PSP。

启动新的 LPM 时，注册需要单个配置更改。添加方法名称，指标开始自动流式传输。系统跟踪四层：

  1. 客户端指标：显示来自客户端应用的用户级流程健康
  2. 支付后端指标：为支付流程提供 API 级指标
  3. PSP 指标：提供 Airbnb 和 PSP 之间的 API 级可见性
  4. Webhook 指标：跟踪重定向方法或退款的异步完成状态

Airbnb 还使用复合警报和异常检测标准化整个平台层的警报规则。每个警报遵循一致的模式，具有失败计数、失败率和时间窗口阈值。示例警报可能说明：“Naver Pay 恢复失败大于 5 且失败率大于 20% 在 30 分钟内”。这种设计在低流量期间最小化误报。

结果

“像本地人一样支付”计划交付了显著的业务和技术影响。Airbnb 观察到在启动本地支付方式的市场中预订提升和新用户获取。通过可重用流程和配置驱动自动化减少了集成时间。通过增强的可观察性提高早期故障检测可靠性、标准化测试防止回归，以及简化的供应商升级和待命流程以实现全球弹性。

换句话说，支持本地支付方式帮助 Airbnb 在全球旅游业保持竞争力和相关性。这些支付选项改善结账转化、推动采用，并解锁新的增长机会。

参考

本文为学习目的的个人翻译，译文仅供参考。

原文链接：How Airbnb Rolled Out 20+ Local Payment Methods in 360 Days。

版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。