How to integrate a stablecoin payouts API: a developer checklist (2026)

To integrate a stablecoin payouts API, follow eight steps: create a free development instance, authenticate with a bearer API key, onboard the recipient with KYC data, add a bank account, create a quote, execute the payout, listen to webhooks for every state change, and move to production. This page is the checklist, with the requests and tests.

It covers BlindPay's API as of October 2026. For the concept, start with what a stablecoin payouts API is and how a stablecoin payout works step by step. Older pages go deeper on single topics, and this one links them rather than repeating them. BlindPay publishes this post.

Key takeaways

• The flow is fixed: add a bank account once, create a quote that locks rate and fees for 5 minutes by default, then execute the payout.
• The payout request carries a quote_id and a sender_wallet_address, and one quote can back only one payout.
• Minimums by rail: SWIFT 100 USD, SEPA 50 USDC or 40 EUR, Faster Payments 70 USDC or 50 GBP, every other rail 10 USD sender amount.
• On development instances, a request_amount of 66600 forces failed and 77700 forces refunded.
• Build against webhooks, not polling, and verify the signature on every call.

What does the integration look like end to end?

One customer, one bank account, one quote and one payout per recipient payment. Everything else is state handling.

How to integrate a stablecoin API covers the wider build, including SDK choice. BlindPay ships SDKs for Node.js, Python, Go, PHP and Swift, plus an OpenAPI spec, all wrapping the same REST API described in the API reference.

How do you set up the environment and authenticate?

Create a development instance, generate an API key and send it as a bearer token. Keep it on your server.

Development and production expose the same endpoints, fields and response shapes, at the same hostname, https://api.blindpay.com. The instance your key belongs to decides the environment. Development instances are free, auto-approve customers and use the USDB test token on test networks. Sandbox vs production lists every difference. Production uses mainnet networks with USDC or USDT; check the supported chains page before you name a network.

Send mutating requests with an Idempotency-Key header so a network retry cannot create two payouts. The docs say a key is kept for 24 hours, and a retry only replays if the body matches byte for byte. Idempotency keys for stablecoin APIs has the pattern.

What KYC data do you send for the recipient?

The customer fields depend on type: individual or business. Create the customer, then wait for approved before you add a bank account or quote.

On production, KYC Standard is automated in about 60 seconds. KYC Enhanced (high-risk countries) and KYB Standard take 3 hours to 1 business day. Development instances auto-approve, so a name of Fail forces a rejection for testing. The KYC requirements list every field. The compliance side, including who owns what, is in stablecoin payout compliance.

How do you add a bank account and create a quote?

Add the bank account once per recipient, then create a quote for each payment.

Bank account fields depend on the rail, so fetch them at runtime from the public rails endpoint instead of hardcoding them. Third-party accounts are allowed, with recipient_relationship set to something other than first_party. Then create the quote against that bank account:

curl --request POST \
  --url https://api.blindpay.com/v1/instances/in_000000000000/quotes \
  --header 'Authorization: Bearer YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
  "bank_account_id": "ba_000000000000",
  "currency_type": "sender",
  "cover_fees": false,
  "request_amount": 10000,
  "network": "sepolia",
  "token": "USDB"
}'

request_amount is an integer in minor units, so 10000 is 100.00. currency_type says which side the amount is denominated in: sender is the stablecoin, receiver is the fiat. cover_fees: false takes fees out of the fiat received, and true adds them on top, which payroll teams usually want. The response returns sender_amount, receiver_amount, flat_fee, partner_fee_amount, commercial_quotation, blindpay_quotation and expires_at in epoch milliseconds. See payout quotes and pricing.

What does the payout request look like?

One POST with the quote_id and the funding wallet address. Check the field list in the payouts docs before you ship.

curl --request POST \
  --url https://api.blindpay.com/v1/instances/in_000000000000/payouts/evm \
  --header 'Authorization: Bearer YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
  "quote_id": "qu_000000000000",
  "sender_wallet_address": "YOUR_WALLET_ADDRESS"
}'

