Skip to main content
The Payment Widget handles crypto asset, network and address collection for withdrawals. Your backend creates the session, then continues with the REST API to create a quote and transaction once the user has provided the destination details.
The Payment Widget does not create any transaction. Transaction creation must be handled by your backend via the REST API.

Prerequisites

Walkthrough


Select source account

Crypto withdrawals can be sourced from any account. If the selected account is not in the withdrawal asset, the balance will be converted at the time of the transaction using Uphold’s prevailing rate. Make sure the origin asset has the necessary features enabled. Call List accounts to retrieve the user’s accounts and let them choose one with sufficient balance for the withdrawal.

Set a crypto destination

The widget lets the user select a crypto asset, choose a network and enter the destination address.

Create a widget session

Call Create widget session to start the select-for-withdrawal flow. To customize the theme and layout, see the example here.
The response contains a session object with a url field that loads the widget. Return response.session to your frontend as is.

Set up the widget

Initialize the widget for the select-for-withdrawal flow using the session data returned from the API.
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 Web SDK for the SDK’s native-bundling pattern, or Setup without the SDK for the no-SDK approach that loads the session url directly as the WebView’s top-level page.

Handle the complete event

The widget lets the user select a crypto asset, choose a network and enter a destination address. If the network requires a destination tag or memo, the widget prompts for it and warns the user if it’s missing. When the user completes the selection, the complete event fires with via: "crypto-network".
The event payload:
  • via — set to crypto-network when the user provides a crypto withdrawal address.
  • selection.asset — the selected crypto asset code (e.g. BTC, XRP).
  • selection.network — the selected blockchain network (e.g. bitcoin, xrp-ledger).
  • selection.address — the destination wallet address.
  • selection.reference — the destination tag or memo, if required by the network.

Handle cancellations

The cancel event fires when the user closes the widget without completing the selection.

Handle errors

The error event fires when an error occurs during the flow.

Create a quote

Use the selection data from the widget to create a quote via the Create quote endpoint.
Quotes typically expire quickly. Prompt for user confirmation within the expiry window and requote if needed.

Handle quote requirements

When the quote is returned, check the requirements array. If non-empty, resolve each requirement before creating the transaction.

Travel Rule

If the requirements array contains travel-rule, you must collect the required originator and beneficiary information before creating the transaction. For the full step-by-step implementation, see the Travel Rule withdrawal guide.

Create a transaction

Once the user confirms the quote, create the transaction using the Create transaction endpoint. If the original quote expired during the RFI process, create a new quote and proceed with the transaction using the new quote ID.
In a successful crypto withdrawal, the origin is the source account and the destination is a crypto-address node reflecting the recipient’s on-chain address.

Execution modes

Crypto withdrawals are executed in one of the following modes, indicated by destination.node.execution.mode:
The transaction is broadcast to the blockchain network. destination.node.execution.mode is onchain, and destination.node.execution.transactionHash is set once the transaction is completed.
When both the sender and recipient are Uphold users, the transfer is processed within Uphold’s infrastructure instead of the blockchain. This avoids network fees and is faster than on-chain processing.Each side sees the transfer from its own perspective:When both users belong to the same organization, the execution also identifies the counterpart account: destination.node.execution.accountOwnerId and destination.node.execution.accountId for the sender, and origin.node.execution.accountOwnerId and origin.node.execution.accountId for the recipient.Because funds move between Uphold accounts, the assets may differ from an on-chain transfer:
  • Sender: destination.asset is the asset of the recipient account associated with the address, which may differ from the one in the quote.
  • Recipient: origin.asset is the asset of the sender’s account, which may differ from the network’s asset or even be one the network doesn’t support, such as a fiat asset.
Used in development environments for testing. The transaction appears processed without affecting blockchain state, although user balances are updated. destination.node.execution.mode is simulated.

Monitor for settlement

Prefer webhooks for real-time updates, or fall back to polling if webhooks are not feasible.
  • Webhook events (recommended):
    • core.transaction.created
      • status: processing → initiated but not yet broadcast
    • core.transaction.status-changed
      • status: completed → broadcast and confirmed
      • status: on-hold → transaction checks paused (e.g., pending RFIs)
      • status: failed → transaction failed, check statusDetails for more info
  • Polling (fallback): Get transaction

Notify the user

Display an in-app confirmation when the transaction is completed, and send an email if applicable.
You now support crypto withdrawals via the Payment Widget.