What you’ll build
A backend that creates a Secure Payment link in response to your app’s events — a customer hitting checkout, an invoice being approved, a subscription renewing. The customer opens the link, pays from any chain/token in any supported wallet, and your webhook fires when the payment confirms. Audience: developers integrating Request Network into an e-commerce app, marketplace, SaaS, or accounting product. Apps used:- Auth API — Client IDs, webhooks
- Request API —
POST /v2/secure-paymentsandPOST /v2/secure-payments/payouts - Secure Payment — what your customer sees when they open the link
Prerequisites
Complete steps 1–4 of the Quickstart:- Sign in to the Dashboard with your wallet
- Create a payment destination
- Create a Client ID (with allowed domains for browser apps, empty for backend-only)
- Register a webhook URL pointing at your handler
clientId— passed asx-client-idon every API calldestinationId— composite ID combininghumanReadableInteropAddress+tokenAddress- Webhook signing secret — for verifying webhook payloads
Create an incoming payment link
UsePOST /v2/secure-payments to mint a link the customer pays into.
securePaymentUrl — share it with the customer. They open it on pay.request.network, connect a wallet, and pay.
Send the customer back to your site after payment
PassredirectUrl (and optionally redirectLabel) when creating the payment link. After a successful payment, the success screen renders a button that opens your URL — the payer clicks it to return to your site. There is no auto-redirect; the button is an explicit user action.
redirectUrlmust behttp(s). Other schemes (javascript:,data:, etc.) and HTML/script payload characters are rejected with400 redirectUrl must be a safe http(s) URL with no script/HTML payload.redirectLabelis 1–255 chars and rejects HTML control characters (<,>,&,",',`).redirectLabelcannot be set withoutredirectUrl— the API rejects with400 redirectLabel cannot be provided without redirectUrl.- If you don’t pass
redirectLabel, the button reads “Go Back and Close”.
POST /v2/secure-payments/payouts for hosted payout links.
EVM and Tron destinations side-by-side
Tron is a drop-in replacement for any EVM destination as long as you submit a single recipient per call. The shape is identical; only thedestinationId and addresses change format.
- EVM (USDC on Base)
- Tron (USDT on Tron)
Send a payout link (outgoing)
To pay someone (a contractor, vendor, refund recipient) via a hosted link they open and sign, usePOST /v2/secure-payments/payouts. Same shape, single recipient, EVM or Tron.
- EVM payout
- Tron payout
creatorWalletAddress.
Receive payment notifications
Your webhook endpoint receives signed POSTs as the payment lifecycle progresses. Verify the HMAC-SHA256 signature against your webhook secret before parsing the body.Next steps
Multi-chain checkout
What the customer sees when they pay across chains.
Batch payouts
Pay many EVM recipients in one signed transaction.
Webhook reconciliation
The reliable, signature-verified way to detect payments.
Secure Payments reference
Full request/response schemas for every endpoint.