Apple Pay & Google Pay

Wallets sit between cards and APMs. The shopper confirms in a native sheet instead of typing a card number, but what comes out the other side is a network token that rides the card rails — so unlike an APM, a wallet payment can be stored and rebilled.

Availability

Processor	Apple Pay	Google Pay	Notes
TagadaPay (managed)	✓	✓	Nothing to configure beyond your domains
Stripe	✓	✓	Also exposes Link and Klarna through Express Checkout
Checkout.com	✓	✓
NMI	✓	✓
Mastercard MPGS	✓	—	Apple Pay only

Every other processor charges a wallet-sourced card as a plain card if it gets one, with no cryptogram and no wallet indicator — which usually means worse authorisation rates and no liability shift. Treat the table above as the real list.

Two integration paths

Native (vault tokenization)

You open the sheet yourself. The encrypted wallet payload is decrypted inside TagadaPay’s PCI vault and turned into a Tagada token you charge like any other instrument. Works with every processor in the table.

Through-processor (Express)

The processor’s own element renders the button and confirms the payment. Less code, but you inherit that processor’s rules — and the resulting instrument may not be reusable.

Prefer the native path when you want one code path across processors, stored credentials for subscriptions, or control over the sheet. Prefer Express when you want the shortest possible integration on Stripe and do not need to rebill.

Native wallets with core-js

Check the device can pay

Both checks are async and must run before you render a button. Never render an Apple Pay button on a device that cannot use it.

import { isApplePayAvailable, isGooglePayAvailable } from '@tagadapay/core-js';

const canApple = await isApplePayAvailable();
const canGoogle = await isGooglePayAvailable();

Open the sheet from a user gesture

Apple Pay must be started synchronously inside a click handler. Any await before startApplePaySession and the browser will refuse to open the sheet.Pass your storeId and a public-restricted key: Apple Pay runs through TagadaPay’s platform integration (we hold the Apple certificates and register your checkout domains under them), and each registered domain has its own registration id. The session resolves the one for the current domain by itself, during merchant validation — after the sheet has opened, so it costs nothing at gesture time and there is no lookup code to write.

import { startApplePaySession, applePayTokenToTagadaToken } from '@tagadapay/core-js';

button.addEventListener('click', () => {
  startApplePaySession(
    {
      basisTheoryApiKey: 'key_***',
      storeId: 'store_xxx',
      tagadaApiKey: 'tp_pk_live_***',
      countryCode: 'FR',
      storeName: 'My Store',
    },
    { totalAmountMinor: 4999, currency: 'EUR' },
    {
      onSuccess: async (token, contacts) => {
        const tagadaToken = applePayTokenToTagadaToken(token);
        const approved = await chargeOnYourServer(tagadaToken, contacts);
        return { status: approved ? 'success' : 'failure' };
      },
      onError: (msg) => console.error(msg),
    },
  );
});

The sheet stays open while onSuccess runs, and shows what it returns (core-js 3.5.0 and later; earlier versions closed the sheet as a success before calling it):

`onSuccess` returns	The sheet shows
`{ status: 'success' }`, or nothing	The checkmark and “Done”
`{ status: 'failure' }`	”Payment Not Completed”. `onError` is not called: you already have the reason
`{ status: 'unknown' }`	Nothing: the sheet is dismissed. Use it when the charge is still pending or needs a redirect
it throws	”Payment Not Completed”, then `onError`

Apple abandons the sheet 30 seconds after the shopper authorizes. If onSuccess has not returned after 25 seconds, the sheet is dismissed as for unknown, and your code keeps running.Only when you mint the Basis Theory merchant session yourself do you need the id in hand — one call, before the click:

import { resolveApplePayRegistration } from '@tagadapay/core-js';

const registration = await resolveApplePayRegistration({
  storeId: 'store_xxx',
  apiKey: 'tp_pk_live_***',
});
// registration?.merchantRegistrationId → `merchant_registration_id`
// registration?.displayName            → `display_name`

null means the domain uses the store’s default platform configuration — that is normal, not an error: send no merchant_registration_id and behavior is unchanged.

Charge server-side

The browser never charges. Send the token to your backend and create the payment there.

const { paymentInstrument } = await tagada.paymentInstruments.createFromToken({
  tagadaToken,
  storeId: 'store_xxx',
  customerData: { email: 'shopper@example.com' },
});

