Can we take card payments in the app, or do we have to use Apple and Google billing?

Physical goods, and services the customer receives outside the app, can go through a payment gateway with Apple Pay, Google Pay, or Stripe. Digital goods and features consumed inside the app have to use in-app purchase on iOS and Play Billing on Android. We map each thing you sell to the right route before any screen gets built.

How much work is Apple Pay and Google Pay on top of an existing Stripe integration?

Usually a short phase measured in days. It needs a merchant identifier at Apple, a Google Pay merchant configuration, wallet support enabled on the gateway, and device testing with a live card. Your PCI scope normally stays where it is, because the card number still never reaches your server.

Should we build a balance wallet inside the app?

Only when the product genuinely holds money between transactions, such as marketplace funds waiting on a payout or a transit top-up. Holding customer balances is a regulated activity in many jurisdictions, so it usually needs an e-money partner or a licence, and it brings reconciliation and dormant balance questions with it.

How do refunds work when the payment came through a wallet sheet?

The refund goes back to the original charge through the gateway, which is why every payment needs a record on your side with its gateway reference. For balance wallets we post the reversal as a ledger entry and show it in the customer history. Partial refunds are supported in both cases.

Our app was rejected for selling digital content with Stripe. What changes?

The digital items move to in-app purchase, while anything consumed outside the app can stay on your gateway. We keep one entitlement system so a subscriber sees the same access whichever route paid for it. Talk to us before you resubmit, because the fix is usually smaller than the rejection email suggests.

Mobile Payment & Wallet Integration

Apple Pay, Google Pay, Stripe and in-app wallet balances for iOS and Android apps, with SCA, refunds, receipts and store billing rules handled.

See our work:

Paymentz→ONLINEPAY WALLET→COINAGE WALLET→

A mobile payment flow has more parts than a web checkout. The device runs a payment sheet on its own secure element, the platform decides whether you were allowed to sell the item that way, and your gateway holds the merchant account.

We add Apple Pay, Google Pay, Stripe, and stored wallet balances to iOS and Android apps, and we handle what surrounds the payment: authentication challenges, saved instruments, receipts, refunds, and reconciliation. Much of the work sits in the cases after the happy path and in the store rules that decide which route your product may use.

What we build

A wallet in mobile payment work usually means one of two things, and they behave differently.

Platform payment sheets

Apple Pay on iOS and Google Pay on Android carry a card the customer already saved. Confirmation runs through Face ID, Touch ID, or the device passcode, and the gateway receives a token instead of a card number. We configure the merchant identifier, certificates, and gateway support this needs, then keep a card entry path for wallets that are empty.

Cards, bank transfers, and saved instruments

Card payments run through Stripe or your existing gateway, with card fields hosted by the gateway so the number never reaches your server or logs. Bank transfer flows add a reference per order and a screen for transfers that arrive a day later. Returning customers pay with a tokenised card confirmed by biometrics.

A stored balance inside your product

Some products hold money on account: transit top-ups, gifting, marketplace funds waiting on a payout, corporate expense balances. A balance wallet is closer to ledger software than to checkout, because every credit and debit needs an entry and a reason.

When a wallet belongs in the app, and when it does not

Apple Pay and Google Pay fit when the customer pays for something consumed outside the app: a delivered order, a booked service, a rental, a membership sold on your website. The card is already in the wallet, and the merchant account stays with your gateway.

They do not fit as a substitute for store billing. Apple's App Store Review Guidelines require in-app purchase for digital goods consumed inside the app, and Google Play requires Play Billing for the same. A Stripe button that opens a premium in-app feature puts the build at risk of rejection. Rules on linking out to an external purchase page differ by region, so we check the current position for your category first.

A stored balance wallet earns its place when the product genuinely holds money between transactions, a smaller set than most teams assume. Keeping customer funds on account is a regulated activity in the UK, the EEA, and other jurisdictions, so a balance usually needs an e-money partner or a licence. If the balance exists only to avoid card fees, reconciliation, refund obligations, and dormant fund questions will cost more than the fees saved.

