FurlPay Docs
Open App
  • Services & Availability
  • Quickstart
  • For AI Agents
  • Monorepo
  • API Routes
  • Authenticationupdated
  • Webhook Eventsupdated
  • Error Codesupdated
  • Rate Limitsnew
  • Configuration & Setupnew
  • Merchant Paymentsnew
  • Payroll & Payoutsnew
  • Agentic Payments (x402)updated
  • Agent Trust & Mandates (TAP)updated
  • CCTP Cross-Chainupdated
  • LI.FI Swapsupdated
  • FurlPay Travels (Travel MCP)updated
  • Solana Actions & Blinks
  • Settlement Workspacenew
  • FURL Tokennew
  • Claude Connectorupdated
  • AI Assistants
  • Circlenew
  • Ramp Providersnew
  • Telegram Mini Appnew
  • Stripe Crypto
  • Persona KYC
  • Regulatory status
  • Screening & Casesnew
  • Security Postureupdated
  • Signing & WebAuthnupdated
  • Help Center
  • Getting Started
  • KYC Verification
  • Passkeys & Biometrics
  • Privacy & Data Protection
  • Transaction Statuses
  • Gasless Transfers
  • Deposits & Withdrawals
  • Managing Virtual Cards
  • Freezing & Unfreezing Cards
  • Declined Transactions
  • SDK & API Support
  • x402 Monetization Basics
  • Booking Travel
  • Travel Refunds & Cancellations

Resources

  • Changelog
  • System Status
  • OpenAPI Spec
  • Community
  • GitHub
Docs/Help Center/SDK & API Support

Help Center

SDK and API support

Use the SDK or API reference for its request contract, and check production availability separately for every payment rail.

Credentials do not enable a service

An SDK can construct a request to a route that is not configured for production. Check/api/rails before exposing a money-moving flow, and treat an unavailable status as a stop condition.

Developer packages

  • @furlpay/furlpay-node — Node.js / TypeScript server SDK.
  • @furlpay/gateway — self-hosted x402 gateway; choose a facilitator whose settlement is available.
  • @furlpay/mcp-server — MCP server for agent integrations; tool access depends on scopes.

Start here

  • Quickstart — rail status, fee estimates and payment-flow boundaries.
  • API Routes — route groups, authentication and availability handling.
  • Webhook Events — inbound provider webhooks and signature verification.
  • Error Codes and Rate Limits — error and retry behavior.

Common integration issues

  • Webhook signature failures — verify the provider-specific signature against the raw request body. Algorithms, timestamp checks and header names differ by provider.
  • 429 responses — respect Retry-After when present and apply bounded backoff rather than retrying in a tight loop.
  • Duplicate requests — use Idempotency-Key only on routes that document idempotency, and persist the key for the whole retry window.
  • Intent created but no payment — an intent is preparation data. Verify a confirmed settlement status and transaction reference before updating your order.

Getting help

Open a ticket in the developers category from the Support Center. Include the route, response status, request ID and timestamp. Do not include secret keys, session cookies, private keys, one-time codes or recovery phrases.

Report vulnerabilities separately

For a security issue, use the responsible disclosure process rather than a routine support ticket.
Did this page help?
Edit this page on GitHub

← Previous

Declined Transactions

Next →

x402 Monetization Basics