+
+
+
+
+
+
+## Sign-in
+
+EVM and Tron are co-equal sign-in methods. The login screen offers parallel tabs:
+
+
+
+
+
+
+
+
+Supported chain × token combinations (8 networks):
+
+| Chain | Tokens |
+| --- | --- |
+| Ethereum, Arbitrum One, Optimism, Base, Polygon, BSC | USDC, USDT |
+| **Tron** | USDC, USDT (TRC-20) |
+| Sepolia (testnet) | FAU, USDC, USDT |
+
+You can switch your active destination at any time via **Manage Destination → Update Receiving Route**.
+
+## Client ID management
+
+Client IDs are the credential the Dashboard (and your own apps) use to call the API on your behalf. Each Client ID can be:
+
+- **Domain-restricted** (frontend use) — set `allowedDomains` to one or more HTTPS origins
+- **Backend-only** — leave `allowedDomains` empty for server-side use
+- **Fee-aware** — set a default `feePercentage` and `feeAddress`
+- **Operator-aware** — bind `operatorWalletAddress` for commerce payment flows
+- **Destination-bound** — bind `payeeDestinationId` for orchestrator patterns
+
+
+ 
+
+
+
+ 
+
+
+For full field reference, see [Client ID Management](/api-features/client-id-management).
+
+## Get Paid
+
+The **Get Paid** tab is your incoming-payments view. Create a request — amount, currency, optional reference and payer identifier — and the Dashboard generates a `pay.request.network` link to share.
+
+
+ 
+
+
+Each request shows status (Pending / Paid), the on-chain transaction hash once paid, and a copyable payment URL. Works identically for EVM and Tron destinations (single recipient on Tron).
+
+
+ 
+
+
+## Pay (outgoing)
+
+The **Pay** tab is your outgoing-payments view. Create a payment to one or more recipients on the same chain, sign the resulting transaction, and the Dashboard tracks settlement.
+
+
+ 
+
+
+| Outgoing flow | EVM | Tron |
+| --- | --- | --- |
+| Single payout | ✓ | ✓ |
+| Batch payout (one signature, many recipients) | ✓ | ✗ |
+
+For Tron payouts, send single payments per recipient. EVM batch payouts are documented at [Batch payouts](/use-cases/batch-payouts).
+
+## What the Dashboard does *not* do
+
+- It is not an admin / merchant control panel for downstream platforms — it's a user dashboard for your own wallet.
+- It does not manage webhooks today — webhooks are managed via the [auth-api](https://auth.request.network/open-api).
+- It does not host the payer-side checkout — that's [Secure Payment](/tools/secure-payments) at `pay.request.network`.
+
+## Open the Dashboard
+
+
+
+
+## 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
+
+
+
+
+
+ 
+
+ 
+
+ 
+
+ 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The Dashboard generates a **destination ID** in the ERC-7828 format. You only need to do this once per chain/token combo you want to receive on.
+
+
+
+ The Client ID is the credential the Dashboard uses on your behalf when you create payment links.
+ 
+
+
+ Click **Create**. The Dashboard returns a hosted payment URL on `pay.request.network`.
+
+
+ - A protocol for requests, payments, and 100% automated reconciliation. + A protocol for requests, payments, and 100% automated reconciliation. Receive crypto payments — across EVM and Tron — with cryptographic certainty about who paid what.
- Requests add business context to payments, eliminating manual accounting with cryptographic certainty. See how unique Request IDs prevent payment collisions: + Request Network is delivered through three surfaces that share the same wallet session and Client IDs.
-pay.request.network. Cross-chain swap-to-pay via Li.Fi. Tron and EVM payer wallets.
+ - How does Request Network compare to other approaches? -
- -