Introduction<\/h2>\n\n\n\n
Ride-hailing platforms such as Uber operate as two-sided marketplaces. They match riders who want a trip with drivers who provide it, and they earn revenue by taking a commission on every fare. Every completed ride therefore triggers a flow of money. The rider pays in, the driver is paid out, and the platform retains the difference as its commission. At first glance, this appears trivial. In practice, performing it correctly across billions of transactions, dozens of countries, and a multitude of payment methods and providers is one of the defining challenges of a ULSS.<\/p>\n\n\n\n
The difficulty lies not in a single algorithmic challenge but in the combination of scale, heterogeneity, and an unforgiving correctness requirement. Networks are unreliable, external providers fail or respond twice, and fraudsters actively attack the system. Unlike most application failures, a mistake in this domain creates, destroys, or misdirects real money. A defect rate that would be acceptable in most software becomes a systemic financial risk when multiplied by the transaction volume of a global platform.<\/p>\n\n\n\n
Problem Statement<\/h3>\n\n\n\n
The notion of a ULSS, as characterized by P. Feiler et al. [1]<\/a>, describes systems whose scale in code, data, users, and organizational scope exceeds what classical software engineering assumes. Control is decentralized, requirements are inherently conflicting, the system evolves continuously while it operates, its parts are heterogeneous, and failures are not exceptional events but the normal case [1]<\/a>. A global payment platform exhibits every one of these characteristics. No single party controls the system. Card networks, issuing banks, PSPs, regulators, and the platform itself each control a part of every transaction. Requirements conflict by design, as low checkout latency competes with strong consistency, and aggressive fraud prevention competes with conversion, because every additional verification step loses legitimate customers. The set of payment methods evolves continuously as regional schemes appear. The parts are highly heterogeneous, since every provider exposes different Application Programming Interfaces (APIs), semantics, and settlement timelines. At billions of requests, moreover, network partitions, provider outages, and duplicated messages are everyday events that the architecture must absorb rather than treat as exceptions. The mechanisms presented in this paper (gateway abstraction, tiered consistency, reconciliation, and idempotency) are best understood as answers to precisely these ULSS characteristics.<\/p>\n\n\n\n The goal of this paper is to explain, in an end-to-end manner, how a ride-hailing platform moves money reliably at ULSS scale, and which architectural building blocks are required to do so. Rather than presenting a single component in isolation, we follow a payment through the entire system and use it to motivate each mechanism in turn. Uber serves as the paper\u2019s running case study, and we draw primarily on its publicly documented engineering practices.<\/p>\n\n\n\n Concretely, we aim to answer four questions.<\/p>\n\n\n\n From the marketplace model we can derive a list of requirements that structures the remainder of this paper. A ULSS payment platform must <\/span>(i) support a large and changing set of international and regional payment methods, <\/span>(ii) actively prevent fraud, <\/span>(iii) keep financial records balanced and traceable, <\/span>(iv) coordinate transactions that span many distributed services, <\/span>(v) reconcile its own record of transactions against external providers, and <\/span>(vi) execute each payment exactly once. This paper treats these requirements at the level of application and data architecture. Transport security, workload identity, and the platform\u2019s broader security posture are a separate concern and fall outside this scope, as do detailed cost modeling, individual PSP contract terms, and tax handling. The following sections address these requirements in this order, except that (iv)<\/a> is treated alongside (iii)<\/a> in Section V<\/a>, since coordinating a payment across services and keeping its record correct are two aspects of the same problem. Section IX<\/a> then examines design decisions that a platform at a different scale might reasonably make differently.<\/p>\n\n\n\n Section I<\/a> grounds this paper in the foundational characterization of ULSSes by P. Feiler et al. [1]<\/a>. This section positions the paper against three adjacent bodies of literature that directly inform the architectural requirements of a global payment platform, covering transaction coordination across service boundaries, application-level correctness over unreliable networks, and payment security alongside real-time fraud screening.<\/p>\n\n\n\n Classical database systems relied on centralized transaction managers to enforce Atomicity, Consistency, Isolation, Durability (ACID) guarantees across data operations [2]<\/a>. In distributed microservice architectures, however, maintaining atomic commitment across independent service boundaries introduces severe availability risks. D. Skeen [3]<\/a> demonstrated the fundamental blocking constraints of multi-site commit protocols under network partitions, proving that synchronous atomic commitment compromises system availability during site failures. Bounding atomicity to isolated domain entities was further formalized by P. Helland [4]<\/a> and evaluated for modern microservices by N. Dragoni et al. [5]<\/a>, who argued that ULSSes must abandon cross-service database transactions and instead manage consistency through entity-scoped operations and asynchronous messaging.<\/p>\n\n\n\n To coordinate multi-service workflows without distributed locks, architectures at scale draw on long-running transaction models. H. Garcia-Molina and K. Salem [6]<\/a> introduced the saga pattern, demonstrating that a long-running distributed operation can be decomposed into a sequence of local transactions where each step is paired with a compensating action. This makes saga orchestration an important mechanism for financial workflows in particular, since a payment routinely spans exactly this kind of long-running, multi-service process. External services carry out these compensating actions, while double-entry bookkeeping provides an auditable record of their financial effects. Gulfstream (Section V<\/a>) and LedgerStore (Section VI<\/a>) apply these ideas by restricting zero-sum invariants to individual order entities [7]<\/a> and managing storage writes through intent-then-commit protocols [8]<\/a>.<\/p>\n\n\n\n Executing money movements across distributed components requires handling network partitions, message loss, and duplicated requests. J. H. Saltzer, D. P. Reed, and D. D. Clark [9]<\/a> established the end-to-end argument in system design, showing that critical reliability functions cannot be completely satisfied by underlying network transport layers. Correctness must ultimately be guaranteed at the application endpoints. Modern payment platforms reflect this principle by enforcing exactly-once processing through application-level idempotency keys and structured retry budgets (Section VIII<\/a>) rather than relying on transport acknowledgments.<\/p>\n\n\n\n Theoretical limits on network communication further dictate what a distributed payment architecture can guarantee. E. A. Akkoyunlu, K. Ekanadham, and R. V. Huber [10]<\/a> proved that two parties cannot achieve guaranteed state agreement over an unreliable channel in a finite number of messages. M. J. Fischer, N. A. Lynch, and M. S. Paterson [11]<\/a> extended this result by showing that no deterministic consensus protocol can guarantee both safety and liveness in an asynchronous network if even a single process can experience an unannounced failure. Formalized as the Consistency, Availability, Partition Tolerance (CAP) theorem by S. Gilbert and N. Lynch [12]<\/a>, these constraints require large-scale systems to trade strict global consistency for high availability, settling for eventual consistency instead [13]<\/a>. Payment architectures address these theoretical bounds by employing tiered consistency models in storage (Section VI<\/a>) and relying on asynchronous reconciliation (Section VII<\/a>) as an external safety net.<\/p>\n\n\n\n A third body of literature addresses the domain-specific challenges of payment security protocols and automated fraud detection. In payment security, S. Solat [14]<\/a> evaluated tokenization protocols that isolate sensitive primary account numbers from application backends, reducing regulatory compliance scope under standards such as Payment Card Industry Data Security Standard (PCI DSS) (Section IX<\/a>).<\/p>\n\n\n\n In fraud detection, S. Bhattacharyya et al. [15]<\/a> and A. Dal Pozzolo et al. [16]<\/a> examined machine learning methodologies for transaction streams characterized by extreme class imbalance and continuous concept drift. A. Dal Pozzolo et al. [16]<\/a> identified verification latency as a central challenge, where ground-truth fraud labels mature slowly because chargebacks surface weeks after the original transaction. Uber\u2019s Project RADAR (Section IV<\/a>) addresses verification latency by structuring loss data along dual time dimensions and combining automated rule mining with human-in-the-loop analyst review.<\/p>\n\n\n\n While prior research has explored transaction theory, network reliability, and payment security alongside fraud detection as isolated topics, existing literature does not address how a global platform composes these mechanisms into one unified payment system. This paper provides that synthesis using Uber\u2019s documented engineering practices as a concrete case study.<\/p>\n\n\n\n Requirement (i)<\/a> is to support a large and continuously changing set of international and regional payment methods. The checkout must work globally while presenting each rider with locally relevant options. These include credit cards and digital wallets, deferred-payment schemes, and regional methods such as Single Euro Payments Area (SEPA) direct debit in Europe or Paytm1<\/a><\/sup> in India. Each method has its own semantics and settlement timeline, which is why the platform needs a common checkout interface that hides these differences [17]<\/a>.<\/p>\n\n\n\n Provider selection also affects processing cost. A PSP such as Stripe2<\/a><\/sup> or Adyen3<\/a><\/sup> can offer favorable rates while handling the underlying payment networks. A platform may instead connect directly to a card network or bank when its transaction volume makes the additional engineering and maintenance economical. A global platform can combine both approaches and select a route for each market and payment method.<\/p>\n\n\n\n Uber\u2019s payment platform demonstrates the number of integrations involved. By the end of 2018, it processed 14 million trips per day across 65 countries through 28 PSPs and 5 banks [18]<\/a>. Each integration requires contract negotiations, regulatory review, technical implementation, failure handling, and a gradual market-by-market rollout [17]<\/a>.<\/p>\n\n\n\n The platform-owned payment gateway forms the boundary between the rest of the platform and the provider landscape. It exposes a uniform internal API and routes each request to a PSP, a bank, or an internally operated digital wallet. Provider-specific adapters translate the gateway\u2019s canonical operations and result codes into the protocol and semantics of the destination. Other services depend on the gateway rather than on every individual integration.<\/p>\n\n\n\n The gateway exposes four principal card operations. Authorize validates the card and reserves an amount without moving money, while capture converts an existing authorization into a charge up to the authorized amount. Void releases an authorization, whereas charge combines authorization and capture when no separate hold is needed [17]<\/a>. Calling services use these operations without implementing each provider\u2019s API.<\/p>\n\n\n\n Modern PSPs generally expose Representational State Transfer (REST)-APIs that exchange JavaScript Object Notation (JSON) and process individual transactions in near real time [18]<\/a>. Banks and older payment schemes may provide only batch integrations that exchange files through Secure File Transfer Protocol (SFTP) every few hours or once per day [19]<\/a>.<\/p>\n\n\n\n Consider how this gateway processes a ride paid with a saved credit card. Before the card can be used, the rider adds it and the PSP returns a token representing the stored card details. The Payments Profile Service (PPS) persists this token together with non-sensitive metadata such as the last four digits. Other platform services exchange the profile identifier or token rather than the raw card number. This separation reduces the platform\u2019s exposure to sensitive card data and its compliance scope [14]<\/a>.<\/p>\n\n\n\n Authorization and capture are separated because the final fare is not known when the trip begins. The flow therefore proceeds in three phases, of which Fig. 1<\/a> shows the second and third, in which the request leaves the platform for the provider.<\/p>\n\n\n\n In the first phase, the app sends the ride request and selected payment-profile identifier to the backend. The backend loads the corresponding token and billing context from the PPS and creates a payment attempt for the estimated fare. Before any funds are reserved, the platform-wide risk engine (Section IV<\/a>) may approve the attempt, decline it, or request additional verification. If the attempt is not approved, the app asks the rider to verify the transaction or choose another payment method [17]<\/a>.<\/p>\n\n\n\n During authorization, the backend submits an authorization request for the estimated fare to the payment gateway. The gateway selects a route, and the corresponding adapter translates the canonical request into the chosen PSP\u2019s format. The provider carries the request through the card network to the issuing bank, which either declines it or places a hold on the rider\u2019s funds. On approval, the adapter normalizes the provider\u2019s response, the gateway returns it to the backend, and the ride is confirmed [17]<\/a>.<\/p>\n\n\n\n After the trip, the backend calculates the final fare and submits a capture against the existing authorization through the same gateway route. If the fare is lower than the estimate, only the lower amount is captured. The final fare can also exceed the original estimate, for instance when the trip takes a longer route than the one the estimate was based on, in which case the backend must place a supplementary authorization for the difference before it can capture the full amount. If the ride is canceled, the backend can void the hold instead. Once the PSP accepts the capture and queues it for clearing, the backend can issue the receipt.<\/p>\n\n\n\n The gateway hides provider interfaces but not their different timescales. A capture acknowledgement only means the PSP accepted the instruction, since clearing and settlement between financial institutions follow asynchronously, often overnight. The platform therefore treats the result as provisional until reconciliation (Section VII<\/a>) compares its ledger with the provider\u2019s external record.<\/p>\n\n\n\n Requirement (ii)<\/a> calls for active fraud prevention. Every transaction that reaches the risk engine (Section III.B<\/a>) is screened before any funds are reserved. This section examines the kinds of fraud a ride-hailing platform faces, why that screening cannot be delegated to the payment providers alone, and how Uber extends it from individual transactions to coordinated attacks.<\/p>\n\n\n\n At a volume of millions of transactions per day, fraud is not an edge case but a systemic risk that costs money, time, and reputation. A ride-hailing platform faces several distinct attack patterns. Stolen cards are used to pay for rides, and when the legitimate cardholder disputes the charge, the platform still incurs the PSP\u2019s chargeback fee. Phantom rides are fabricated trips through which a driver collects a payout without providing a service. Coordinated attacks employ many accounts, often fully automated, acting in concert. In an account takeover, an attacker gains control of a legitimate account and abuses its stored payment methods. Promo abuse systematically exploits discounts and referral bonuses through multiple fake accounts. Uber reports encountering all of these patterns across its rides and delivery businesses [20]<\/a>.<\/p>\n\n\n\n PSPs ship their own fraud-prevention tooling, such as Stripe Radar4<\/a><\/sup> or Adyen RevenueProtect5<\/a><\/sup>, which use machine learning to flag suspicious transactions [21]<\/a>. These tools are valuable but insufficient for a platform of Uber\u2019s scale, for three reasons.<\/p>\n\n\n\n The platform, by contrast, directly controls first-party account, device, location, trip or order, and usage histories [23]<\/a>. These platform-specific and provider-level signals are therefore complementary. At Uber\u2019s scale it makes sense to operate a platform-wide risk engine rather than to rely on provider tooling alone.<\/p>\n\n\n\n The platform\u2019s own risk engine evaluates requests before deciding whether they may proceed. Its advantage is access to platform-specific context that is not necessarily transmitted to a PSP. Uber states that its fraud-prevention processes use account, device, location, trip or order, and usage data. The underlying data includes device identifiers, IP addresses, operating-system and mobile-network information, device-motion data, payment information, past trip statistics, and trip details such as time, route endpoints, distance, and order value [23]<\/a>. Uber further describes its automated fraud systems as monitoring location, payment, and usage information in real time and comparing it with historical information to identify suspicious behavior [23]<\/a>. A PSP may receive some of these fields and contribute valuable payment-network signals of its own, but it cannot evaluate platform context that is not included in the integration [22]<\/a>.<\/p>\n\n\n\n Based on these signals the engine chooses one of four responses [24]<\/a>, [25]<\/a>. Approve lets the transaction proceed normally. Step-up requires additional verification, such as a selfie or an Short Message Service (SMS) code, when confidence is moderate. Uber also uses penny drop verification when it suspects that a user does not own the card. It places two small random authorization holds on the card and asks the user to enter the amounts shown in their bank statement, giving a legitimate cardholder a way to prove ownership instead of being declined outright [24]<\/a>. Decline blocks a clear fraud case, and shadow mode logs a hypothetical decision without acting on it, letting engineers validate new models against real traffic before they can affect genuine users. The latter matters because the two error costs are asymmetric. A false negative costs the platform the fare, the chargeback fee, and standing with the card networks, while a false positive costs a paying customer who may not return. Because the risk engine sits in the synchronous authorization path of Section III.B<\/a>, its decision must also fit within a strict latency budget, which is why such systems are typically built around dedicated low-latency feature stores.<\/p>\n\n\n\n Per-transaction scoring reacts to individual events, but large-scale fraud often arrives as coordinated attacks whose individual transactions may each look unremarkable. Uber\u2019s Project RADAR addresses fraud at the level of the attack rather than the transaction [25]<\/a>. RADAR targets two dominant payment-fraud outcomes for the platform. In the first, a completed trip\u2019s payment cannot be collected at all. In the second, a chargeback reverses a payment that was already collected, after the issuing bank sides with a dispute.<\/p>\n\n\n\n RADAR constructs features across these two dimensions by ingesting real-time transaction telemetry from streaming pipelines alongside historical data from analytical stores. Real-time signals capture immediate account and device patterns at order time, while delayed settlement updates refresh historical features as chargebacks mature over weeks [25]<\/a>.<\/p>\n\n\n\n RADAR\u2019s core is a time-series anomaly detector that forecasts expected fraud losses and raises an alarm when observed losses deviate from the forecast by more than normal variation would explain. Fraud data matures slowly, since a chargeback can surface weeks after the trip that caused it, the same verification-latency problem documented more broadly for card transactions [16]<\/a>. RADAR accounts for this by modeling the data along two time dimensions, the order time when the trip happened and the settlement maturity time when the payment outcome became known [25]<\/a>. Once an attack is detected, RADAR mines its transactions for common patterns in the categorical feature space and generates candidate blocking rules. These rules are not deployed automatically. They must meet high precision requirements and are reviewed by human analysts before Uber\u2019s rule engine pushes them to production [25]<\/a>. RADAR is thus deliberately a human-in-the-loop system, in which automation scales the detection while humans bound the consequences of the response.<\/p>\n\n\n\n Fraud prevention decides which transactions may proceed, but it says nothing about whether the transactions that do proceed are recorded correctly. Requirement (iii)<\/a> addresses that correctness directly, beginning with how the books represent a single transaction.<\/p>\n\n\n\n Double-entry bookkeeping most likely emerged in an early Florentine bank [26]<\/a>. Every account has a debit and a credit side, and every transaction touches at least two accounts such that the sum of all debits equals the sum of all credits. Money is therefore never created or destroyed within the books, but only moves between accounts. Entries, once written, are never modified. An error is corrected by an additional, compensating entry. These two properties, the zero-sum invariant and the append-only history, are exactly the guarantees a payment platform requires, which is why modern ledger services restate them as their core design principles [27]<\/a>.<\/p>\n\n\n\n Uber\u2019s Gulfstream, the fifth generation of its collection and disbursement platform, enforces this invariant structurally [7]<\/a>. Gulfstream models a trip as a job with one or more orders, where each order consists of entries, and each entry describes one money movement between two accounts. The entries of an order must sum to zero, so the system cannot create or destroy money by construction. A trip with a fare of $18 and a service fee of $2, for example, forms one order with four entries. These are debits of $18 and $2 against the payer\u2019s escrow account, a credit of $18 to the payee\u2019s escrow account, and a credit of $2 to Uber\u2019s escrow account [7]<\/a>. Note that this example models the platform\u2019s share as a separate service fee, so the payee receives the full fare, whereas a commission model deducts the platform\u2019s share from the fare. Both structures satisfy the zero-sum invariant. Orders are furthermore immutable and are processed only after they have been durably persisted, which turns the bookkeeping rule against editing history into a storage-level guarantee. On this basis Gulfstream operates as a self-reconciling platform that serves around 18 million requests per day across more than 10,000 cities [7]<\/a>.<\/p>\n\n\n\n The zero-sum invariant holds within one order, but confirming a trip touches many independently owned services, namely the payment profile, the risk engine, the collection path that charges the rider, and the disbursement path that pays the driver, each keeping its own state. A single database transaction spanning all of them is unavailable, and distributed transactions that hold locks across service boundaries are exactly what such architectures avoid, since a coordinator failure blocks every participant until it is resolved [3]<\/a>. P. Helland [4]<\/a> argues that systems at this scale should instead bound atomicity to a single owned entity and coordinate between entities by other means.<\/p>\n\n\n\n The saga pattern is that other means, expressing a long-running operation as a sequence of local transactions, each atomic within its own store and paired with a compensating transaction that semantically undoes it if a later step fails [6]<\/a>. A payment service compensates for a card charge by voiding or refunding it, and the ledger records the result with new balancing entries while preserving the originals as part of the audit trail. We interpret Gulfstream\u2019s documented structure through this pattern. A job groups the orders belonging to one trip, each order is a local unit whose entries sum to zero, and the order processor can produce successive orders and payment-result orders [7]<\/a>. Under this interpretation, requirement (iv)<\/a> is answered at two levels, as the saga coordinates actions across services while the ledger records their financial effects. An intent-then-commit protocol, examined in Section VI<\/a>, coordinates the write of a single order inside the store.<\/p>\n\n\n\n What a saga gives up is isolation. Its intermediate states are visible, so a trip can briefly appear collected on one side and unpaid on the other before a later step or its compensation completes. The platform tolerates this because the zero-sum invariant is checked over the settled result, not the intermediate one, and because reconciliation (Section VII<\/a>) independently confirms the final state against the providers. Durability matters correspondingly. Gulfstream persists an order before processing it, separating the record of what must happen from the attempt to carry it out, so a crash between steps destroys neither the instruction nor the entries already written.<\/p>\n\n\n\n The invariant scales from individual entries to aggregates. Over any set of trips, the total pay-in must equal the total pay-out plus the total commission. In accounting terms this is the classical trial balance check, in which the totals of all debit and credit balances must agree and any mismatch reveals an error in the books [28]<\/a>. Table I<\/a> illustrates this for three example rides. The riders pay in 67.00\u20ac, the drivers receive 53.60\u20ac, and the platform retains 13.40\u20ac, so the books balance exactly. Any deviation implies that some party was paid incorrectly or that money appeared from nothing. If trip #2 were recorded with a pay-out of 28.50\u20ac instead of 28.00\u20ac, for example, the totals would disagree by 0.50\u20ac and immediately expose the defective entry. Because the check is a plain summation, it can be evaluated at any granularity, whether per trip, per day, or per market, and thus doubles as an operational monitoring signal, in which a non-zero difference always indicates a genuine defect rather than statistical noise. A balanced ledger can still contain a wrong amount, account, or duplicate transaction, so idempotency and external reconciliation remain necessary. Ledger platforms expose exactly this kind of balance check as a building block, letting teams wire it into an alerting system [29]<\/a>.<\/p>\n\n\n\nGoal<\/h3>\n\n\n\n
\n
Requirements and Structure<\/h3>\n\n\n\n
Related Work<\/h2>\n\n\n\n
Bounded Atomicity and Saga Coordination<\/h3>\n\n\n\n
End-to-End Correctness over Unreliable Networks<\/h3>\n\n\n\n
Payment Security and Multi-Signal Fraud Detection<\/h3>\n\n\n\n
Payment Methods and PSP Integration<\/h2>\n\n\n\n
Payment Gateway and Provider Adapters<\/h3>\n\n\n\n
Processing a Saved-Card Ride<\/h3>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/07\/auth-capture-sequence-1008x1024.png\")
<\/a>Fraud Prevention<\/h2>\n\n\n\n
Threat Landscape<\/h3>\n\n\n\n
Why PSP Tools Are Insufficient<\/h3>\n\n\n\n
\n
A Platform-Wide Risk Engine<\/h3>\n\n\n\n
Project RADAR<\/h3>\n\n\n\n
Double-Entry Bookkeeping<\/h2>\n\n\n\n
Coordinating a Payment across Services<\/h3>\n\n\n\n
Consistency through Aggregation<\/h3>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/07\/ledgerstore-write-path-876x1024.png\")
<\/a>