await tagada.payments.process({
  amount: 4999,
  currency: 'EUR',
  storeId: 'store_xxx',
  paymentInstrumentId: paymentInstrument.id,
});

Google Pay is the same shape with startGooglePaySession and a GooglePayServiceConfig.

startApplePaySession and startGooglePaySession take (config, request, callbacks) and return void — they are not promises. The token arrives in callbacks.onSuccess.

Express Checkout (Stripe)

Stripe’s Express Checkout Element renders Apple Pay, Google Pay, Link and Klarna as one row of buttons. TagadaPay pins the intent to exactly the wallet the shopper pressed. You discover it through paymentSetup — an express_checkout:<processorId> entry carries the Stripe publishableKey and the per-method methods map — and confirm it with the headless SDK’s tagada.payment.processStripeExpress({ checkoutSessionId, processorId, paymentMethod }), which returns the clientSecret for stripe.confirmPayment(). Supported express methods are apple_pay, google_pay, link and klarna_express. Anything else the Stripe account has switched on is deliberately refused rather than half-handled.

An Express Checkout payment records a tokenless instrument. It settles the order it was created for, but there is no stored credential behind it, so it cannot be rebilled. Do not start a subscription from an Express button — use the native path.

What you must configure

Apple Pay — register every checkout domain with us

Apple Pay runs through TagadaPay’s platform integration: we hold the Apple certificates and register your domains under them. You never create an Apple Developer account, host a verification file, or manage a certificate.What you must do is register every domain that will show an Apple Pay button — checkout subdomains and any CDN alias you serve checkout from included. Do it yourself from the CRM, under Store → Integrations → Apple Pay: it picks up the store’s checkout domain, checks the association file, registers it with Apple and switches it on. An unregistered domain fails at merchant validation, before the sheet ever opens, and the failure is silent to the shopper (the button simply does not work). Registration is per-domain: a store served from two hostnames needs both registered.At runtime nothing is left for you to configure. startApplePaySession resolves the registration for the current domain from storeId + tagadaApiKey; when you drive the sheet yourself, resolveApplePayRegistration({ storeId, apiKey }) returns the same thing in one call (findApplePayRegistration(config, hostname) if you already hold the payment setup).

Google Pay — merchant id

Google Pay needs your Google merchant id for production, and the button will render in test mode without it. The gateway side is handled by TagadaPay.

Both — HTTPS and a real user gesture

Wallets need HTTPS and a genuine click or tap to open the sheet. Apple Pay additionally refuses localhost — test it through an HTTPS tunnel. Google Pay tolerates localhost in test mode.

Recurring and wallets

Unlike APMs, wallets can be rebilled. The wallet gives you a network token that is stored like a card, so a subscription started with Apple Pay keeps billing after the sheet is long gone. Two rules make the difference between a working rebill and a decline:

The cryptogram is single-use. It authenticates the first, shopper-present charge only. Replaying it on a later merchant-initiated charge gets the charge declined.
Later charges are merchant-initiated. They carry the stored credential and the network transaction id from the first payment instead. TagadaPay does this for you on the native path.

This is the practical reason to prefer native tokenization for anything with a subscription, a rebill or a post-purchase upsell.

Support matrix

Every method and processor in one filterable view.

Card tokenization

The same vault flow for plain cards.

From the SDKs

Wallet helpers in each package.

Overview

Payments

Web Integration

Tracking & Attribution

Node SDK

Funnels

Funnel demos

Examples

Shopify

WooCommerce

SaaS Billing

Headless SDK

Plugin SDK

Plugin CLI

Studio MCP (AI Agents)

Config MCP (AI Agents)

Hosting & A/B Testing

Internal

Apple Pay & Google Pay

Apple Pay & Google Pay

Availability

Two integration paths

Native (vault tokenization)

Through-processor (Express)

Native wallets with core-js

Express Checkout (Stripe)

What you must configure

Recurring and wallets

Next

Support matrix

Card tokenization

From the SDKs

​Apple Pay & Google Pay

​Availability

​Two integration paths

Native (vault tokenization)

Through-processor (Express)

​Native wallets with core-js

​Express Checkout (Stripe)

​What you must configure

​Recurring and wallets

​Next

Support matrix

Card tokenization

From the SDKs

Apple Pay & Google Pay

Availability

Two integration paths

Native wallets with core-js

Express Checkout (Stripe)

What you must configure

Recurring and wallets

Next