> ## Documentation Index
> Fetch the complete documentation index at: https://rheon.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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`](/api-reference/cards/start-a-card-purchase) returns as `redirectUrl`.
There is nothing extra to integrate: you run the card flow exactly as
[On/off ramps with cards](/products/cards) describes, and Apple Pay appears as an
option on a supported device.

<Steps>
  <Step title="Price it">
    [`POST /v1/card/quote`](/api-reference/cards/display-quote-for-a-card-purchase)
    with the fiat currency and the amount the buyer pays. Nothing in the request
    says Apple Pay, and there is no flag to send.
  </Step>

  <Step title="Verify the buyer">
    [`POST /v1/card/kyc-token`](/api-reference/cards/verification-token-for-the-buyer)
    returns the token that opens verification for them.
  </Step>

  <Step title="Send the buyer to the hosted page">
    [`POST /v1/card/purchase`](/api-reference/cards/start-a-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.
  </Step>

  <Step title="Follow it to settlement">
    [`POST /v1/card/status`](/api-reference/cards/poll-a-card-purchase) until the
    `state` is terminal, or take the [webhook](/webhooks). The payment method does
    not change the statuses you get.
  </Step>
</Steps>

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

## 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](/integration/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.

<Note>
  Inside the [Rheon SDK](/integration/sdk), Apple Pay is offered on the hosted card
  page within the flow.
</Note>

## 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](/api-reference/cards/where-a-card-payment-may-not-come-from) |
| The currency is supported | [Card currencies](/api-reference/cards/what-a-card-can-pay-in-and-what-it-buys) |
| 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](/fees) and the card
detail on [On/off ramps with cards](/products/cards#fees).

## Related

* The full card flow: [On/off ramps with cards](/products/cards).
* Where cards are open: [Coverage](/coverage).