Skip to main content
Start with an authenticated read, then choose direct customer payment routes or the prefunded Treasury workflow.
Sandbox: https://api.sandbox.rails.wayex.com · Production: https://api.rails.wayex.com — all current endpoints are versioned under /v1. Examples use the sandbox base URL; swap in the production URL and a production key when you go live.

​
Connect

1

Get the correct API key

Sign in to the intended tenant account and open Developers → API keys. Use a secret key (sk_…) on your server. Store each tenant account’s key separately; a key never switches accounts.
2

Read an indicative rate

Confirm authentication with a read-only request:
This rate is indicative — it locks nothing, and the executed rate can differ. For direct routes, the binding rate is struck the moment your customer’s funds arrive. For Treasury, lock an exact price by requesting and accepting a short-lived conversion quote.
3

Choose the workflow

Continue with a direct customer route when every funding belongs to an onboarded customer. Use Treasury when your organisation prefunds its own isolated wallet and explicitly pays, converts, or withdraws.

​
Treasury: fund and pay

Wayex enables Treasury for your tenant account and sets its policy — fees, limits, and which capabilities (funding, payouts, conversions, withdrawals) are switched on. Requests against a capability that is not enabled are refused. Reads need the treasury:read scope; writes need treasury:write.
1

Check the account and balance

Confirm the tenant account, enabled rails/networks, and the wallet’s available, reserved, and pending amounts. The API key determines the account.
2

Fund the wallet

Fetch or create an AUD BSB/account funding instrument or stablecoin address. Send only to the exact instructions for this account, then wait until the net credit appears in available. See Funding and balances.
3

Create a beneficiary

This example creates an individual BSB/account recipient. The external reference is optional; Wayex generates one when you omit it.
If your account is configured to require reusable identity evidence, add a sumsub object with a single-use share token to this request: "sumsub": { "shareToken": "…" }. Without it, beneficiary creation fails with sumsub_evidence_required. The evidence attaches to the beneficiary — payout requests never carry the token.
4

Submit an AUD payout

Reuse the beneficiary ID and give the payout a new external reference and idempotency key:
5

Track settlement

accepted means the full source debit was durably reserved; it is not bank settlement. Subscribe to treasury.payout.updated and fetch GET /v1/treasury/payouts/{id} until the payout settles, fails, or returns.

​
Direct route: onboard and fund

1

Create and verify a customer

Create a customer with POST /v1/customers, issue a hosted verification link, and wait until the required entitlement is approved.
2

Create a payment route

Create an on-ramp or off-ramp route under the customer. The response provides reusable AUD or stablecoin funding instructions.
3

Fund the route

When the customer funds those instructions, Wayex prices at the live rate, creates a transfer, converts, and delivers the destination funds. You do not create or accept a direct-route quote.
4

Track the transfer

Subscribe to transfer webhooks and fetch the transfer for its authoritative lifecycle. See Payment routes.

​
Before sending funds

Sandbox never moves real funds — its provider rails are fully simulated. Production does. Before your first production funding, confirm the limits and exact asset/network with Wayex in writing.

Treasury workflows

Fund, pay, convert, withdraw, track, and reconcile.

API reference

Every endpoint explains prerequisites, balance effect, states, and safe retries.

Postman

Run the client API collection with tenant-bound environment variables.

Errors

Handle stable error codes and unknown outcomes safely.