Skip to main content
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.

​
What is live today

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

Quote and start as usual

The same four calls. Your code does not change and there is no Apple Pay flag to send.
2

Send the buyer to the hosted page

On a supported Apple device the page offers Apple Pay next to card entry. The buyer authorises with Face ID or Touch ID.
3

Follow it to settlement

Status and webhooks behave exactly as they do for a typed card payment - the payment method does not change the statuses you get.

​
Native Apple Pay

Planned, through the Rheon API. Native means your own app presents the Apple Pay sheet, with no redirect to a hosted page - 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. Until then the hosted page is the way to take Apple Pay.
How Apple Pay is presented inside the Rheon SDK is being decided separately - the flow keeps offering it on the hosted page for now.

​
Which buyers actually see it

Three things all have to line up, and only the third is about Apple: 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.