Skip to main content
Apple Pay is a payment method on the card rail, not a product with its own endpoints. A buyer who picks it on the hosted card page goes through exactly the same four calls as a typed card payment, and nothing in your request says “Apple Pay”:
1

Price it

POST /v1/card/quote with the fiat currency and the amount the buyer pays.
2

Verify the buyer

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

Start the payment

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

Follow it to settlement

POST /v1/card/status until the state is terminal. The payment method does not change the states 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. The API has no call for it: it needs a merchant identity and payment-processing certificates registered with Apple, and each partner whitelisted on the card partner’s Apple account, so talk to us before planning it. The hosted page needs none of that.

Which buyers see it

The product story, fees included, is on Apple Pay.