Watch someone buy something on their phone with a card. They find their wallet, read sixteen digits, mistype one, retry, hunt for the CVV, then fail an authentication step because the SMS went to a phone they are already using.
Now watch the same purchase with a wallet. Double-click, thumb, done.
That difference is why payment integration is a conversion project rather than a plumbing one.
The first decision is not technical
Before any integration work, establish what you are selling — because for iOS and Android apps this determines whether you have a choice at all.
Digital goods consumed in the app — subscriptions, premium features, in-game currency — must generally use the platform's own in-app purchase system, at platform commission rates. There has been regulatory movement here and some jurisdictions now permit alternatives, but the default remains platform billing and the rules differ by market.
Physical goods and real-world services — retail, food delivery, ride-hailing, ticketing — use ordinary payment processing at ordinary card rates. You keep control and pay a fraction of the platform rate.
Getting this wrong is not a technical bug. It is an app rejection, and repeated attempts to work around it put the listing at risk. If your product sits near the boundary, read the current guidelines rather than relying on what a competitor appears to do.
What wallets actually change
Apple Pay and Google Pay are not payment processors. They are a faster way for a customer to hand over card details that already exist on the device, tokenised so the raw card number never reaches you.
Two consequences follow. First, you still need a processor behind them — the wallet supplies the credential, the processor moves the money. Second, and more usefully, tokenisation means you are not handling card data directly, which dramatically narrows your compliance exposure.
The conversion effect is the reason to bother. Removing manual card entry removes the step where mobile checkouts are abandoned, and the improvement is largest exactly where it hurts most — first-time buyers on a small screen with no saved card.
Fig. — The card number never touches your code. That is most of the compliance win.
Choosing a processor
Rates matter less than teams expect at low volume and a great deal at high volume, and the headline percentage is rarely the whole cost.
Ask about the additions: currency conversion margin, chargeback fees, payout timing, refund handling, and whether the advertised rate applies to the card mix you actually see. A business selling to consumers on premium cards pays materially more than the headline.
Ask about local methods. Card coverage is not the whole market in most countries — UPI in India, iDEAL in the Netherlands, various bank-transfer and wallet schemes elsewhere. A processor without the dominant local method in your market is losing you customers who simply cannot pay conveniently.
And check the SDK quality, because you will live in it. Native support for both platforms, a working test environment, sensible error taxonomies, and documentation that covers failure cases rather than only the happy path.
The compliance you cannot skip
PCI DSS applies the moment card data touches your systems. The correct strategy is to ensure it never does — use the processor's SDK so the card details go from the device to the processor without passing through your servers. That reduces your obligation to the lightest tier, and it is the single most valuable architectural decision in a payments project.
Strong customer authentication applies in Europe and increasingly elsewhere. Certain transactions need a second factor, handled through 3-D Secure, which means your checkout must gracefully handle being interrupted mid-payment and resumed. Test this deliberately — it is the most common source of "payment sometimes fails" reports.
Tax is genuinely complicated for digital services sold across borders and is not a thing to work out afterwards. It changes pricing display, invoicing, and in some cases whether you can sell in a market at all.
Subscriptions are their own problem
Recurring billing looks like a variation on one-off payments and behaves nothing like it.
Cards expire, get replaced after fraud, and get declined for reasons that resolve themselves in a day. A meaningful share of subscription churn is involuntary — customers who wanted to keep paying and whose payment failed quietly. Handling that well is called dunning, and it is mostly unglamorous logic: retry on a sensible schedule, notify the customer through a channel they actually read, and hold the account in a grace state rather than cancelling immediately.
Card updater services, offered by most processors, refresh stored credentials when a bank reissues a card. They cost a little and recover more than they cost.
The other half is state. A subscription can be trialling, active, past due, paused, cancelled-but-active-until-period-end, or expired, and your app has to render the right thing for each. Teams that model this as a boolean discover the gap when a customer who cancelled last week loses access three weeks early and complains publicly.
And if you are on platform billing for digital goods, entitlement lives with the platform rather than your server, which means reconciling their receipt data with your own records. That reconciliation is a permanent job, not a launch task.
Where implementations go wrong
Treating payment as a screen rather than a state machine. A payment can be pending, authorised, captured, failed, disputed, or refunded, and the app can be killed at any point in that sequence. Design around the states, not around the button.
No idempotency. A user taps twice on a slow connection, or the app retries after a timeout, and they are charged twice. Idempotency keys on every payment request are not optional.
Trusting the client. The amount, the currency, and the item must be determined server-side from the cart, never accepted from the app. This is the most damaging and most common mistake in the category.
Ignoring failure copy. "Payment failed" tells a customer nothing and loses the sale. "Your bank declined this — try another card or contact them" recovers a meaningful share of them.
Skipping receipts and history. Customers expect to see what they paid and when. Its absence generates support tickets forever.
No refund path in the product. If issuing a refund requires someone logging into the processor dashboard, refunds will be slow and inconsistently recorded. Build it into your own admin tooling, with the reason captured, or your support team will develop a workaround you cannot audit.
A sane order of work
Start with cards through a single processor, server-side amount determination, idempotency, and a properly modelled payment state machine. Get that correct and boring.
Add wallets next — they are a modest amount of work on top of an existing integration and deliver the largest conversion improvement available.
Add local methods once you know where your customers actually are, guided by where checkouts are being abandoned rather than by a map.
Test with real cards in the real world before launch, not only in the sandbox. Sandboxes model the happy path and a handful of scripted declines; they do not reproduce a bank's authentication flow on a real phone with a real SMS arriving while your app is backgrounded. A small pilot with staff buying genuine low-value items surfaces more problems in a day than a fortnight of sandbox testing.
Then instrument it: attempt rate, success rate, failure reasons, and where in the flow people leave. Payment problems are invisible without this — customers do not file tickets about a checkout they abandoned, they just do not come back.
Wiring payments into an app so the edge cases behave is the sort of work we do at CODT.
