How Uber Unified Checkouts Across Billion-Dollar Business Lines
Building AI Apps on Postgres? Start with pgai (Sponsored)
pgai is a PostgreSQL extension that brings more AI workflows to PostgreSQL, like embedding creation and model completion. pgai empowers developers with AI superpowers, making it easier to build search and retrieval-augmented generation (RAG) applications. Automates embedding creation with pgai Vectorizer, keeping your embeddings up to date as your data changes—no manual syncing required. Available free on GitHub or fully managed in Timescale Cloud.
Disclaimer: The details in this post have been derived from the Uber Engineering Blog. All credit for the technical details goes to the Uber engineering team. The links to the original articles are present in the references section at the end of the post. We’ve attempted to analyze the details and provide our input about them. If you find any inaccuracies or omissions, please leave a comment, and we will do our best to fix them.
Uber began as a ridesharing company and their back-end systems were built specifically for this purpose. Payment operations were deeply integrated into the ridesharing framework, focusing on the straightforward interaction between riders and drivers.
Over time, however, Uber diversified into various lines of business (LOBs) such as:
Food and grocery delivery (Uber Eats)
Bike and scooter rentals
Public transportation ticketing
Car rentals
Other services aimed at enhancing mobility options
Each new LOB built its back-end system to support its unique business logic. However, this approach created inconsistencies because payment methods and features were not uniformly supported across all LOBs.
For example:
Apple Pay could be used for on-demand rides but not for scheduled rides.
Local payment methods like PIX (Brazil) and UPI (India) were supported in some LOBs but not others.
There was also a duplication of efforts because payment features like two-factor authentication or device fingerprinting, had to be implemented multiple times–once for each LOB.
As expected, managing and maintaining multiple back-end payment systems increased the technical complexity, cost, and risk of errors. Introducing new payment features or compliance requirements (for example, regulatory mandates like Strong Customer Authentication in the EU) required redundant implementations across the fragmented systems, slowing Uber’s ability to adapt and innovate.
The need for a unified, scalable solution to address these challenges became critical, paving the way for the development of the Unified Checkout system. In this article, we’ll look at how Uber developed this system and its architecture.
If It’s Slow, It’s Broken 🐢 (Sponsored)
To your users, slow and buggy are the same thing. 🐛 And Sentry helps you find bugs fast, even the ones that aren’t obvious.
Cut chunks of time off of bad API calls
Eliminate extremely costly, unnecessarily frequent, or slow DB operations
Uncover the source of a traffic spike spike in minutes
Whether it’s an error or a slowdown, Sentry helps you fix issues fast and keep your app running smoothly. Because if it’s slow, it’s broken.
Unified Checkout Solution By Uber
The Unified Checkout system acts as a single, centralized layer for managing payments across all Uber services.
Think of Unified Checkout as a one-stop shop for all payment-related activities at Uber. Instead of each service (like Uber Eats or ridesharing) building its payment system, they now plug into a single, centralized system.
See the diagram below that shows a comparison of the system landscape with and without Unified Checkout:
Some key features of the Unified Checkout system are as follows:
Centralization: Instead of each LOB (ridesharing, Uber Eats, bike rentals, etc.) managing its payment system, all LOBs now connect to a single platform.
Elimination of Redundancy: Any new payment feature or compliance requirement is implemented only once, making the process more efficient.
Consistent Payment Support: Payment methods like Apple Pay, Google Pay, and local payment methods (PIX, UPI) are uniformly supported across all Uber services.
Design Philosophy
Uber approached the Unified Checkout platform with a clear set of guiding principles:
Treat LOBs As External Entities: The system is designed to interact with each LOB as an independent client, with minimal assumptions about its internal operations. This decoupling ensures that changes in one LOB (for example, Uber Eats adding new delivery features) do not affect the payment system.
Decoupling Payment Logic from Product Systems: The Unified Checkout layer handles all payment-related operations (such as authentication, risk scoring, and transaction processing). Product teams for specific LOBs don’t need to understand or manage the complexities of payment systems, reducing their development workload.
Generic System: The platform supports a wide range of payment methods (both global and local) and operations like two-factor authentication (2FA), device fingerprinting, and error recovery. If a new payment method like PIX (Brazil) needs to be added, it’s implemented once in Unified Checkout, and all LOBs benefit.
Scalable: The system is designed to handle Uber’s massive global traffic and adapt to new payment methods or regulatory requirements without major changes.
Architecture of Unified Checkout System
Let’s now look at the architecture of the Unified Checkout system. We will look at the core components and how they are deployed.
Core Components
The architecture of the Unified Checkout system revolves around several interconnected components, each serving a specific purpose in the payment process.
The diagram below shows the architecture on a high level.
Let’s look at various components in detail.
1 - Payment Profile Preparation
This component gathers and processes transactional data from the user.
It integrates with third-party systems like banks and payment gateways. For example, if a user chooses to pay via Apple Pay, this component securely exchanges short-lived tokens with Apple’s systems to authenticate the transaction.
2 - Risk Evaluation and Securing Funds
Uber’s risk system evaluates the payment request for potential fraud or other risks.
Depending on the evaluation, the system may temporarily lock the required amount in the user’s account (used when payment is finalized after the service, like a ride). Based on the strategy, it can also charge the full amount before the service begins.
3 - Checkout Actions
This is a stateless framework that handles essential tasks to ensure smooth transactions.
It includes multiple tasks such as:
Verifying the user’s identity.
Ensuring the account belongs to the user.
Providing corrective actions like retrying payments or selecting a new payment method.
These actions are designed to be generic and reusable across all Uber LOBs, making the system versatile and efficient.
4 - Event Handling
Many payment systems work asynchronously, meaning the payment processor may not provide immediate confirmation.
This component listens for payment confirmation signals from third-party systems and decides the next step.
If payment is successful, it confirms the order and notifies the LOB.
If payment fails, it cancels the transaction and prompts corrective actions.
Deployment Models
The Unified Checkout system supports two deployment models, catering to the varied needs of Uber’s LOBs.
1 - Modular Deployments
The modular version allows LOBs to integrate pre-built components of the Unified Checkout system directly into their apps and workflows.
Here’s how it works:
LOB-specific back-end systems communicate directly with the checkout back end.
Checkout Actions such as 2FA or error messages are surfaced in the LOB’s user interface through responses from the checkout system.
The payload remains opaque to the LOB, meaning it cannot interpret or modify the payment details, ensuring security and decoupling complexity.
See the screenshot below that shows this feature:
The main benefit of this approach is the flexibility of LOB-specific integration while simplifying payment operations.
2 - Hosted Deployment
This is an out-of-the-box solution for smaller LOBs or new verticals, providing a complete payments and checkout system.
Here’s how it works:
The hosted checkout system takes over the app interface when a user initiates payment.
It displays a summary of the order, allows users to select their payment method, and processes the transaction.
Once the payment is complete, control is handed back to the LOB.
See the screenshot below that shows a hosted checkout summary view:
This solution accelerates time-to-market for smaller teams or experimental services while ensuring full feature parity with Uber’s top payment methods.
Checkout Actions Framework
The Checkout Actions framework is a key feature of the Unified Checkout system
It handles the necessary steps to complete a transaction and resolve any issues during the process. It’s a stateless framework, meaning it doesn’t store user-specific information between actions, ensuring efficiency and scalability.
See the diagram below that shows a sequence diagram for checkout actions:
The key features of the framework are as follows:
Generic and Modular: It is designed to work across all Uber Lines of Business (LOBs). Actions are flexible and reusable, making them adaptable for various payment scenarios.
Action Types: Includes tasks like:
Two-Factor Authentication (2FA): Verifying the user’s identity.
Error Recovery: Guiding users through corrective steps if something goes wrong.
Identity Challenges: Ensuring the user is the rightful account holder.
Data Collection: Gathering necessary details for payment processing.
Stateless Operation: The framework doesn’t rely on previous states, making it easier to process actions independently and across systems.
Pre-Checkout Actions
Pre-checkout actions are steps completed before the checkout request interacts with the Unified Checkout back end. These actions ensure all the necessary information is gathered before the transaction is initiated, minimizing delays or errors later in the process.
The pre-checkout actions are deterministic, meaning they’re known in advance and must always occur for certain transactions. By handling them upfront, the system reduces the complexity of subsequent operations.
Some examples of pre-checkout actions are as follows:
Selecting a Payment Method: For Apple Pay, the user must select a payment method in their Apple Wallet before proceeding.
Device Fingerprinting: Captures details about the user’s device to evaluate transaction risks.
Token Generation: Generates a short-lived token for secure communication with third-party payment processors.
See the screenshot below that shows pre-checkout actions:
Post-Checkout Actions
Post-checkout actions occur after the checkout request has been sent to the back end.
These actions handle the unpredictable nature of payment processing where external systems might reject or delay a transaction. By offering corrective actions, the system ensures a high recovery rate and reduces user drop-offs.
They are often conditional, triggered by the results of payment processing or risk evaluation. Some examples of post-checkout actions are as follows:
Payment Authorization: Verifies that funds are available and the payment method is valid. It might involve waiting for confirmation from external systems like banks.
Error Handling: If something goes wrong (for example, insufficient funds, expired card), the system provides recovery options such as:
Reauthenticating the user’s account.
Updating payment method details.
Choosing a different payment method.
Identity Challenges: For high-risk transactions, users may need to complete additional verification steps like entering a one-time password or confirming their identity via biometric data.
Corrective Flows: These flows are designed to help users resolve issues efficiently. For example, if a payment is declined due to a low balance, users can switch to another payment method directly from the app.
See the screenshot below that shows a few post-checkout actions:
Understanding Through an Example
Imagine using Uber Eats and trying to pay with a credit card. Here’s a list of possible pre-checkout and post-checkout actions that might be involved:
Pre-Checkout Actions: The user selects a saved credit card as the payment method. The system fingerprints the device to ensure it matches previous transactions.
Transaction Submission: The checkout request is sent to the payment processor.
Post-Checkout Actions: If the card has insufficient funds, the system prompts the user to choose a different card. If the new card works, the transaction is completed successfully.
Conclusion
The Unified Checkout system directly enhanced key business metrics such as:
Checkout Conversion Rate: Unified Checkout improved checkout conversion rates by 3%. The conversion rate measures how many users complete a transaction successfully. A higher rate indicates fewer errors and an improved user experience.
Session Recovery Rate: A 4.5% higher session recovery rate was observed after the use of the unified checkout system. This metric reflects the ability of users to recover from errors (for example, payment failures or declined cards) and complete their transactions successfully. The increase means users faced fewer abandoned sessions.
Financial Impact: These performance improvements translated into an incremental gross booking increase estimated in the hundreds of millions of dollars annually. At Uber’s scale, even small percentage gains in conversion or recovery rates generate significant financial returns.
Global Payment Support: All major global and popular local payment methods (e.g., Google Pay, PIX in Brazil, UPI in India) are integrated seamlessly.
The architecture and implementation of the Unified Checkout system show how common, duplicated operations can be evolved into scalable platforms. Uber tackled technical debt accumulated during its rapid growth by creating a generic system that works across all Lines of Business (LOBs).
However, the Unified Checkout platform is not a static solution.
Uber continues experimenting with new features, error recovery models, and payment methods to optimize the system further. This proactive approach ensures that the platform remains relevant and effective in the face of changing market demands.
References:
Very insightful