Apple Pay on Radial vs. on Gr4vy

This is a summary breakdown of how Apple Pay on the web differs between Radial’s platform and Gr4vy’s platform. The primary distinction is around ownership and management of the Apple merchant identity and the merchant validation TLS flow.

A Key Distinction

The merchant identity certificate is a TLS client certificate used during Apple Pay’s merchant validation step — the server-to-server handshake that occurs when a customer taps the Apple Pay button on the web.

This is where the two integrations diverge significantly.

Gr4vy — Apple & TLS Are Managed for You

For web integrations, Gr4vy removes the need for the merchant to directly maintain an Apple Developer relationship. This extends to merchant validation and TLS management.

You do not bring your own merchant identity certificate. Gr4vy owns and manages the Apple merchant identity and the associated TLS client certificate on your behalf.

During merchant validation, your server does not establish a mutual TLS connection directly with Apple. Instead, your frontend or backend calls Gr4vy’s Apple Pay session endpoint:

POST /digital-wallets/apple/session

passing:

• validation_url
• domain_name

Gr4vy then performs the authenticated server-to-server merchant validation call to Apple using Gr4vy-managed credentials and returns the merchant session object, which is passed into:

session.completeMerchantValidation()

What you do still own:

• Domain verification
• Hosting Apple’s domain association file

You must download the Apple Pay Domain Association File from the Gr4vy dashboard and host it at:

https://{domain}/.well-known/apple-developer-merchantid-domain-association

for every domain where Apple Pay is enabled.

This proves control of the domain, but it is not merchant TLS certificate management.

Operationally, this means:

• No Apple Developer account required
• No Merchant ID management
• No .p12 / PKCS12 handling
• No keystore configuration
• No merchant-side TLS maintenance
• No merchant-side certificate rotation responsibilities

Gr4vy fully abstracts the Apple-facing merchant validation flow.

Radial — Merchant-Owned Apple Relationship with Platform-Assisted Certificate Management

Radial’s Apple Pay integration still requires the merchant to maintain a direct Apple relationship and participate in Apple credential management.

The merchant must maintain:

• An Apple Developer account
• Apple Merchant IDs
• Apple domain registration and verification
• Certificate renewal responsibilities

However, unlike a fully self-managed Apple Pay implementation, Radial provides portal-assisted certificate management as part of its platform.

In the Radial Payments & Fraud portal, the merchant:

1. Generates a Certificate Signing Request (CSR) through Radial
2. Uploads the CSR to Apple Developer
3. Downloads the signed certificate from Apple
4. Uploads the signed certificate back into Radial
5. Activates the certificate within the Radial platform

This means the merchant still owns the Apple trust relationship and operational lifecycle, but Radial participates in certificate storage and usage within the payment platform.

So while the merchant remains responsible for Apple onboarding and renewal, Radial abstracts portions of the underlying certificate hosting and activation workflow.

What the merchant still owns

• Apple Developer account
• Apple Merchant ID
• Apple domain registration/verification
• Certificate issuance participation
• Certificate renewal lifecycle
• Apple onboarding responsibilities

What Radial assists with

• CSR generation
• Certificate storage/activation within the platform
• Apple Pay payment processing APIs
• Tokenized payment authorization flows

Unlike Gr4vy, Radial does not eliminate the merchant’s Apple relationship. The merchant still operates as the Apple-recognized entity and participates directly in certificate management and renewal.

Side-by-Side Summary

Practical Implications

Gr4vy

Gr4vy is the lower-overhead integration path.

Apple onboarding complexity, merchant identity certificate management, TLS configuration, and certificate rotation are abstracted away from the merchant. The tradeoff is reduced direct ownership of the Apple-facing trust chain.

This model is operationally simpler, especially for merchants that do not want to manage Apple Pay infrastructure internally.

Radial

Radial keeps the merchant directly involved in the Apple ecosystem.

The merchant still owns the Apple Developer relationship, Merchant IDs, and certificate lifecycle responsibilities, even though Radial assists with CSR generation and certificate hosting within the platform.

Compared to Gr4vy, this provides:

• Greater merchant ownership of the Apple relationship
• More visibility into Apple onboarding and credential management
• More operational responsibility around renewal and platform configuration