For years, Airbnb has relied on credit and debit cards as the primary payment methods for guest accommodations. However, operating in over 220 countries worldwide revealed limitations of card-only payments, excluding millions of potential users in regions with low credit card penetration or strong preferences for local payment options.
To address this, the Airbnb Engineering Team launched the “Pay as a Local” initiative aiming to integrate over 20 locally preferred payment methods (LPMs) across multiple markets within 14 months. This article examines the technical architecture and engineering strategies that enabled this global expansion.
Local Payment Methods extend beyond traditional payment cards, encompassing digital wallets such as Naver Pay in South Korea and M-Pesa in Kenya, online bank transfers common across Europe, instant payment systems like PIX in Brazil and UPI in India, and regional schemes including EFTPOS and Cartes Bancaires.
Supporting LPMs offers several benefits: increasing conversion rates by providing familiar options; unlocking markets with minimal credit card usage; and enhancing accessibility for guests without credit cards or conventional banking.
Initial research identified over 300 unique payment methods worldwide. Airbnb narrowed this to a shortlist of just over 20 LPMs for integration by evaluating the top 75 travel markets, selecting one or two payment methods per market, and excluding those lacking a clear travel use case.
Prior to integrating LPMs, Airbnb modernized its payment infrastructure, which was originally monolithic and presented challenges like lengthy feature development cycles, limited team autonomy, and scalability issues.
The Payments LTA (Long-Term Architecture) replatforming initiative transitioned the system to a domain-driven, capability-oriented services architecture. This fragmentation into smaller services by business domain enhanced scalability and development speed.
The modern core payment domain includes subdomains such as:
This modernization reduced time to market, improved code reusability, and empowered teams to work independently within domains.
The Processing subdomain became critical for integrating LPMs by adopting a connector and plugin-based architecture for onboarding new payment service providers (PSPs).
During replatforming, Airbnb introduced Multi-Step Transactions (MST), a processor-agnostic framework that supports multi-stage payment flows. Unlike traditional single-step card payments, many LPMs involve actions such as redirecting to external sites, authenticating with separate apps, or scanning QR codes.
MST defines a PSP-agnostic transaction language with intermediate steps called Actions. These include redirects, strong customer authentication challenges like fingerprinting, and payment method-specific flows.
When a PSP requires additional user action, its plugin normalizes the request into an ActionPayload and sets the transaction status to ACTION_REQUIRED, enabling consistent handling of complex payment experiences across diverse PSPs and markets.
For example, the ActionPayload structure is represented in JSON format.
The modernized platform supports three primary payment flows, addressing unique challenges from different LPM behaviors. Integration required handling app switching, session handoffs, and API variations across charge, refund, and settlement processes.
The redirect flow involves guests being sent to third-party sites or apps to complete payments, then returning to Airbnb to finalize bookings. Examples include Naver Pay, GoPay, and FPX. The process includes:
The async (asynchronous) flow enables guests to complete payments externally after receiving prompts like QR codes or push notifications. Airbnb receives confirmation asynchronously via webhooks. Examples include PIX, MB Way, and Blik. The flow steps are:
The direct flow allows guests to input payment credentials directly within Airbnb’s interface, enabling real-time processing similar to card payments. Examples include Carte Bancaires and Apple Pay.
Airbnb adopted a config-driven integration approach using a central YAML-based Payment Method Config file. This file is the definitive source for flows, eligibility rules, input fields, refund policies, and more.
This centralized config replaces scattered payment logic in frontend and backend systems, ensuring consistency for eligibility checks, UI rendering, and business rules. The unified approach reduces duplication, manual intervention, and errors.
The configuration also supports automated backend code generation, producing Java classes, DTOs, enums, database schemas, and scaffolding for integration. Thus, adding or updating payment methods is largely declarative, shortening feature launches from months to weeks and simplifying ongoing maintenance.
The payment widget embedded in the checkout page displays available payment methods and handles user inputs. Local payment methods often require country- and currency-specific input forms.
For instance, Brazil’s PIX requires first name, last name, and CPF (tax ID). Instead of hardcoding forms and validation, Airbnb centralizes form specifications and eligibility checks in backend systems.
Servers send configuration payloads defining required fields, validations, and payment options for dynamic frontend adaptation. This enables swift launches and updated user experiences without frequent client-side releases.
Testing LPMs is challenging due to limited access to local wallets. For example, developers in the U.S. cannot easily test Brazil’s PIX, which requires local banking access.
To overcome this, Airbnb enhanced its Payment Service Provider Emulator, simulating realistic PSP interactions for redirect and async payment methods. This allows end-to-end testing without depending on unstable or unavailable PSP sandboxes.
The Emulator provides a UI for redirect payments to approve or decline scenarios and automatically schedules webhook tasks for async methods, delivering comprehensive testing across LPMs.
Ensuring global payment system reliability requires robust visibility into increasing complexities from supporting numerous LPMs and external PSPs. Differing payment flows necessitate unified monitoring to prevent unnoticed regressions.
Airbnb developed a centralized observability framework, unifying metrics across clients, backend, PSPs, and webhooks. Adding new LPMs requires only a config change to begin metric streaming automatically.
The system tracks:
Standardized alerting, including composite alerts and anomaly detection, follows consistent failure count and rate thresholds to minimize false positives during low traffic.
Two notable examples showcase the initiative’s impact. Naver Pay, one of South Korea’s fastest-growing digital wallets, boasts over 30.6 million active users as of early 2025, covering approximately 60% of the population. Integrating Naver Pay enhanced the payment experience for local guests and expanded Airbnb’s reach to users favoring this method.
PIX, Brazil’s instant payment system launched by its Central Bank, reached over 76% population usage by late 2024. In 2024 alone, PIX processed transactions totaling approximately 26.4 trillion Brazilian reals (4.6 trillion US dollars), overtaking cash and card payments as the dominant method.
The Pay as a Local initiative brought both business and technical benefits: higher bookings and new user acquisition in markets with LPMs, faster integration via reusable flows and config-driven automation, and improved reliability through enhanced observability, thorough testing, and streamlined global support processes.
Supporting local payment methods remains essential for maintaining competitiveness and relevance in global travel commerce, boosting checkout conversions, adoption, and unlocking growth opportunities.