Mobile App Payments: How to Design a Secure Payment Experience
How mobile payments work for physical goods, digital goods and subscriptions: gateways, Apple Pay and Google Pay, in-app purchases, webhooks, verification, failures and secure payment UX.
Quick answer
Mobile app payments follow different rules depending on what you sell. Physical goods and real-world services typically use a payment provider, with cards, Apple Pay and Google Pay, through the provider's SDK so card data stays off your servers. Digital goods and subscriptions consumed in the app generally must use Apple's in-app purchase and Google Play Billing, with region-specific exceptions. In every case, create payments server-side, confirm results through webhooks or store notifications before fulfilling, handle failures and refunds cleanly, and keep the payment UX short and transparent.
Three Kinds of Mobile Payments
| What you sell | Typical payment method | Examples |
|---|---|---|
| Physical goods | Payment provider: cards, Apple Pay, Google Pay | Retail, groceries, marketplace products |
| Real-world services | Payment provider | Rides, bookings, food delivery, appointments |
| Digital goods and subscriptions | Apple in-app purchase and Google Play Billing, with regional exceptions | Premium features, content, virtual items |
Platform Payment Rules
Apple's App Store Review Guidelines require in-app purchase for digital content and features unlocked in the app, and require other payment methods for physical goods and services consumed outside it. Google Play's Payments policy similarly requires Google Play's billing system for digital goods. Both have region-specific exceptions for alternative billing or external purchase links, which have changed in several markets. Check the current guidelines for each market before designing your flow; this is not legal advice.
Mobile Payment Architecture
For physical goods and services, the app requests a payment from your server, which creates it with the payment provider. The provider's SDK collects card or wallet details and handles authentication. The provider notifies your server by webhook, and your server confirms the order. For in-app purchases, the store processes the payment and your server verifies the transaction with Apple or Google.
Cards, Digital Wallets, Apple Pay and Google Pay
Use your provider's mobile SDK or payment sheet so card numbers go straight to the provider. Offer Apple Pay and Google Pay where supported: they're fast, familiar and use device authentication, which reduces friction and card entry errors. Payment providers typically support both through the same integration.
In-App Purchases and Subscriptions
Apple's StoreKit and the Google Play Billing Library handle one-time purchases and subscriptions for digital goods. Verify every transaction on your server with Apple's and Google's server APIs, and subscribe to App Store Server Notifications and Google Play real-time developer notifications to track renewals, grace periods, cancellations and refunds. Always offer a way to restore purchases.
Adding payments to your app?
ZSpace designs payment flows across app, backend and provider, with verification and failure handling built in.
Payment Authorization and Transaction States
| State | Meaning | App behavior |
|---|---|---|
| Created | Payment initiated | Show progress |
| Requires action | Bank authentication needed | Provider SDK shows the challenge |
| Processing | Awaiting confirmation | Show pending status; don't fulfill yet |
| Succeeded | Confirmed by webhook or server check | Confirm order, send receipt |
| Failed | Declined or errored | Explain clearly, allow retry or another method |
| Refunded / disputed | Money returned or contested | Update order and entitlements |
Webhooks and Backend Verification
Never trust the app alone to confirm payment. Verify webhook signatures, confirm status with the provider or store, then update orders and entitlements. Process webhooks idempotently because they can arrive more than once or out of order. The payment gateway integration guide covers the server side in more detail.
Failed Payments, Retries and Refunds
Declines, authentication failures and network errors are routine. Keep the cart or order intact, explain what happened in plain language, and offer a retry or alternative method. Use idempotency keys so retries don't double charge. For subscriptions, use store grace periods and billing retry. Refunds should update orders, entitlements and receipts.
Fraud Prevention Concepts
Rely on your payment provider's fraud screening and 3D Secure where appropriate, add velocity limits on your own endpoints, watch for patterns such as many failed attempts, and use app attestation to reject requests from tampered apps. See mobile app security.
Secure Payment UX
Show the full price, taxes and delivery costs before payment, offer familiar methods first, minimize typing with wallets and autofill, keep users informed during processing, and prevent double taps on the pay button. Present clear receipts and transaction history in the app. See mobile app UX design.
PCI Considerations
If you accept cards, PCI DSS applies to your business in some form. Keeping card data within the provider's SDK or hosted fields, so it never reaches your servers or logs, significantly reduces your compliance scope. Confirm your specific obligations with your payment provider.
Testing Payment Flows
- Successful payment with and without 3D Secure
- Declined cards and insufficient funds
- App closed during processing; order resolves via webhook
- Duplicate webhooks handled once
- Double tap on the pay button doesn't double charge
- Refunds update orders, entitlements and receipts
- In-app purchase, restore and subscription renewal in sandbox
- Subscription grace period, cancellation and refund notifications
Receipts and Transaction History
Send receipts by email or in-app, show order and subscription history, and make it clear how to manage or cancel subscriptions, which the stores handle for in-app purchase subscriptions.
Want your payment flow reviewed before launch?
Talk to ZSpace about testing and hardening your app's payments across providers and app stores.
Conclusion
Secure mobile payments start with using the right system for what you sell, keep card data with the provider, verify every payment on the server, handle failures and refunds cleanly, and present a short, transparent checkout. Confirm platform rules and legal obligations for each market. For the wider build context, see the mobile app development guide.
Common questions
Generally for digital goods and services consumed in the app, such as subscriptions, premium features and virtual items. Physical goods and real-world services typically use other payment methods. Rules have region-specific exceptions and change, so check the current App Store Review Guidelines and Google Play Payments policy.