Charge for your own API
Accept XRP or RLUSD for your APIs, data, and services. No XRPay account, merchant signup, API key, or purchase from an XRPay merchant is required.
Choose the integration you need
Standalone payments: use x402Middleware to charge for your own endpoints, or X402Client to pay compatible exact XRPL x402 endpoints. The public facilitator at https://api.xrpay.it/api/x402 needs no account or API key. Payments go directly to your chosen XRPL recipient.
Hosted digital commerce: sellers need an XRPay merchant account to list products and use managed orders, receipts, and private file delivery. Buyers do not need an XRPay account. Read the optional commerce guide.
The SDK is MIT licensed. Payments require XRPL wallets and network fees. This integration supports the exact XRPL x402 scheme for XRP and RLUSD.
Run a paid API in minutes
Use Node.js 20 or later. In an empty project, install the SDK and Express:
Save this complete server as paid-api.mjs. It charges 0.001 Testnet XRP per request:
Generate a receiving wallet with the XRPL Testnet faucet, selecting Testnet. The server needs its classic address, not its seed. Configure the address and a locally generated challenge secret:
X402_CHALLENGE_SECRET authenticates the payment challenges your API issues. It is not an XRPay API key. Keep it private, at least 32 characters long, and stable across processes and restarts. The same example is included at node_modules/@xrpay/x402/examples/paid-api.mjs.
In another terminal, request the endpoint without payment:
You receive HTTP 402 with a PAYMENT-REQUIRED header and the exact terms. A paying agent signs those terms and retries with PAYMENT-SIGNATURE. After validated settlement, your API returns HTTP 200, its JSON result, and a PAYMENT-RESPONSE receipt.
You host the API and control its response. No XRPay merchant or product record is created. Standalone payments do not create hosted storefront orders or file-delivery entitlements.
Let an agent pay your API
Install xrpl in the agent project. Use a separate funded Testnet payer wallet, keep its seed in AGENT_TESTNET_SEED, and set XRPL_RECIPIENT_ADDRESS to your API's receiving address.
Signing happens locally. The facilitator receives a signed transaction, never the wallet seed. Payment and total authorization limits are required. If the payment outcome is uncertain, reconcile the transaction and API result before authorizing another payment.
Deploy your own service
The example binds to localhost and uses Testnet. Serve the deployed API over HTTPS and set the middleware's resource to its public endpoint URL when needed behind a proxy. Keep your challenge secret stable. Switch to testnet: false with Mainnet wallets deliberately for real XRP payments.
For RLUSD, set currency: 'RLUSD' and the exact issuer address on the chosen network. Payer and recipient need matching trust lines. You can also supply your own XrplFacilitator instance through the middleware's facilitator option.
Public facilitator and optional merchant routes
GET /api/x402/supported returns supported mechanisms. POST /api/x402/verify checks a signed authorization without submitting it. POST /api/x402/settle deduplicates, submits, and waits for validated delivery. These public routes need no XRPay credentials.
The optional /api/v1/x402 merchant routes require an XRPay API key and bind terms to the configured merchant wallet and network. Existing merchants can use server-side facilitatorHeaders for that integration.