In-app payments
What are in-app payments?
In-app payments are transactions made directly inside a mobile application on a smartphone or tablet. The customer buys products, services, or digital content without leaving the app or being redirected to a browser page.
The payment interface lives inside the app, built with a software development kit (SDK) from a payment provider or an embedded . Card details come from a token saved during an earlier purchase or from a mobile wallet such as Apple Pay, Google Pay, or Samsung Pay, so the customer confirms with a fingerprint or face scan instead of typing a card number. In-app payments are often called mobile payments, though that broader label also covers browser checkouts on a phone and in-store taps over .
Key facts
- Also known as: mobile payments; in-app purchases, when the app store itself handles the billing
- Applies to: native iOS and Android apps
- Built with: a payment SDK, or a payment form rendered inside the app
- Payment methods used: stored card tokens, , entry, , carrier billing
- Authentication: (fingerprint, facial recognition, voice), device passcode, and 3-D Secure where applies
- Common use cases: subscriptions, digital content, in-game currency, food delivery, ride-hailing
How in-app payments work
- Checkout starts in the app. The customer taps to buy, and the app calls the payment SDK, which renders a native payment sheet instead of opening a browser.
- A credential is selected. The customer picks a saved card token, a digital wallet, or another method. When a token already exists, nothing is typed.
- The customer authenticates. A fingerprint, face scan, or device passcode unlocks the credential. The provider collects the and other signals at the same time for risk scoring.
- The token becomes an authorization request. keeps the raw card number out of the app. The wallet returns a network token and a one-time cryptogram, which the provider passes to the card network.
- Authorization runs. The routes the request through the and the card network to the , which approves or declines it.
- The app confirms the result. The response returns to the app, which unlocks the purchase on the same screen the customer started on.
Why it matters
- Typing a card number, expiry date, and CVV on a phone keyboard takes far more taps than confirming a wallet sheet with a fingerprint, and every extra field is a place the checkout can be abandoned.
- Wallet credentials arrive with a cryptogram and issuer-side verification already attached, which gives the issuing bank a stronger authentication signal than a manually keyed card.
- A saved token lets the same app charge again later, which is what makes and possible without asking for card details a second time.
- Raw card data never reaches the app's own code, so PCI DSS scope sits with the payment provider rather than with the app developer.
Common issues
- App-store billing rules. Apple and Google require their own in-app purchase billing for digital goods and subscriptions consumed inside the app, and charge a commission on them. Physical goods and services delivered outside the app can use a third-party provider. The EU's Digital Markets Act has forced both stores to permit external payment links for apps distributed in the EU, so the applicable rule depends on the store, the product type, and the market.
- Wallet coverage isn't universal. Apple Pay and Google Pay availability depends on the customer's country, bank, and card scheme, so an app offering wallets alone loses every customer whose bank hasn't enabled them. A card form fallback covers that gap.
- Renewals run without the app open. Subscription charges fire against the stored token with no biometric prompt, so an expired card or a revoked token fails quietly until the customer opens the app again.
- Decline reasons are hidden by the native sheet. The wallet interface shows a generic failure, so the actual issuer response code has to be read from the provider's API response or dashboard.
