BlindPay

• Name: BlindPay
• URL: https://www.blindpay.com/
• Category: stablecoin-fiat corridor operator / payout control plane
• Tags: ethereum-ecosystem
• Summary: BlindPay at the project layer is the receiver, quote, wallet, virtual-account, webhook, and agent-integration surface inside a broader blindpay company shell. Keep this note on the product mechanics developers and operators integrate directly; the named operator boundary around corridor coverage, compliance review, credential issuance, payout exception handling, and lifecycle truth now lives in blindpay.
• What it does:
  • Provides APIs and dashboard workflows for stablecoin payins and fiat payouts built around receivers, quotes, transfers, wallets, and virtual accounts
  • Connects supported stablecoin networks to local banking rails and compliance checks
  • Exposes partner-fee, webhook, and API-key surfaces so integrators can run payout workflows from software rather than manual ops
  • Publishes MCP, CLI, and agent-facing surfaces, which makes the platform unusually explicit about machine-operated payments workflows
• Key claims:
  • Official docs position BlindPay as non-custodial global payments infrastructure rather than a wallet
  • The product surface is broad for a smaller vendor: payout and payin quotes, receivers, bank accounts, virtual accounts, blockchain wallets, partner fees, webhooks, and file upload
  • Failed settlements are described as refunding back to the originating wallet, which reinforces the model: BlindPay coordinates corridors and state, while final asset movement starts from user-controlled wallets
  • The first-party MCP server, skills index, and CLI show the company is intentionally packaging this stack for agentic and developer operation
• Whitepaper: No canonical standalone BlindPay whitepaper or litepaper surfaced in this pass. The clearest current source of truth is the official site, docs corpus, well-known agent endpoints, and first-party GitHub repos; see ../whitepapers/blindpay-primary-sources-2026-04-30.md.
• Sources:
  • https://www.blindpay.com/
  • https://www.blindpay.com/docs/getting-started/overview
  • https://www.blindpay.com/docs/getting-started/quick-start
  • https://www.blindpay.com/.well-known/mcp/server-card.json
  • https://www.blindpay.com/.well-known/agent-skills/index.json
  • https://www.blindpay.com/blog/mcp
  • https://www.blindpay.com/blog/cli
  • https://github.com/blindpaylabs/blindpay-cli
  • https://github.com/blindpaylabs/blindpay-skills

Internal linkages

• Company / operator boundary for corridor coverage, compliance review, credential issuance, refund handling, and lifecycle truth: blindpay.
• Best upward reads for this corridor-operator branch: bridge-xyz and coinflow where the sharper comparison is the company-run payout and settlement shell.

Protocol / company boundary

• Keep this note on the product surface: receivers, quotes, wallets, virtual accounts, bank-account objects, webhook mechanics, and the MCP / CLI / agent integration shape downstream teams wire into software.
• Use blindpay for the named operator boundary around corridor coverage, partner and receiver approval, compliance review, API-key issuance, payout exception handling, and the webhook-backed lifecycle truth integrators ultimately depend on.
• That split matters because what can BlindPay's API surface do? and which company decides whether those payout routes and callbacks are available and authoritative? are related but not identical questions.

Control surface

• At the product layer, practical power sits in receiver creation, quote construction, wallet and virtual-account wiring, webhook consumption, and how tightly the operator’s software binds itself to BlindPay-specific lifecycle objects.

• The thicker corridor-approval, compliance, and exception-handling shell now points upward to blindpay.

• Read BlindPay as productized corridor middleware rather than a general payments baseline.

• Last reviewed: 2026-08-10 UTC