Digital Wallets — Overview

NetValve supports Apple Pay™ and Google Pay™ as wallet payment methods. This page explains the operating model that sits behind both wallets so that the per-wallet guides (Apple Pay, Google Pay) can stay focused on the integration mechanics.

What changed: processor certificates

Historically, accepting Apple Pay on the web required each merchant to:

1. Sign up for an Apple Developer Account.
2. Create a Merchant ID and a Merchant Identity Certificate.
3. Create a Payment Processing Certificate tied to their processor.
4. Share both certificates and the private keys with NetValve so we could load them into the gateway.

That setup is no longer required. NetValve now operates as an Apple Pay Payment Service Provider (PSP) and holds its own processor certificate — also called the integrator certificate — with Apple. The same model applies on the Google Pay side: NetValve is the registered Google Pay Gateway, so merchants do not need to obtain a gateway certificate themselves.

In practice, this means:

• You do not need an Apple Developer Account.
• You do not need to generate, renew, or share any Apple Pay or Google Pay certificates.
• NetValve performs the mTLS handshake with Apple on your behalf, signs your domain registration with the NetValve processor identity, and decrypts the wallet payload server-side using our keys before routing the transaction to the acquiring bank.

What stays on your side is the front-end integration (rendering the Apple Pay / Google Pay button, calling the wallet JS APIs, sending the resulting token to NetValve) and, for Apple Pay only, hosting Apple's well-known domain-association file. Everything cryptographic is handled by NetValve.

Gateway ID for Google Pay

When you configure the Google Pay JS SDK on your site, use gateway: "netvalve" and set gatewayMerchantId to your NetValve MID. NetValve's gateway registration with Google is what allows your front-end token request to succeed without a separate certificate exchange.

Who handles what

The table below describes the default processor-certificate model. If you choose to bring your own Apple Pay certificate (see Bring your own certificate), the Apple Developer Account, both Apple certificates, the domain-registration call, and the well-known association file all shift to your side — NetValve only loads the certificates you supply and uses them at runtime. The session-validation, front-end, and Sale-submission steps are identical.

Step	You (the merchant)	NetValve
Apple Developer Account	—	Owns the developer account used as the processor identity.
Apple Merchant Identity Certificate	—	Holds and renews the integrator certificate.
Apple Payment Processing Certificate	—	Holds the cert; payloads are decrypted server-side.
Google Pay Gateway registration	—	Registered with Google as gateway netvalve.
Apple Pay domain registration call	Trigger via API (POST /registerApplePayDomain) — or ask your NetValve representative.	Performs the mTLS call to Apple using the processor certificate and stores the registration.
Hosting apple-developer-merchantid-domain-association	Serve at /.well-known/ on every domain you want to register.	Provides the exact file contents to host.
Front-end wallet button + JS SDK calls	Implement on your site / app.	—
Session validation (Apple Pay)	Server-side call to POST /initializeApplePaySession.	Validates the merchant session with Apple and returns the session object.
Wallet token submission	Include applePaySSL / googlePaySSL in the Sale request.	Decrypts, routes through the acquirer, and returns a normal transaction response.

End-to-end flow

Setting up Apple Pay on your domains

The only piece of one-time setup is registering each domain you intend to serve Apple Pay from. You have two options:

Option 1 — Self-serve via the Payment API

Call POST /registerApplePayDomain with your NetValve API credentials. NetValve will perform the registration on Apple's side using its processor certificate and store the resulting merchant registration against your client.

POST /registerApplePayDomain — request

{
  "domainNames": [
    "shop.example.com",
    "www.shop.example.com"
  ],
  "displayName": "Example Store"
}

200 OK — response

{
  "traceID": "b126345b-6199-4635-9bf2-f9aadbdd4d58",
  "responseTimestamp": "2026-05-13T09:21:04.512+00:00",
  "responseCode": "GTW_1000",
  "responseMessage": "Registration successful",
  "merchantRegistrationId": "289e253d-f955-4e29-a2c7-bb1805883ee0"
}

Notes:

• domainNames accepts one or more fully qualified hostnames. Register every variant that customers may reach the Apple Pay sheet from (apex, www, subdomains).
• displayName is shown to the customer in the Apple Pay sheet — keep it consistent with your brand.
• Before calling this endpoint, you must already be hosting the well-known association file (see below). Apple verifies it as part of the registration request.

See the full reference at Register Apple Pay™ Domain.

Option 2 — Ask your NetValve representative

A Backoffice UI for managing wallet domain registrations is on the roadmap. Until it ships, if you prefer not to call the API yourself, contact your NetValve representative with the list of domains and a display name and we will perform the registration for you.

Hosting the domain-association file

Apple verifies that you control each domain by fetching a static file. NetValve will provide you with the exact contents — it corresponds to NetValve's registered merchant identifier, not yours.

Host it at:

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

Requirements:

• Served over HTTPS with a valid TLS certificate.
• Returned with HTTP 200 OK.
• Identical bytes across every domain you register.
• Must be reachable from the public internet at the time you call /registerApplePayDomain.

If the file is not reachable, the registration call will return REGISTRATION_FAILED with the underlying Apple error in responseMessage.

Sandbox vs production

Sandbox registrations use Apple's apple-pay-gateway-cert.apple.com endpoint and the NetValve UAT integrator certificate. When you go live, register the same domains again against the production environment.

Setting up Google Pay

Google Pay does not require a per-domain registration step. As long as NetValve is configured for your MID, your front-end can request a Google Pay token using:

• gateway: netvalve
• gatewayMerchantId: your NetValve MID or site ID

You can call POST /initializeGooglePaySession to fetch the merchant configuration NetValve has on file (display name, merchant identifier, allowed origin) so you can pass it into Google's PaymentsClient configuration without hard-coding it.

POST /initializeGooglePaySession — example response

{
  "merchantIdentifier": "BCR2DN4T...",
  "merchantName": "Example Store",
  "merchantOrigin": "shop.example.com"
}

Submitting wallet transactions

Once you have a token from Apple Pay or Google Pay, submit it as part of a standard NetValve sale request:

• Set paymentType to WALLET.
• Set walletType to APPLE_PAY or GOOGLE_PAY.
• Include the wallet payload under applePaySSL or googlePaySSL.

See the wallet-specific guides for full payload examples:

• Apple Pay™ Integration
• Google Pay™ Integration

FAQ

Do I still need an Apple Developer Account? No. NetValve's processor certificate is sufficient. You only need an Apple Developer Account if you also want to ship a native iOS app — that's an App Store requirement, not a payments requirement.

Can I bring my own Apple Pay certificate? Yes. NetValve supports both paths: the processor-certificate model (recommended for new integrations) and a "bring your own certificate" path for merchants who already have an Apple Developer Account or who need to hold the certificate themselves. See Bring your own certificate in the Apple Pay guide.

What happens when NetValve's certificate is renewed? Renewal is transparent. You don't need to do anything — domain registrations and active sessions continue to work across the rotation.

Do I need to re-register domains when going live? Yes. Sandbox and production are separate Apple environments with separate processor certificates. Register each domain in both environments before launching.

The transaction works in Safari on macOS but fails in iOS Safari. What gives? Almost always a domain-association issue. iOS Safari is stricter about cache and redirects. Verify the file is reachable on the exact host the customer is browsing (including www vs apex) and is returned with Content-Type: text/plain.

Related references

• Apple Pay™ Integration
• Google Pay™ Integration
• Register Apple Pay™ Domain (API)
• Initialize Apple Pay™ session (API)
• API Authentication