airbnb·Jan 12, 2026·3 min readCurated summary

Pay As a Local

Airbnb launched more than 20 locally preferred payment methods across global markets in just over 14 months. The initiative aimed to improve checkout conversion, reach customers with limited access to cards, and provide familiar payment options. Airbnb achieved this by combining a replatformed, domain-oriented payments architecture with reusable PSP connectors and standardized payment-flow patterns. ## Why Local Payment Methods Matter - Local payment methods (LPMs) include: - Digital wallets such as M-Pesa and MTN MoMo - Online bank transfers - Real-time payment systems such as PIX and UPI - Regional payment schemes such as EFTPOS and Cartes Bancaires - They help Airbnb: - Increase conversion by offering trusted local options - Enter markets where card usage is limited - Serve customers without credit cards or traditional banking access - Airbnb identified more than 300 payment options worldwide. - For the initial rollout, it evaluated the top 75 travel markets and selected one or two methods per market, producing a shortlist of just over 20 integrations. ## Payments Platform Modernization - Airbnb separated payment capabilities from its core stays, experiences, and services businesses. - Its Payments LTA modernization replaced a monolith with domain-oriented services. - Core payment subdomains include: - Pay-in and payout - Transaction fulfillment and processing - Wallets and payment instruments - Ledger - Incentives and stored value - Issuing - Settlement and reconciliation - This structure improved reuse, extensibility, time to market, and team autonomy. ## Connector Architecture and Multi-Step Transactions - The processing domain uses connector and plugin-based integrations for payment service providers (PSPs). - Plugins support: - API- and file-based integrations - Payment routing and switching - Market-specific PSP behavior - Airbnb also introduced Multi-Step Transactions (MST), a PSP-agnostic framework for payments requiring multiple stages. - MST represents intermediate operations as Actions, including: - Redirects to external apps or websites - Strong customer authentication challenges - Payment-method-specific interactions - PSP plugins normalize these requirements into an `ActionPayload` and return an `ACTION_REQUIRED` transaction status. ## Three Standardized LPM Flow Types Airbnb analyzed its payment methods and grouped them into three reusable archetypes: - **Redirect flow:** The guest is sent to an external site or app, then returned to Airbnb. Examples include Naver Pay, GoPay, and FPX. - **Async flow:** The guest completes payment later through a QR code, push notification, or wallet app, while Airbnb receives confirmation through a webhook. Examples include Pix, MB Way, and Blik. - **Direct flow:** Payment credentials are entered within Airbnb and processed immediately, similar to card payments. Examples include Cartes Bancaires and Apple Pay. This classification reduced duplicate engineering work and made new integrations more predictable. ## Orchestrating External Payment Actions - For redirect payments: - Airbnb sends a charge request to the local vendor. - The vendor returns a `redirectUrl`. - The guest completes payment externally. - Airbnb receives a result token and uses it to confirm the transaction securely. - For asynchronous payments: - Airbnb sends a charge request and receives `qrCodeData`. - The checkout displays the QR code. - The guest pays in an external wallet. - The vendor sends a webhook, allowing Airbnb to mark the payment successful and confirm the order. - These flows required careful handling of app switching, session handoff, delayed confirmation, and synchronization between Airbnb and external providers. ## Outcome Airbnb’s rollout demonstrates that broad local-payment coverage depends less on building every integration independently and more on creating reusable abstractions. A modular payments platform, standardized flow archetypes, normalized PSP actions, and plugin-based connectors enabled the company to support diverse regional payment behaviors at global scale.

Read original(opens in new tab)

Domain Driven DesignMicroservicesApi IntegrationSoftware Architecture+3

line·Jul 28, 2025Original article

Introducing a case of utilizing DDD in (opens in new tab)

LY Corporation’s ABC Studio developed a specialized retail Merchant system by leveraging Domain-Driven Design (DDD) to overcome the functional limitations of a legacy food-delivery infrastructure. The project demonstrates that the primary value of DDD lies not just in technical implementation, but in aligning organizational structures and team responsibilities with domain boundaries. By focusing on the roles and responsibilities of the system rather than just the code, the team created a scalable platform capable of supporting diverse consumer interfaces. ### Redefining the Retail Domain * The legacy system treated retail items like restaurant entries, creating friction for specialized retail services; the new system was built to be a standalone platform. * The team narrowed the domain focus to five core areas: Shop, Item, Category, Inventory, and Order. * Sales-specific logic, such as coupons and promotions, was delegated to external "Consumer Platforms," allowing the Merchant system to serve as a high-performance information provider. ### Clean Architecture and Modular Composition * The system utilizes Clean Architecture to ensure domain entities remain independent of external frameworks, which also provided a manageable learning curve for new team members. * Services are split into two distinct modules: "API" modules for receiving external requests and "Engine" modules for processing business logic. * Communication between these modules is handled asynchronously via gRPC and Apache Kafka, using the Decaton library to increase throughput while maintaining a low partition count. * The architecture prioritizes eventual consistency, allowing for high responsiveness and scalability across the platform. ### Global Collaboration and Conway’s Law * Development was split between teams in Korea (Core Domain) and Japan (System Integration and BFF), requiring a shared understanding of domain boundaries. * Architectural Decision Records (ADR) were implemented to document critical decisions and prevent "knowledge drift" during long-term collaboration. * The organizational structure was intentionally designed to mirror the system architecture, with specific teams (Core, Link, BFF, and Merchant Link) assigned to distinct domain layers. * This alignment, reflecting Conway’s Law, ensures that changes to external consumer platforms have minimal impact on the stable core domain logic. Successful DDD adoption requires moving beyond technical patterns like hexagonal architecture and focusing on establishing a shared understanding of roles across the organization. By structuring teams to match domain boundaries, companies can build resilient systems where the core business logic remains protected even as the external service ecosystem evolves.

Domain Driven DesignApache KafkaSoftware DesignGrpc+4