Uber began its journey as a ridesharing platform with a straightforward yet ambitious goal: to make transportation as dependable as running water, accessible to everyone, everywhere.

Initially, Uber’s backend systems were tailored around a singular line of business (LOB) focused on ridesharing. Consequently, payment-related operations were integrated directly into the ridesharing system. For instance, the implementation of Apple Pay® was embedded within the rides backend.

As Uber expanded its services to include food and grocery delivery, bike and scooter rentals, public transportation ticketing, and car rentals, the complexity of its backend systems increased significantly. Each new LOB developed its own backend infrastructure to accommodate specific business logic. However, they all required payment processing and risk management support, necessitating operations such as two-factor authentication (2FA) and device fingerprinting. This fragmented approach to implementing payment business logic became costly and inefficient, as any necessary changes had to be replicated across multiple services. This not only hindered operational velocity and feature consistency but also increased complexity, costs, and risks associated with service maintenance.

Moreover, payment methods were not uniformly accessible across various user flows and LOBs. For example, while users could utilize Apple Pay for on-demand rides, it was not available for scheduled rides until recently. Similarly, other payment options like Google Pay™ and direct bank transfers faced similar limitations due to differing service models handling scheduling rides and securing funds prior to fulfillment. This inconsistency was particularly problematic for popular payment methods in regions such as Brazil’s PIX and India’s UPI.

After years of managing individual payment implementations for each LOB, the need for a more efficient solution became apparent—especially with the upcoming compliance requirements that demanded repeated changes across backend services. The catalyst for this initiative was the introduction of Strong Customer Authentication (SCA), a mandate originally established in the European Union. SCA requires that any transaction exceeding a certain threshold involving a European credit card undergo a multi-factor authentication process using 3-D Secure to verify the user’s identity. This protocol includes measures such as device fingerprinting and may involve challenges like biometric verification or one-time passwords.

Uber identified around 70 endpoints that could trigger financial transactions, all of which were directly integrated with risk and payment systems. This article outlines how Uber implemented these authentication methods while navigating the complexities involved.

Unified Checkout

To address these challenges, Uber developed a checkout layer that provides all LOBs access to its payment ecosystem through a single connection. This new layer serves as an orchestrator for checkout business logic.

All business logic related to supporting various payment methods has been centralized within this layer. If Unified Checkout supports a particular payment method, enabling it across any LOB or user flow requires only minor configuration changes.

New payment methods are exclusively supported within Unified Checkout, which acts as a driving force for adoption throughout the organization while delivering value to existing customers. The strategy behind Unified Checkout was to treat each Uber LOB as an independent entity with limited knowledge of internal operations—similar to existing checkout solutions in the market. By decoupling the system from individual LOB product layers, Uber can ensure that the platform remains agnostic to their internal workings while focusing solely on payment method specifics. This approach facilitates faster platform evolution and encourages teams to model operations generically while allowing users to pay using their preferred methods across all Uber services.

Architecture

Unified Checkout is available in both modular and hosted versions featuring client components integrated with the checkout backend service.

It offers comprehensive support for both global and local payment instruments along with risk system integration on both client and backend sides for risk assessment. Additionally, it executes various workflows through a generic framework known as Checkout Actions.

A streamlined set of microservices manages checkout requests and performs several key operations:

• Prepares the payment profile by exchanging transactional data captured on the client side with external payment systems.
• Engages with the risk system to evaluate requests and secure funds based on user-selected payment profiles—either by placing an authorization hold or charging upfront before order fulfillment.
• Generates Checkout Actions that guide users through necessary steps or display failure messages alongside corrective action buttons.

In cases where an upfront charge is initiated by the risk system, Unified Checkout awaits confirmation signals from the payments platform after receiving responses from third-party processors. This asynchronous nature necessitates additional complexity; once Unified Checkout receives confirmation or cancellation signals from processors or LOB services, it can finalize or abort order preparations accordingly.

Modular vs. Hosted Solutions

In its modular version, clients can integrate pre-built components into their own screens throughout the checkout journey.

This integration model allows LOB backends to communicate directly with the checkout backend. Any Checkout Actions needed externally are conveyed through opaque responses passed back to client components. This design choice prevents complexities related to payments from infiltrating LOB services while ensuring that only relevant teams manage them.

Conversely, the hosted solution provides smaller LOBs or new verticals with an out-of-the-box payments and checkout experience. This accelerates their time-to-market while maintaining consistent support for various payment methods.

Once a user is ready to check out in this model, the hosted solution takes control of the application interface to display an order summary alongside options for selecting a payment profile. After successfully preparing the order, signals are sent back to both client and backend systems to relinquish control back to the respective LOB.

Checkout Actions Framework

Checkout Actions represents a stateless framework designed to execute various flows necessary for successful transactions. These actions may involve 2FA operations, identity challenges, authorizations for payments, device fingerprinting, among others—all crafted generically enough for application across all LOBs.

The client side executes these actions and generates result payloads sent back during subsequent checkout requests—either succeeding or prompting further actions needed from users.

Pre-checkout Actions

Pre-checkout actions must be executed on the client side before initiating any backend interactions during checkout requests. These actions are typically deterministic operations generated by backend systems in real time since their execution is predetermined—for example, selecting a payment method in Apple Wallet® during checkout.

Post-checkout Actions

Post-checkout actions are generated after initial interactions with the checkout backend. These may include authorizing payments or handling rejections due to insufficient balance or errors during authorization holds. Each action generated offers corrective measures—such as allowing users to select alternate payment profiles or confirming identities through additional verification processes.

Impact Analysis

Each launch of Unified Checkout undergoes rigorous experimentation aimed at assessing its impact on key metrics such as conversion rates during checkout requests and overall session recovery rates. Following the introduction of frequently used global payment methods on Uber Eats, a holdout experiment revealed that users routed through Unified Checkout experienced a 3% higher conversion rate compared to those using legacy systems—alongside a 4.5% improvement in session recovery rates.

Although this experiment targeted only one LOB initially, extrapolated results indicated significant potential impacts on gross bookings across all traffic channels—estimated in hundreds of millions of dollars annually.

Beyond metric improvements, every user flow now supports at least five of the most popular global payment methods. Major LOBs also accommodate prevalent local options—transforming previous limitations into strategic decisions rather than technical constraints or cost barriers related to implementation complexity.

Conclusion

By adopting a strategy that treats Uber’s LOBs as external customers, the Checkout Platform team continually experiments with new features aimed at enhancing conversion metrics while minimizing drop-off rates. Initiatives include developing new types of Checkout Actions, refining error messaging frameworks for greater granularity in communication, optimizing existing processes, exploring new modalities for memberships and scheduled orders, split tender options, among others.

In software development contexts marked by rapid growth phases—where common operations require transformation into more generic platforms—addressing technical debt becomes essential for sustainable scalability.

At Uber’s scale, implementing a unified system capable of managing order placement traffic across mobile and web applications enables simultaneous enhancements in user experiences through singular changes or deployments—ultimately influencing critical business indicators like gross bookings positively.

Software engineers play a pivotal role in identifying such opportunities while designing solutions that benefit both users and organizational objectives—even if it necessitates initiating projects from grassroots levels until they evolve into fully-fledged products.

Read more such articles from our Newsletter here.