Overview

Accept stablecoin payments without holding funds or keys.

RSends is a non-custodial stablecoin payment gateway. Your customer pays in stablecoin on Base, and the funds settle on-chain directly into your own wallet through an immutable smart contract — the router. RSends never holds, controls, or can move them.

Funds are yours the instant the transaction confirms

This is the whole point of RSends, and what makes it different from a custodial processor. There is no balance to track, no reserve withheld, and no payout to wait for: the payer's wallet sends the stablecoin straight to your wallet in the same transaction that records the payment. RSends only watches the chain and tells you it happened.

The contrast, stated plainly

A custodial card processor receives your customer's money, parks it in a balance, keeps a reserve against chargebacks, and pays you out days later. RSends does none of that — it never receives the money at all. The only thing it moves is information.

How a payment flows

Step	What happens
1. Create an intent	Your server calls `POST /api/v1/merchant/payment-intent` with the amount, settlement token and your destination wallet. You get back the intent and its `onchain` pay instructions.
2. Send the payer to checkout	Redirect the customer to the hosted checkout on `demo.rsends.io/pay/{intent_id}`. They connect their own wallet and approve the payment in the browser.
3. Settle on-chain	The browser calls `pay(...)` on the router. The stablecoin moves payer → your wallet and a `PaymentMade` event is emitted, atomically. Your amount always arrives whole; on the sandbox router the payer additionally covers a small on-chain fee on top (see Payment intents).
4. Reconcile	RSends indexes the event, matches it to your intent, and delivers a `payment.completed` webhook carrying the on-chain proof. You can also read the chain yourself.

Environments

There are two environments. Sandbox is live today and is what a partner can integrate against right now. Production is not deployed yet — the mainnet router has not been published, so the values below are marked as pending and will be filled in at launch.

	Sandbox	Production
Base URL	`https://pay.rsends.io/api/backend`	Pending — assigned at launch
Network	Base Sepolia (84532), Avalanche Fuji (43113), TRON Nile	Base (8453), Avalanche C-Chain (43114), TRON
API keys	`rsend_test_…`	`rsend_live_…`
Tokens	USDC and native ETH (test tokens, no real value)	Enabled per jurisdiction at rollout
Router	`0x2Ec3…58CA` — `routerVersion 1`, charges an on-chain flat fee	Pending — RSendsRouterV2, fee-less
Checkout	`demo.rsends.io/pay/{intent_id}`	Pending

The REST API is served over HTTPS and every response is application/json. Endpoint paths are identical in both environments — only the base URL, the key and the chain change. So the sandbox call for /api/v1/merchant/payment-intent is:

sandbox — full URL

https://pay.rsends.io/api/backend/api/v1/merchant/payment-intent

Why the base URL carries an /api/backend prefix

The sandbox API is reached through the RSends edge, which forwards your Authorization, Content-Type and X-Idempotency-Key headers to the backend and returns its status and body verbatim. Two consequences worth knowing up front: response headers other than Content-Type are not passed back (so the X-RateLimit-* headers are not visible on this base URL — the limits themselves still apply, and are documented in Errors), and a request that takes longer than 25 seconds returns 502 BACKEND_UNREACHABLE. A dedicated API hostname is planned for launch.

Getting started in three steps

The Quickstart walks all of this end to end, with working calls.

Step	What you do
1. Get an API key	Self-serve: sign in, open `/app` → API keys → Merchant keys and create a `rsend_test_` key (org `admin` role required). Your organisation must be approved before the merchant API answers — see Authentication.
2. Create & host a payment	Call Payment intents and send the payer to the hosted checkout.
3. Listen for webhooks	Register a webhook and verify every delivery's signature before trusting it.

Verify on-chain yourself

Because settlement is on-chain, you never have to take RSends' word for it. Every payment is a public PaymentMade event you can read directly on BaseScan, keyed by your reference (the on-chain invoiceId).

The chain is the source of truth

The webhook is a convenience; the blockchain is the record. Anyone — you, your auditor, your customer — can independently confirm a payment settled, for the right amount, to the right wallet, without any access to RSends. Trust is not required.

What you'll need

A destination wallet address you control (an EOA or smart wallet on Base). This is where your money lands — RSends never holds the keys.
A server that can call the REST API and receive webhooks.
For testing: a wallet funded from public faucets — see Testing.