> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.crisscross.money/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.crisscross.money/_mcp/server.

# Wallet Configuration

> What you need to configure to render Apple Pay and Google Pay buttons on your own site, and what CrissCross configures on your behalf.

### 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:

| Integration                                     | Payment domains to register                                       |
| ----------------------------------------------- | ----------------------------------------------------------------- |
| [Hosted checkout](/hosted-checkout)             | **None.** The button is presented on CrissCross's checkout domain |
| [React SDK](/wallets-react-integration)         | Every domain and subdomain that will render a wallet button       |
| [Server-to-server](/wallets-server-integration) | Every 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.

> **Note**
>
> 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.

#### 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

* **[Digital Wallets](/payment-method-digital-wallets)** — overview, supported workflows, refunds and reconciliation.
* **[React Integration](/wallets-react-integration)** — rendering the button once your domains are verified.
* **[Server Integration](/wallets-server-integration)** — submitting a wallet token yourself.