In-app payment is a purchase completed inside a mobile or desktop app without sending the user to a browser, using either the app store's billing system or a payment SDK embedded by the developer. What is sold decides the rail: digital goods and subscriptions have historically gone through Apple's In-App Purchase or Google Play Billing, which take 30% or 15% commission, while rides, food delivery and other physical services use a payment service provider at ordinary card fees. SDKs send card details straight to the PSP, which returns a single-use token, so card numbers never touch the merchant's servers. Every in-app card payment is card-not-present, so the merchant carries fraud liability unless strong customer authentication through 3DS2 applies.
What is an in app payment, and which rail does it use
The split is set by what is being sold. Digital goods and subscriptions consumed inside an iOS or Android app have historically had to go through Apple's In-App Purchase or Google Play Billing, where the store is the seller of record and takes a commission: 30% as standard, 15% for smaller developers and many subscriptions. Physical goods and real-world services (food delivery, rides, hotel bookings) are outside that rule, so those apps plug in a payment service provider and pay ordinary card processing fees, often below 3%.
The EU Digital Markets Act and several court rulings have loosened the store-billing requirement in some markets, but store rules still decide which rail a given app may use.
How do in app payments work
In store billing, the app calls the platform's purchase API, the store charges the card or carrier account on file, and the developer receives a signed receipt to validate on its server before unlocking content. Payouts arrive from Apple or Google monthly, net of commission.
In SDK-based mobile in app payment processing, the PSP's software development kit collects card details or triggers Apple Pay or Google Pay, sends them straight to the PSP, and returns a single-use token to the app's backend. Card numbers never touch the merchant's servers, which keeps its PCI DSS scope small.
Wallets and stored credentials
A saved card turns repeat purchases into a single tap. Apple Pay and Google Pay pass a device-specific token plus a one-time cryptogram instead of the card number, so a leaked token is useless on another merchant. Apps that store cards themselves usually keep a PSP payment token and charge it later under merchant-initiated transaction rules.
Authentication and fraud in the app
Every in-app card payment is a card-not-present transaction, so the merchant carries the fraud liability unless the payment was authenticated. In the EEA and UK, customer-initiated app payments fall under strong customer authentication; 3DS2 includes a native app SDK so the issuer's challenge renders inside the app instead of a web view. Device fingerprinting, biometric unlock and account age are the main signals app merchants feed into risk scoring.
Example: one purchase, two costs
A €10 in-game currency pack sold through the store nets the developer €7 at a 30% commission or €8.50 at 15%. A €10 food order paid through a card SDK nets roughly €9.75 after a 2.5% blended processing fee. That gap explains why platforms fight hard over which purchases count as digital.