Skip to main content

​
Overview

Secure Payment Pages let you generate a hosted payment URL from the API and redirect the payer to a dedicated payment experience. This feature is useful when you want to reduce frontend tampering risk and separate payment execution from your checkout UI.

​
Built-in contract safety check

Before signing, the secure page validates that the transaction targets official Request Network contracts. The payer-facing status copy is:
  • “This is a safe smart contract”
  • “The smart contract you are interacting with is an official Request Network smart contract, it is audited and valid.”
If validation fails, the secure page warns the payer and prevents continuing with unsafe contract interactions.

​
KYT wallet screening

Secure Payment Pages can enforce KYT wallet screening when the payment destination has a compliance gate enabled. See Compliance-gated payments for configuration details and Hypernative Standard Screening Policy for the default policy categories and thresholds.

​
How the flow works

1

Create a secure payment link

Call POST /v2/secure-payments with one or more requests.The API creates Request records and returns:
  • requestIds
  • token
  • securePaymentUrl
2

Redirect the payer to the hosted page

Send the payer to securePaymentUrl.
3

Payer reviews payment details

The hosted page loads the payment details and prepares the required transaction flow.
4

Sign and submit payment transactions

The payer signs the returned transaction set from their wallet. Depending on token approvals, this can be one or more transactions.

​
Authentication

Both secure payment endpoints accept:
  • x-api-key, or
  • x-client-id with browser Origin
See Authentication for implementation options.

​
API Reference

POST /v2/secure-payments

Create a secure payment entry and return a hosted secure payment URL. View the complete endpoint documentation with request/response schemas and examples.

​
Crosschain Support

Secure payment pages support crosschain payments. When a payer connects their wallet, the page fetches balance information across supported chains via the paymentOptions field. The payer can select which chain and token to pay from, and the page fetches executable calldata for the selected route. Supported crosschain currencies: USDC, USDT Supported crosschain chains: Ethereum, Arbitrum, Base, OP Mainnet, Polygon, BNB Chain See Crosschain Payments for details on crosschain routing via LiFi.

​
Smart Account Payments

For supported EVM payments, the secure payment page can execute through an ERC-4337 Safe smart account derived automatically from the payer’s connected wallet, bundled through Pimlico. The whole payment — approval, funding, and settlement — runs as a single UserOperation. How it works:
  1. The payer authorizes the token spend. For tokens that support EIP-2612 permit (such as USDC), this is an off-chain signature with no separate approval transaction; for other tokens (such as USDT) it is a one-time on-chain approval.
  2. The smart account batches the permit/approval, the funding transfer from the payer’s wallet, and the payment transaction into a single UserOperation.
  3. The bundler submits the UserOperation and the page surfaces the resulting on-chain transaction hash on the success screen.
Supported chains for smart account payments: Ethereum, Base, Arbitrum, Optimism, Polygon, and BNB Chain (plus Sepolia testnet). Native-currency payments and Tron payments do not use the smart-account path.
Smart account payments are an automatic client-side behavior of the hosted secure payment page. There is no API field to enable them — the same GET /v2/secure-payments/:token/pay endpoint provides the transaction calldata, and the page decides whether to route through a smart account. To pay from an existing Gnosis Safe multisig programmatically, see Safe multisig payments.

​
Gasless token approvals (EIP-2612)

ERC-20 payments normally need a separate approve() transaction before the transfer, which costs the payer extra gas. On the smart-account path, the secure payment page checks each token at runtime for EIP-2612 permit support:
  • Permit-enabled tokens (e.g. USDC, EURC) — the payer signs an off-chain permit instead of sending an approval transaction. No approval gas is required, and the approval gas line item is hidden in the payer’s cost breakdown.
  • Non-permit tokens (e.g. USDT, DAI) — the page falls back to a standard one-time on-chain approve(), which costs native gas as usual.
The approval is a one-time authorization that stays in effect until revoked (the page exposes a revoke control), and it applies to both single payments and multicall payouts. Gasless approvals are available on the same chains as smart-account payments listed above.
Whether a token is gasless is determined per token at payment time by probing the token contract, not from a fixed list — any EIP-2612-compliant token gets the gasless signature path. USDC/EURC and USDT/DAI are cited here only as common examples.

​
Status outcomes

  • 200: token is valid and payable
  • 403: token expired or status is not payable
  • 404: token not found
  • 409: payment already completed

​
Next pages

Secure Payments API Reference

Endpoint details, request and response schemas, and error codes.

Supported Networks and Currencies

Check supported chain and currency coverage before creating links.