Apple Pay & Google Pay for your checkout

What you're actually buying

Apple Pay and Google Pay are not a separate merchant account or another acquiring contract. They are a payment layer that sits on top of the provider you already use — Stripe, Revolut, JCC, or any other. The wallet itself doesn't process money; it passes a tokenised card to your existing flow. So the question isn't "Apple Pay vs Stripe" — it's "Stripe with Apple Pay enabled" or "JCC with Google Pay on top".

Why one-tap checkout matters for mobile revenue

• Card entry is where mobile carts die — typing 16 digits, expiry, and CVC on a phone is the single biggest drop-off point in checkout
• Face ID or fingerprint replaces the form — the user confirms and the payment is done in under two seconds
• No redirects, no new tabs — the wallet sheet opens inside your page and closes back into the purchase flow
• Higher approval rates on mobile — tokenised transactions carry less fraud risk, so issuers decline them less often
• Subscriptions and repeats become easier — once a card is in the wallet, subsequent charges don't require re-entry

What the implementation actually includes

• Apple domain verification — you upload a file or add a DNS record to prove you own the domain; without it Apple Pay won't activate
• Merchant ID and certificates — we create the identifier in your Apple Developer account, generate the payment processing certificate, and keep it renewed before expiry
• Button built to Apple's rules — the black Pay button has strict size, corner radius, and placement requirements; a non-compliant button can be rejected during review
• Google Pay configuration — gateway and merchant parameters set in the Google Pay API, with environment separation for test and live
• Provider-side handling — the actual charge runs through your existing Stripe, Revolut, or JCC integration; the wallet only supplies the token
• Testing on real devices — we verify on physical iPhones and Android phones, because emulators don't reproduce wallet behaviour reliably

Honest limitations

• Apple Pay works in Safari and Apple apps — on Android browsers it's Google Pay; there's no cross-platform Apple Pay on the web
• HTTPS is mandatory — Apple Pay will not run on plain HTTP, and the domain must pass Apple's verification
• You never see the customer's card — the wallet issues a token, so refunds and chargebacks are handled through your provider, not through Apple or Google
• Card support depends on the issuer — most European cards work, but a small number of banks still block wallet provisioning
• Recurring payments need provider support — not all acquirers handle wallet tokens for subscriptions equally; we check this before starting

Works with the acquiring you already have

• Stripe — native Apple Pay and Google Pay support, tokens appear as regular charges in the dashboard
• Revolut Merchant — wallet payments enabled through the API, multi-currency friendly
• JCC — Cypriot acquiring with wallet support for local cards; useful for domestic customers
• Other providers — if your gateway supports wallet tokens, we can wire it through

If you don't have an acquiring contract yet, start with Stripe or Revolut — both support Apple Pay and Google Pay out of the box.

What you need to get started

• An active merchant account with Stripe, Revolut, JCC, or another supported provider
• Access to your domain's DNS or hosting to place the Apple verification file
• An Apple Developer account (free tier is enough for web Apple Pay)
• A Google account with access to the Google Pay API console
• Your logo and brand colour for the wallet sheet
• One working day for testing on your staging environment

Domain verification can take from a few minutes to 24 hours depending on DNS propagation. The full setup usually lands within 2-4 working days when the acquiring side is already live.

What the buttons look like in practice

• Product page button — a single "Buy with Apple Pay" or "Buy with Google Pay" button that skips the cart entirely for express purchases
• Checkout placement — wallet buttons above the standard card form, so returning users don't scroll past them
• Cart page — wallet options alongside the regular "Checkout" button for users who already decided
• Subscription flows — wallet confirmation for the first payment, then automatic renewals through the provider
• Responsive fallback — on unsupported devices the button hides automatically instead of showing a broken experience

Fees and pricing

Apple and Google don't charge the merchant anything extra for the wallet itself. You pay only your existing provider's commission — typically 1.5-2.9% plus the fixed fee, same as a regular card payment. There's no monthly fee to Apple or Google for web wallet acceptance.

Our integration work is a one-time project cost, not a subscription. The price depends on how many touchpoints you need and whether your provider already supports wallet tokens.

Timelines

Basic setup with one button on checkout — 2-3 working days. With domain verification, certificates, and testing on real devices — 3-4 working days. If your provider needs additional configuration or you want wallet buttons on multiple pages with custom logic — up to a week. All assuming the acquiring account is already approved and live.

Common questions before starting

• Do I need a separate contract with Apple or Google? — No. You need a free Apple Developer account and a Google Pay API profile, but no commercial agreement with either company.
• Does it work with all cards? — Most Visa and Mastercard cards issued by European banks work. A small percentage of issuers block wallet provisioning; those customers simply see the regular card form instead.
• What about subscriptions and repeat charges? — The first payment goes through the wallet, and subsequent charges run as tokenised transactions through your provider. We verify your provider supports this before enabling the button on subscription flows.
• Are there hidden fees? — No. You pay your provider's standard card commission. Apple and Google take nothing from web wallet transactions.
• How do we test without real money? — Both wallets have sandbox modes. We run test transactions with dummy cards on real devices, then switch to live and run a €1 charge that we refund immediately.