Uber during the initial phase had different checkout or payments pipeline based on the business. For example some businesses did not support payment method like apple pay or google. The reason was primarily due to how different services handled different modes of securing funds. While some payment methods required 2FA in countries like India and Brazil. Due to this reason each line of business had to implement logic for their payment methods individually.

Image taken from Uber’s Blog

Unified Checkout

Uber tech team decided to build a checkout layer to allow each line of business access the payments ecosystem via one connection. This new layer acted as an orchestrator which hold the the logic to support payment methods. For example let us say there is a new payment method which is to be launched then it will be added in the new checkout layer and any business that needs to support this payment method could onboard to it.

Why Use a Unified Checkout?

• Abstracts payment complexity → Businesses don’t have to manually handle 2FA, risk checks, or retries.
• Ensures a consistent experience → The same checkout logic works across multiple LOBs.
• Maintains security & compliance → Since LOBs don’t directly handle sensitive payment logic, risk evaluation and compliance measures are centralized.

Architecture

So the architecture looks something like this, whenever a customer places an order the request is sent to the Line Of business backend, let us say you place an order of UberEats. The UberEats service will call the common checkout layer which will further interact with the following services

1. Payments Experience Services
2. Risk Services
3. Payment Processor Services

Payment Experience Services prepares the payment profile for the user which might include steps like validating the eligibility of payment method selected by the customer for the business or country. It also creates the authentication identifiers from the request which are used to generate 2FA url.

Risk Services checks the score of the customer based on customer’s profile for example if the customer is eligible for pre or post order capture of funds. In some cases uber first authorizes the amount to be charged to the customer and later captures the amount. The risk services also checks if the payment method is eligible for upfront charge or once the order is completed.

The last is the payment processor services which interacts with the payment processors such as bank or external payment processors like stripe to capture or authorising the funds.

If the risk system instructs Unified Checkout to initiate an upfront charge, it waits for the payment confirmation signal emitted from the payments platform once we get a response from the third-party processor. This is a necessary complexity, as most processors are asynchronous. Once Unified Checkout consumes this event, it either confirms the order’s preparation or cancels it by emitting another event or calling an LOB service directly.

Uber Checkout gives each businesses 2 option to integrate the checkout into their business

1. Modular
2. Hosted

Modular

The checkout client in modular checkout is a pre-built UI component that handles payment actions on the frontend, so LOBs don’t need to implement payment logic themselves. It works with the checkout backend to process user interactions like 2FA, error handling, and retries while keeping payment complexity hidden from LOBs.

How the Checkout Client Works in Modular Checkout

1. The business backend makes a call to Checkout Backend to process payment.
2. The checkout backend processes the request and may return Checkout Actions (e.g., 2FA, payment retries, risk evaluations).
3. These actions are not visible to the business backend so that the checkout related logic is separated from the business.
4. The checkout client then processes these actions and shows the relevant steps to the user
5. Once the payment process is done the checkout client sends back the response to the checkout backend which confirms payment.

Example Flow (Using Modular Checkout in Uber Rides)

1. User selects the ride and clicks on confirm payment.
2. The rides backend calls the checkout backend to start processing the payment.
3. The checkout backend returns the response to start the checkout actions.
4. These actions are then understood by the checkout client which is a pre-build UI component in the application which prompts the user to complete 2FA.
5. Once the user does these steps the checkout client sends the reuqest to the backend to process the payments
6. The checkout backend finalizes the payment and informs the Rides backend that the payment was successful.

Hosted Unified Checkout (Self-Contained, Out-of-the-Box)

In the hosted component once the user is ready for checkout, the UI of the app is then taken over by the checkout component. On the same screen, the person can select their payment profile and place the order. Once the order is successfully prepared, a signal is sent to the client and to the back end, which will then dismiss the hosted checkout screens on the client side and give control back to the business.

How it works:

Instead of embedding a checkout client inside the application the entire checkout process is handled by the checkout pipeline. When the user is ready to checkout the control is transfered to the checkout implementation. This is most suitable for businesses who do not want to implement their own checkout UI.

Conclusion

Moving the payments related checkout logic away from the businesses helped Uber reduce the complexity of their system and enable supporting new payment methods globally very easily. For instance to enable payment method in multiple businesses they had to previously change the logic in each of the business backend layers. Now with the unified place where the payment methods are launched each business would just need to enable a configuration change and the payment methods would be supported out of the box. For compliance related changes which are very common in payments domain the complexity was abstracted away from the business layers.