Skip to main content

Prerequisites

  • Payward Services API credentials (see Authentication Guide)
  • A verified user with at least one account
Only cryptocurrency deposits are supported. Fiat deposits are not available through the Payward Services API.

Crypto deposits

Deposit workflow

1

List deposit methods

2

Create deposit address

Generate a new deposit address for the user. POST /v1/accounts/{account_id}/funds/deposits/addresses
3

Display address to user

Retrieve and display the deposit address in your UI. GET /v1/accounts/{account_id}/funds/deposits/addresses
4

User sends crypto

The user sends crypto from their external wallet to the deposit address.
5

Receive webhooks

Listen for deposit status updates. deposit.status_updated
Completed deposits will appear in GET /v1/accounts/{account_id}/portfolio/transactions?types=deposit.

Step 1: list deposit methods

Query available deposit methods for a crypto asset. Use the method’s id from the response (passed as method_id) when creating an address in Step 2.
Most cryptocurrency deposits are free, with minimum deposit amounts varying by asset. A few cryptocurrencies are charged an address_setup_fee (a one-time fee on the user’s first deposit to a new address) or a per-deposit fee.

Response example

Key fields to display to users: network, fee, minimum, and network_info.est_confirmation_time. Pass the method’s id back as method_id when creating a deposit address.

Step 2: create a deposit address

Generate a deposit address using the method id from Step 1 as method_id. Display the address to the user so they can send crypto from an external wallet.
Some networks (e.g., XRP, XLM) require a tag or memo in addition to the address. If tag or memo is present in the response, your UI must display it and instruct the user to include it when sending funds. Deposits sent without the required tag/memo may be lost.

Step 3: list deposit addresses

Retrieve existing deposit addresses for a given asset and method. Use this to display previously generated addresses to users without creating new ones each time.

Response example

Best practices

  1. Always display tag/memo: For networks that require a tag or memo (XRP, XLM, etc.), prominently display it alongside the address. Missing tags/memos can result in lost funds.
  2. Set expectations: Show minimum amounts and est_confirmation_time from the methods response so users know what to expect before sending funds.
  3. Use fresh responses: Available methods, addresses and limits are user-specific and may change based on account standing, remaining limits, or regional regulations. Fetch fresh data before displaying options rather than relying on cached results.

Crypto withdrawals

Withdrawals are key-based: you save an address once, then use its key in each withdrawal request.

Withdrawal workflow

1

List withdrawal methods

Query available withdrawal methods for the target asset. GET /v1/accounts/{account_id}/funds/withdrawals/methods/ {asset_symbol}
2

Validate address (optional)

Verify the destination address is valid before saving. POST /v1/funds/withdrawals/addresses/validate
3

Save address (create key)

Store the validated withdrawal address for the user. POST /v1/accounts/{account_id}/funds/withdrawals/addresses
4

Preview / submit withdrawal

Submit the withdrawal request. POST /v1/accounts/{account_id}/funds/withdrawals
5

Monitor status (webhook / polling)

Track the withdrawal via webhooks (withdrawal.status_updated) or transaction polling.

Step 1: list withdrawal methods

Call this first to determine the method’s id (passed as method_id in later requests), fee estimates, limits, and optional fee_token.

Response example

This endpoint validates the destination before you save it.

Step 3: save withdrawal address

Save the address once and keep the returned key for future withdrawals.

Step 4: preview and submit a withdrawal

Use preview=true to quote fees and totals without creating a withdrawal, then submit with preview=false.

Statuses

Withdrawal best practices

  1. Use idempotency keys: Always generate a unique UUIDv4 and send it as the Idempotency-Key HTTP header per intended withdrawal to avoid duplicate sends on retries. Replayed responses include Idempotent-Replayed: true.
  2. Preview first: Run a preview request immediately before submit so users can confirm amount, fee, and total.
  3. Refresh expired fee tokens: fee_token values are short-lived. If a withdrawal is rejected due to an expired/invalid token, fetch withdrawal methods again (or run a fresh preview) to get a new fee_token and retry.
  4. Persist key ownership: Store which key belongs to each user and enforce access checks in your app.
  5. Handle memo/tag networks: For XRP/XLM-like networks, capture and persist memo/tag fields when addresses are saved.
  6. Monitor with webhooks: Subscribe to withdrawal.status_updated and reconcile events against your internal withdrawal records.

Common errors

API reference