Skip to main content
This guide covers funding a user’s account from Apple Pay using the REST API together with the Payment Widget. Every deposit runs through the widget’s Authorize flow, where the user authorizes with Apple Pay. Your backend only creates the quote and the widget session.

Prerequisites

Walkthrough

The diagram shows an Apple Pay transaction authorization.

Check available rails

Call List rails to verify Apple Pay deposit is available.

Check capabilities

Call List capabilities to confirm the user has the apple-pay capability enabled with no unmet requirements.

Select destination account

deposits can target any account. If the selected account is not in the account’s currency, the amount will be converted at settlement using Uphold’s prevailing rate. Make sure the destination asset has the necessary features enabled.

Find an existing account

Call List accounts to retrieve the user’s accounts and let them pick the one they want to fund.

Create a new account

If the user has no accounts, create one with Create account before proceeding.

Create a quote

Call Create quote with Apple Pay as the origin and the user’s account as the destination. Specify Apple Pay as the origin with type: "apm" with method: "apple-pay".
A successful response includes the quote details and a requirements array. For Apple Pay, it contains authorize:apple-pay, which indicates that the user must authorize Apple Pay before the transaction can be created.

Present the order summary

Before creating the transaction, display an order summary of the quote — the amount, fees, and the origin and destination — so the user can review it. Here’s an example:
Apple Pay order summary

Authorize and create the transaction

After the user confirms the Apple Pay quote, hand off to the Payment Widget Authorize flow. It presents the Apple Pay sheet, creates the transaction, and polls until a terminal status is reached. Apple Pay authorizes per transaction on the user’s device — there is no stored authorization to reuse, so the user confirms with Face ID, Touch ID, or their passcode every time. By default, the widget renders a full walkthrough around the authorization; in headless mode, it renders only the Apple Pay button so you can embed it directly into your own UI — see Headless mode below.

Create an authorize session

Call Create widget session with flow: "authorize", the quoteId and with the requirements array containing authorize:apple-pay. For web apps, also include the top-page domain.
The top-page domain is the domain shown in the browser’s URL bar — the very top-level page hosting the widget iframe. For web apps, it must match the domain you registered with Apple Pay for your merchant ID.

Set up the widget

Initialize the widget with the session. The widget presents the Apple Pay sheet, collects device data, creates the transaction, and polls until a terminal status is reached.
Both examples above are for web applications — either creating the iframe yourself or letting the SDK do it. For native apps using a WebView, see Native apps with the SDK for the SDK’s native-bundling pattern, or Setup with JavaScript for the no-SDK approach that loads the session url directly as the WebView’s top-level page.

Headless mode

By default, the widget renders a full authorization experience — a short walkthrough, the Apple Pay button, and a processing screen while the transaction is confirmed. In headless mode, it renders only the Apple Pay button, with no surrounding UI, so you can embed it directly into your own layout. Your app then owns the surrounding context and the post-authorization experience — progress and success feedback, and a way to cancel.
See AuthorizeFlowOptions in the SDK reference for the full type definition.

Handle the complete event

The complete event does not guarantee success. Always check transaction.status and trigger.reason.
Failure reasons in transaction.statusDetails.reason:

Handle cancellations

The cancel event fires when the user dismisses the Apple Pay sheet or navigates back without completing authorization.

Handle errors

The error event fires for critical unrecoverable errors — except authorize_transaction_failed, which is retryable. It is your decision whether to unmount the widget and show a user-facing error message, or leave it mounted so the user can try again.
Error codes in event.detail.error.code:
The Payment Widget handles most errors internally. For unrecoverable errors, the widget fires an error event. It is the host application’s responsibility to handle these events, present an error message to the user, and unmount the widget.

Monitor for settlement

transactions remain in processing while the payment settles. Monitor until the transaction reaches a terminal state.

Sample transaction

In a successful Apple Pay deposit, the origin is represented as an apm node with the method as apple-pay. The destination is the user’s account.

Notify the user

After the transaction completes, display the transaction details to the user so they can confirm the deposit succeeded. Here’s an example:
Apple Pay transaction completed confirmation

Troubleshooting

Having issues rendering Apple Pay? See Troubleshooting in the Payment Widget installation guide.
You now support Apple Pay deposits via the REST API together with the Payment Widget.