Payout creation is split by network: /payouts/evm for EVM and managed wallets, /payouts/stellar and /payouts/solana for those chains, each with its own request shape. The response returns a po_... ID with status processing, and sub-status objects tracking_transaction, tracking_payment, tracking_liquidity and tracking_complete. If you fund from an external wallet, authorize the exact amount on-chain first. A managed wallet needs no signing, but it is custodial: see custodial vs non-custodial payout APIs.

A quote_id can only back one payout, so a second call with the same quote returns an error. Create a new quote instead.

Which flavor of the docs should you read?

BlindPay's docs come in two flavors. Abstracted treats the stablecoin leg as plumbing and walks you through add account, quote, execute. Advanced exposes funding paths and on-chain authorization. Read Abstracted if you think in bank rails, and Advanced if you hold wallets. Abstracted vs advanced blockchain payment APIs explains the choice.

What are the minimums by rail?

Check them at quote time. The quote rejects amounts below the minimum, and you should surface that error rather than hardcode the number.

Payout times from the bank accounts docs: Pix, PIX Safe, SPEI, Transfers (Argentina) and RTP are instant, wire and TED and ACH COP and SEPA about 1 business day, ACH and SWIFT about 2 business days, and Faster Payments 5 to 30 minutes. The cut-off times reference says SWIFT settlement can take up to 5 business days. All SWIFT payouts start on_hold until compliance documents are submitted and approved. For international wires, BlindPay runs SWIFT payments and collections on behalf of (POBO/COBO), with UETR tracking and MT103 confirmations.

How should you handle webhooks and statuses?

Register an https endpoint on the instance, verify the signature on every call and treat payout.complete as the terminal signal.

Verify svix-id, svix-timestamp and svix-signature against the raw body with HMAC-SHA256 and reject timestamps outside a 5 minute tolerance. The verification docs have the code. For local testing, webhook.cool gives a temporary URL that logs each request. Webhooks and reconciliation and payout statuses explained cover the handler design.

What is the go-live checklist?

Walk this list on the day you switch to production.

1. Quote expiry. Read expires_at and requote after 5 minutes (shorter on SEPA and Faster Payments). See handling expired quotes.
2. Minimums. Surface the rail's minimum error to the user instead of failing silently.
3. Webhook verification. Verify signatures, check the timestamp, deduplicate on svix-id, and allowlist the documented source IPs only as an extra layer.
4. Retries. Send an Idempotency-Key on every mutating call and retry only on network errors and 5xx.
5. Refund scenarios. Know your refund wallet, and know that a failed payout is not refunded automatically: contact support@blindpay.com.
6. Holds. Holds can take up to 30 days, and a timeout fails the payout. Tell recipients what on_hold means.
7. Reconciliation. Store the quote ID, payout ID and fee fields against each ledger entry.
8. Production credentials. New production API key, mainnet networks, USDC or USDT, and a small first payout.

What is the 12-item pre-launch test plan?

Run all twelve on a development instance and record the result. Expected outcomes come from the docs.

What shortcuts exist for AI agents and the terminal?

The hosted MCP server and the CLI let you try the flow without writing code first. BlindPay describes itself as the most AI-native stablecoin infrastructure.

The hosted MCP server at https://mcp.blindpay.com/mcp signs in over OAuth and lets an agent quote and track payouts, with a read-only variant at https://mcp.blindpay.com/mcp/readonly. Tools carry read-only and destructive annotations, but the server does not block a call by itself, so keep a human confirmation step. The CLI (@blindpay/cli) supports --json, blindpay schema and predictable exit codes (CLI post). Read the MCP docs and the Model Context Protocol site.

Methodology and sources

External sources: the BlindPay API reference, the OpenAPI spec, the Model Context Protocol site and webhook.cool. BlindPay facts come from the payouts, payout quotes, bank accounts, KYC, cut-off times, webhooks, idempotency, sandbox vs production, SDKs and MCP docs, checked in October 2026.

What to do next

Start in the development instance: create a customer, add a bank account, quote and execute a payout, then run the 12 tests above. The payout quickstart walks the whole flow with copyable requests.