Google Pay, on the same page as everything else.
Google Pay appears as a one-tap button wherever the customer's device and browser support it — Android, and Chrome on desktop. The card behind it is tokenized, the authentication happens on the device, and the merchant's side is identical to any other card payment.
Four steps, most of them invisible.
- [ 01 ]
DETECT
The button renders only where Google Pay is actually available to that customer.
- [ 02 ]
TAP
The sheet opens with the amount and merchant name; the customer confirms a stored card.
- [ 03 ]
AUTHENTICATE
The device handles authentication — no separate challenge screen in the checkout.
- [ 04 ]
SETTLE
The tokenized payment settles to EUR in the same batch as your card takings.
What the customer sees
A Google Pay button beside the card form, opening the familiar sheet with the amount and your merchant name. Their card and address details come from the wallet rather than a form, which removes the two things that lose mobile checkouts: typing a card number and typing an address.
- [ 01 ]Shown only where it can be used
- [ 02 ]Card and address supplied by the wallet, not by typing
- [ 03 ]One sheet, no redirect, no second page
What you receive
Euros in the day's payout against one order reference, with the method recorded on the receipt. Nothing about your reconciliation, refunds, or reporting changes because a customer chose the wallet over the form.
- [ 01 ]Identical order, receipt, and payout to a typed card
- [ 02 ]Refunds against the order, back through the same wallet
- [ 03 ]Method recorded as a field, not as a separate system
What it takes to switch on
A toggle on the methods screen — the merchant registration and domain handling come with it. From then on the button appears automatically for eligible customers, and stays current as Google changes the sheet.
Google Pay — questions merchants ask.
No. It appears on Android and in Chrome on desktop, wherever the customer has a card saved to their Google account. The checkout only renders the button where it will actually work.
No. Both are toggles on the same methods screen and both run through the same order and receipt. You integrate once, and the wallets are configuration on top of that.
The device authentication carries it, so the customer doesn't see a separate 3-D Secure challenge on top of the wallet sheet.
Yes — the card behind the wallet can be tokenized for recurring charges, so a subscription started with one tap continues charging without the customer returning to the checkout.
Often switched on together.
Apple Pay
One-tap · Device tokenA one-tap sheet on the same page, paying with a device token so the real card number never appears.
[ 02 ]Card payments
Visa · MastercardThe default rail, with 3-D Secure 2.0 and strong customer authentication handled inside the flow.
[ 03 ]Recurring payments
Subscriptions · RetriesSubscriptions charged on your schedule, retried when they soft-decline, surviving card reissues.
Take a payment on every one of them.
A sandbox merchant, API keys, and a checkout with all of these switched on — so you can run each method end to end before you commit to anything.
Request sandbox access