Secure Payment (pay.request.network) is the hosted page your payers land on when they click a payment link. It’s a defense-in-depth checkout: trusted contract addresses are hardcoded, every transaction is decoded and verified client-side, and the payer can pay from any of 8 supported chains in any supported wallet.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.
Why it exists
The Secure Payment page is intentionally separated from the merchant frontend so a compromised merchant site or API endpoint can’t trick a payer into signing the wrong transaction. The page:- Loads payment metadata from the Request API using a one-time token
- Validates every contract address against a hardcoded trusted set
- Decodes the transaction calldata and shows the payer what they’re about to sign
- Resolves payee addresses to ENS where available
- Refuses to broadcast if anything looks off
What the payer sees
Open the link
The payer clicks a
pay.request.network/?token=... URL you generated via POST /v2/secure-payments. The page loads payment details (amount, recipient, reference).Connect a wallet
The connect modal lists EVM and Tron wallets side by side.
Choose a chain and token
The page reads the connected wallet’s balances across supported chains and surfaces every chain × token combo with a sufficient balance. The same-chain options view is shown at the top of this page; for cross-chain payments the layout is identical except the banner reads “You’ll be paying across chain via Li.Fi” (in pink) instead of “You’ll be paying on the same chain as your recipient” (in slate).
Approve and sign
For ERC-20s, an approval transaction precedes the payment. The page shows a stepper (connect → confirm → setup → pay) and an optional Advanced view that decodes the calldata for inspection.
Confirm
The success screen shows the source and destination transaction hashes, with explorer links per chain. For cross-chain payments, a Li.Fi badge is displayed. If you set a 
redirectUrl when creating the payment link, an extra button appears at the bottom of the screen — defaulting to “Go Back and Close”, or whatever you set as redirectLabel — that takes the payer back to your site.Wallet support
The connect modal offers a curated wallet list — only the wallets explicitly registered in the app are surfaced; unrecognised injected providers are filtered out (this is what filters TronLink’s EVM injection out of the EVM list).| EVM wallets | Tron wallets |
|---|---|
| MetaMask | TronLink |
| Coinbase Wallet | Guarda |
| WalletConnect | Trust Wallet |
| Ledger | WalletConnect-Tron |
| Phantom | |
| Rabby |
TronLink also injects an EVM provider that converts Tron addresses to EVM-style. Secure Payment filters this out of the EVM wallet list because it would mis-route Tron payments — Tron is handled exclusively via the TronWeb integration.
Cross-chain via Li.Fi
When the payer’s selected source chain differs from the destination chain, Secure Payment routes through Li.Fi. The UI displays:- “You’ll be paying across chain via Li.Fi” on the options view
- The bridge fee in the cost breakdown
- A Li.Fi badge on the success screen
Tron support
Tron is fully supported as both a source and a destination for single-recipient payments:| Direction | Same-chain | Cross-chain (Li.Fi) |
|---|---|---|
| Tron → Tron (USDT/USDC) | ✓ | — |
| EVM → Tron | — | ✓ |
| Tron → EVM | — | ✓ |
Compliance-gated payments (KYT)
When the merchant has enabled a Know Your Transaction policy on the receiving destination, the secure payment app screens the connected wallet before showing payment options. Wallets that fail the screen see a policy-failure view and cannot reach the sign step. Optional privacy flags can also keep the payment amount and the payee address masked until the screening passes. See Compliance-gated payments for the merchant-side configuration.Smart accounts (gasless on EVM)
For supported EVM destinations, Secure Payment can route payments through an Account Abstraction smart account so the payer doesn’t need to hold gas-token balance. The flow is invisible to the payer beyond a slightly different transaction signature step. The integration uses Pimlico for bundling and Alchemy gas policies for sponsorship — see Secure payment pages for the full spec. Smart-account routing is EVM-only. Tron payments use the standard TronWeb path.Error states
The Secure Payment app handles a few well-defined error states with clear copy:| State | Message |
|---|---|
| Link expired (>7 days, or already paid expired) | “You are coming too late. Please contact the recipient to send you a new payment link.” |
| Token not found / invalid URL | ”This URL is invalid. Please check the link and try again, or contact the recipient of this payment.” |
| Already paid | ”If that is not the case, please check the link and try again, or contact the recipient of this payment.” |
| Calldata validation fails | ”There is an issue with this payment call data. Please contact the recipient to send you a new payment link.” |
What Secure Payment does not do
- It does not persist transaction history beyond the immediate confirmation screen — explorers and webhook events are the source of truth.
- It does not provide a payee-side dashboard — that’s Dashboard at
dashboard.request.network. - It does not accept payments without a backing Request — the link must originate from
POST /v2/secure-payments.
Open Secure Payment
Open pay.request.network
Try a payment link in the live app.
Related
Multi-chain checkout
The payer experience and how it routes across chains.
Programmatic payment links
The API call that mints these links.
Secure Payments reference
Full request/response schemas.
Dashboard
The payee-side companion.