# Validate an Apple Pay merchant session, then run a sale with the wallet token.

Validate an Apple Pay merchant session, then run a sale with the wallet token.

1. PREREQUISITE, done once: the merchant's domain is registered for Apple Pay in the Self-Care Portal, which issues the `appleDomainId` input used by `startApplePaySession`. There is no API operation for this; it is an external-system step supplying an input.

2. OPTIONAL — web flow only. Start and validate the Apple Pay merchant session by POSTing the `appleDomainId` and `appleValidationUrl` to the apple-pay-sessions endpoint. The returned `startSessionResponse` is passed to the Apple Pay JS API in the browser so Apple releases the cardholder's encrypted payment data. Skip this step for the in-app (native PassKit) flow, where the app obtains the token directly from Apple.
 [applePaySessions](/api/apple-pay-sessions)
3. The browser hands the `startSessionResponse` to the Apple Pay JS API (web flow) at the validation URL supplied by the `appleValidationUrl` input; the cardholder authorizes the charge in Apple Pay on their device, and Apple releases the encrypted payment data used by `runApplePaySale`. In the in-app (native PassKit) variant, the app obtains this token directly from Apple, skipping `startApplePaySession`.

4. Run the sale with the Apple Pay wallet data by POSTing to /payments. The payment method is a digital wallet: `type: digitalWallet`, `serviceProvider: apple`, and `encryptedData` set to Apple's encrypted payment data in hexadecimal. This is the same operation as a card sale, only the paymentMethod differs. The default `autoCapture: true` runs a normal sale that stays adjustable in the open batch.
 [payment](/api/payment)

## Workflow diagram

```mermaid
flowchart TD
  step0["1. domain registration · Manual"]
  step1["2. session validation request · API"]
  step0 --> step1
  step2["3. Apple Pay authorization · Manual"]
  step1 --> step2
  step3["4. wallet sale request · API"]
  step2 --> step3
```