> ## Documentation Index
> Fetch the complete documentation index at: https://docs.request.network/llms.txt
> Use this file to discover all available pages before exploring further.
# Secure Payment Pages
> Create hosted secure payment links and let payers complete payments from a dedicated secure flow.
## 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](/use-cases/compliance-gated-payments) for configuration details and [Hypernative Standard Screening Policy](/use-cases/hypernative-standard-screening-policy) for the default policy categories and thresholds.
## How the flow works
Call `POST /v2/secure-payments` with one or more requests.
The API creates Request records and returns:
* `requestIds`
* `token`
* `securePaymentUrl`
Send the payer to `securePaymentUrl`.
The hosted page loads the payment details and prepares the required transaction flow.
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](/api-reference/authentication) for implementation options.
## API Reference
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](/api-features/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](https://safe.global/) smart account derived automatically from the payer's connected wallet, bundled through [Pimlico](https://pimlico.io/). 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`](#gasless-token-approvals-eip-2612) (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](/api-features/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](https://eips.ethereum.org/EIPS/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](/api-features/payouts#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
Endpoint details, request and response schemas, and error codes.
Check supported chain and currency coverage before creating links.