App Store Revenue Split Between Google and Developers: Money Flow and Payout System

When a user pays for an app, an item inside an app or a subscription through Google's app store, the money does not all go to one party: Google keeps part of it and the rest belongs to the developer who published the app. Explain how the payment is distributed between Google and the app developer, then design the system architecture that carries out that split, from the user's payment to the developer receiving money. Assume the store is Google Play and the purchase uses Google's own billing system unless the interviewer specifies otherwise. ### Clarifying Questions - Which purchase types are in scope: paid app downloads, one-time in-app items, auto-renewing subscriptions, or all three? - Should the design cover only Google's own billing, or also programs where the developer collects payment through its own processor and owes Google a fee afterwards? - Is the system global, with many currencies and per-country tax rules, or limited to one country? - Does the interviewer want more depth on the money flow and fee policy, or on the backend design? ### Part 1 — How the Payment Is Split Walk through what happens to the money from one purchase: which parties are involved, what is deducted before the developer's share is worked out, what decides the size of Google's fee, and how later events change the result. ```hint Follow a single purchase Trace one price through every party that touches it, then ask what changes when the same purchase is refunded or when the developer's yearly earnings keep growing. ``` #### What This Part Should Cover - The parties involved and the order in which money moves between them. - What is removed before the developer's share is computed, and which factors set Google's fee. - How refunds, chargebacks and subscription renewals change the split, and when the developer actually gets paid. ### Part 2 — Design the System Architecture Design the backend that records purchases, computes the split, tracks what each developer is owed, and pays developers. Describe the main components, the data model, the key flows, and how the design stays correct and scales. ```hint Think like an auditor Months from now someone will ask exactly how one purchase was divided and why. Design so that the answer can be reconstructed even if a service crashed midway or a message was delivered twice. ``` #### What This Part Should Cover - The main services and data stores on the purchase, split and payout paths. - How money records stay correct and auditable under retries, failures and later corrections. - How the system scales to heavy purchase volume and to a few extremely popular apps. - How developers see their earnings and receive payouts. ### What a Strong Answer Covers - Fee rules modeled as versioned configuration rather than a hard-coded rate, since rates vary by product type, program, region and date. - Correct money handling: integer minor units, a rounding rule that keeps the parts summing to the whole, currency conversion and tax. - Exactly-once, auditable accounting, with reconciliation against payment processors and banks. - Clear reasoning about which work is synchronous on the checkout path and which is asynchronous, and where strict consistency matters. - Product judgment about what developers need to see in order to trust their earnings. ### Follow-up Questions - A single large purchase pushes a developer's yearly earnings past the threshold where the fee rate changes. How does your system charge it? - A bug applied the wrong fee to two weeks of purchases. How do you correct balances and developer reports? - How would the architecture change for a program in which developers process payments themselves and Google invoices them for a reduced fee?