CollectPayment MethodsDigital Wallets

Wallet Configuration

Registering payment domains for Apple Pay and Google Pay

Overview

Wallet providers tie payments to the domain that presents the button. Apple in particular requires every domain serving an Apple Pay button to be verified in advance, and a payment from an unverified domain is rejected outright.

What that means for you depends entirely on where the button is rendered:

IntegrationPayment domains to register
Hosted checkoutNone. The button is presented on CrissCross’s checkout domain
React SDKEvery domain and subdomain that will render a wallet button
Server-to-serverEvery domain and subdomain that will render a wallet button

If you are on the hosted checkout, there is nothing on this page for you to do.

What CrissCross holds on your behalf

CrissCross acts as merchant of record and holds the entire wallet configuration:

  • The Apple Pay merchant identifier
  • The Apple Pay payment processing certificate, which decrypts wallet tokens
  • The Apple Pay merchant identity certificate, used to validate merchant sessions
  • The Google Pay gateway identifier

You do not need an Apple Developer account, and you never handle a certificate or a signing request.

You also never handle a wallet identifier in code. The CrissCross SDK is initialised with a sessionId, and CrissCross resolves the wallet identifiers for that session server-side. This is why there is no publishable key to manage and no wallet or processor credential in your front-end bundle.

Registering your payment domains

Required for the React SDK and server-to-server integrations.

1

Send CrissCross your domain list

Provide every domain and subdomain that will host a wallet button — for example checkout.example.com and www.example.com. Register your test domains too; verification is per-environment, and a domain verified for live traffic is not verified for sandbox.

Host the verification file

CrissCross supplies a verification file for each domain. Serve it, unmodified, at:

https://<your-domain>/.well-known/apple-developer-merchantid-domain-association

The file must be reachable over HTTPS with no redirect and no authentication. If your origin is behind an allowlist, permit Apple’s published IP ranges so verification can complete.

Confirm verification

CrissCross verifies each domain with Apple and confirms once it is active. Until a domain is verified, GET /v1/payment/available-methods will not return Apple Pay for sessions originating from it.

Google Pay

Google Pay needs no domain verification file, and for sandbox it needs nothing at all.

For live traffic, Google requires the business displaying the button to be registered in the Google Pay & Wallet Console. Register there, accept the Google Pay Acceptable Use Policy and Terms of Service, and submit the screenshots Google asks for — item selection, pre-purchase, payment method selection, and post-purchase. Send CrissCross the merchant identifier Google issues and it will be resolved into your session configuration automatically.

Native applications

The paths on this page cover web integrations. Accepting wallet payments inside a native iOS or Android application requires the app to hold its own wallet entitlement and merchant configuration, which is not covered here. Contact your CrissCross representative.

Keeping domains current

Domain verification is not one-off:

  • Adding a domain, including a new subdomain, means registering and verifying it before it can present a button.
  • Removing a domain should be reported so it can be deregistered.
  • Moving environments needs its own registration — sandbox and live are verified separately.

Additional resources