We advise against a wallet for low-volume apps selling one physical product, where a hosted checkout page is enough, and for teams whose support desk cannot issue refunds against the gateway.

Who this is for

This suits marketplaces and on-demand platforms that collect from customers and pay providers, fintech apps holding a customer balance, subscription products billed on your own gateway, and apps that were rejected for using an external gateway for digital content.

What we deliver

A working payment flow on both platforms and the records behind it: wallet sheets, card entry, 3D Secure challenges and SCA exemptions, saved instruments, refunds, and receipts. Store receipts get verified on your server, with subscription state and renewals kept in your database.

On the gateway side we set up products, prices, webhook endpoints, wallet certificates, and sandbox credentials, then confirm payment on the server through signed webhooks with one idempotency key per event, so a duplicate delivery cannot create a second order. Balance wallets get a double-entry ledger and a reconciliation report tying the app balance to the bank and gateway.

Testing covers expired cards, insufficient funds, an issuer challenge, a double tap on the pay button, a payment that succeeds while the customer loses signal, and a refund after partial fulfilment, all on real devices.

How the engagement runs

Week one is discovery, and it decides the architecture: what you sell, whether each item is digital or physical, your storefronts, currencies, and whether money is held for someone else before payout. You get a short written scope at the end of it.

The build happens in sandbox, usually two to four weeks for card payments plus Apple Pay and Google Pay on one platform. A second platform, or a stored balance with provider payouts, adds a longer phase with its own testing.

Before launch we run a live transaction, watch the webhook land in production, and confirm the record appears in your admin.

Where the project starts

A plain idea means the payment choices are still open, so we pick the gateway, the merchant account structure, and the entitlement model while the screens are designed. It is the cheapest point to get the flow right.

An existing conventional codebase usually has a web checkout to port or a partial native integration to finish. We map what your backend records about an order, then extend from there. The common gap is a front-end integration where order state lives on the device.

An AI/vibe-coded prototype often has a working payment button, with the secret key in the app bundle, no webhook, and no order record on the server. The screens usually survive, and we rebuild the money path around them: keys move to the server, confirmation comes from signed webhooks, and refunds and receipts get a record. That protects your revenue and your customers' data.

What it costs

Work is billed at our flat rate of $39 per hour, or as a fixed scope once discovery is finished. The pricing page covers both models and monthly capacity from $2,699.

A mobile app MVP with a payment or subscription flow is listed there at a typical order of $4,800 to $8,500 across four to six weeks, and the payment flow is one part of that build.

Scope moves with a few things, counted in phases:

One platform or two, because wallet sheets are configured separately
A payment sheet only, or a sheet plus a balance ledger with payouts
One gateway and one currency, or several with settlement in more than one currency
Store billing, gateway billing, or both behind one entitlement system
Migrating saved cards or live subscriptions from a previous provider

Adding Apple Pay and Google Pay to an existing gateway integration is usually a short phase. A stored balance wallet with provider payouts carries its own compliance review.

Proof

OnlinePay Wallet is a native iOS and Android wallet app we built for a payments company, with biometric login, encrypted local storage, and KYC and AML hooks on a microservice backend. It shows a wallet where the money path and its compliance obligations sit inside the same product.

Paymentz is a fintech platform for international transactions, mass pay-ins and pay-outs, and local IBAN support, with white-label delivery for business clients. It is our evidence that the server side a mobile wallet depends on can carry real operational volume.

Coinage Wallet is a crypto exchange platform we customised from the Peatio foundation, with branding control and security work around exchange operations. It covers the balance and transaction history parts of a wallet product, where tokenised value moves and every entry is accounted for.

Related services

Mobile app development for the iOS and Android build around the payment layer
Payment gateway integration for gateway accounts, webhooks, payouts, and reconciliation
In-app purchases and subscriptions for StoreKit and Play Billing when the item sold is digital
App security audit and hardening for keys, local storage, and API access around payments

Next step

Tell us what you sell, which stores you publish in, and which gateway account you hold. We will say whether the payment sheet, store billing, or a balance model fits, and what the first phase involves.

Contact us with your current payment setup, or run the requirements through the Vasilkoff.info estimator for an initial scope and range.