Apple Pay

Apple Pay as a payment method on the card flow - on the hosted page, or native in your own app through the API.

Apple Pay lets a buyer pay without typing card details: they pick it, authorise with Face ID or Touch ID, and the rest of the flow is identical to a typed card payment.

On the hosted page

Apple Pay is offered on the hosted payment page that POST /v1/card/purchase returns as redirectUrl. There is nothing extra to integrate: you run the card flow exactly as On/off ramps with cards describes, and Apple Pay appears as an option on a supported device.

1. Price it

   POST /v1/card/quote with the fiat currency and the amount the buyer pays. Nothing in the request says Apple Pay, and there is no flag to send.

2. Verify the buyer

   POST /v1/card/kyc-token returns the token that opens verification for them.

3. Send the buyer to the hosted page

   POST /v1/card/purchase answers redirectUrl. On a supported Apple device that page offers Apple Pay next to card entry, and the buyer authorises with Face ID or Touch ID.

4. Follow it to settlement

   POST /v1/card/status until the state is terminal, or take the webhook. The payment method does not change the statuses you get.

Provider sandbox on this deployment. The card calls above target the card provider’s sandbox: no card is charged and no real transfer settles. Every response says which environment answered in its environment field.

Native Apple Pay

Native means your own app presents the Apple Pay sheet, with no redirect to a hosted page. It goes through the Rheon API, so it belongs with the other card calls you make from your backend rather than with the embedded flow.

It needs more than an endpoint: a merchant identity and payment-processing certificates registered with Apple, and each partner whitelisted on the card partner’s Apple account before it can go live - so plan for that step rather than treating it as a same-day switch. The hosted page needs none of that.

Inside the Rheon SDK, Apple Pay is offered on the hosted card page within the flow.

Which buyers actually see it

Three things all have to line up, and only the third is about Apple:

Condition	How to check
The country is open on the card rail	Card countries
The currency is supported	Card currencies
The device and browser support Apple Pay	Apple’s own support, on the buyer’s side

A device that supports Apple Pay in a country we do not cover still cannot pay. Do not present Apple Pay as a promise before the quote comes back.

Fees

Apple Pay is a payment method on the card rail, so it is priced exactly like a typed card payment: the quote returns what the buyer receives, the rate, the provider fee, our markup, and the total, and the fees sit inside the total rather than on top. The payment method does not add a layer. The structure is on Fees and the card detail on On/off ramps with cards.

Related

• The full card flow: On/off ramps with cards.
• Where cards are open: Coverage.