Developer quickstart

Start with a read-only rail check and fee quote. Then build against the route contract for the specific payment flow you need.

1. Check current rail status

The public rail registry lists protocols, assets, networks, limits and operational status. Check it before you integrate and again before you submit a payment:

curl --fail-with-body https://furlpay.com/api/rails

Continue only when the selected rail reports a usable status. If the endpoint returns an error or cannot provide fresh status, treat availability as unknown and stop the payment flow. A test or live API credential does not turn on an unconfigured rail.

2. Request a fee estimate

The fee-estimate endpoint is public and read-only. Its amount parameter is in USD, not minor units:

curl "https://furlpay.com/api/payments/fees/estimate?amount=150&sourceChain=arbitrum"

The response is an estimate, not a locked conversion quote or promise that a payment can settle. Recheck the fee and rail status immediately before presenting a payment to a user.

3. Build the payment flow

The authenticated POST /api/payments/create route validates the request and returns an intent with EIP-712 signing data. The connected user's wallet signs that data. It may return 503 service_unavailable when required production configuration is missing.

POST /api/payments/execute accepts the signature and attempts the next step. A successful HTTP response or a created intent by itself is not proof of an on-chain transfer. Poll the payment status and verify the returned transaction reference. Review authentication, schemas, status codes and idempotency in the API Routes reference.

Choose your integration

• x402 and MPP — HTTP payment challenges for metered API access; production settlement status is separate.
• Circle CCTP — build non-custodial cross-chain USDC transactions.
• LI.FI — quote routes and prepare wallet-signed swaps.
• Agent integrations — MCP, scoped access and spend controls.

Credentials and safety

• Keep secret credentials on your server; never embed them in browser code or a mobile bundle.
• Use the credential type and authentication method documented for each route.
• Use an Idempotency-Key where the route supports it so retries do not create duplicate intents.
• Verify webhook signatures over the raw request body before processing an event.
• Never treat a sandbox response, demo inventory or generated signing data as proof of a production payment.