Airbnb's payment logic was welded to stay reservations, so every new product — Experiences, Resolution Center — meant reimplementing payments. This is the rebuild into an idempotent, product-agnostic orchestration platform.

Airbnb’s payments began inside the monolithic Ruby on Rails application, and the logic was tightly coupled to stay reservations — the original product. That coupling was invisible until Airbnb became more than stays. Every new product that needed to move money — Experiences, the Resolution Center — required its own separate implementation of payment functionality, because the existing one only knew how to pay for a stay.

The result was an approach the team describes as lacking scalability and maintainability: payment behavior duplicated per product, each copy carrying its own risk, none of them a shared platform.

The rebuilt system is a service-oriented payment orchestration platform organized around three principles. It is idempotent: built on the Orpheus idempotency framework, each payment is modeled as a workflow — a directed acyclic graph (DAG) of retryable idempotent steps — which Airbnb credits with achieving five 9s (99.999%) of consistency for payments. It is product-agnostic: product fulfillment is decoupled from payment orchestration, so new products can integrate quickly and easily. And it favors data immutability: persistent events and versioning track the complete payment history.

The shift is from “payments, as implemented for stays” to “payments, as a platform any product calls.”

Airbnb did not cut over at once. The migration ran in four major phases: Pricing, where product-specific pricing was remodeled into generic models; Payouts; Bookings, which was itself subdivided into more than 30 milestones; and Data Migration. Sequencing it this way let the generic models come first and the highest-risk surface — bookings — move in small, checkable steps.

The key to surviving a live migration was letting both systems run at once. Throughout most of the process, existing bookings kept proceeding through their lifecycle in the legacy monolithic system, while new work moved to the platform.

The reported gains are qualitative in the source’s own framing: improved performance, maintainability, and extensibility, plus support for future Airbnb products and features — the direct dividend of a product-agnostic platform. The whole justification is that the next product integrates by calling the platform instead of reimplementing payments.

The cost is the machinery that buys it. You accept an idempotency framework, DAG-modeled workflows, persistent event history with versioning, and a transformation layer that has to faithfully read two systems at once for as long as the migration runs. That is a large amount of infrastructure to stand up before the first product benefits — the price of moving money across a live system without stopping it.

A payment platform earns its keep the moment charging is no longer a property of the product being paid for — decouple the two, make every step idempotent, and the next product integrates instead of reimplementing.