BlindPay

• Name: BlindPay
• URL: https://www.blindpay.com/
• Category: stablecoin-fiat corridor company / payout-operations operator / compliance-and-webhook workflow shell
• Tags: ethereum-ecosystem
• Summary: BlindPay belongs in companies/ because the durable dependency is not only what API endpoints exist? but which named operator decides corridor coverage, approves receivers and partners, issues API keys, runs compliance checks, publishes webhook truth, and defines refund and settlement handling across stablecoin-to-fiat flows? blindpay stays the product-layer note for receivers, quotes, wallets, virtual accounts, and agent-facing integration mechanics. This note is for the company boundary where corridor policy, compliance review, machine-facing access, and payout-state publication live together.
• What it does:
  • Runs a company-managed stablecoin payin and fiat payout stack built around receivers, quotes, transfers, wallets, bank accounts, virtual accounts, partner fees, and webhooks
  • Controls which payout corridors, banking integrations, and settlement paths are exposed to developers and agent operators through the API and dashboard
  • Issues API keys and packages MCP, CLI, and agent-facing tooling so integrators can operate BlindPay’s payment workflows from software rather than manual backoffice steps
  • Applies compliance review and payout handling inside the same operating shell that creates receivers, prices quotes, and determines whether transfers complete or refund
  • Publishes transaction and webhook state that downstream integrators treat as operational truth for payout success, failure, or refund handling
• Key claims:
  • The docs position BlindPay as non-custodial global payments infrastructure, but the product materials still show a single named operator packaging corridors, compliance, wallets, virtual accounts, webhooks, and partner-fee logic into one live service boundary
  • The quick-start and overview docs expose a broad operating surface — receivers, quotes, transfers, bank accounts, virtual accounts, blockchain wallets, partner fees, and webhooks — which is wider than a neutral settlement primitive and strongly suggests company-shaped workflow control
  • The docs say failed settlements are refunded back to the originating wallet, which is analytically important because it shows BlindPay controls not just initiation but also exception handling and downstream operational truth when a payout does not complete
  • The public MCP server card, agent-skills index, and CLI posts show BlindPay intentionally packaging its payment stack for automated and agentic operation, which increases the importance of company-controlled credentials, rate limits, webhook semantics, and service behavior
  • The strongest control-surface question here is not protocol design; it is who decides corridor availability, onboarding posture, compliance gating, payout review, and what counts as the authoritative lifecycle state for software built on top of BlindPay
• Whitepaper: No standalone company whitepaper is the point here. The clearest primary materials are BlindPay’s official site, docs corpus, agent endpoints, and first-party tooling repos already collected in ../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
  • ../whitepapers/blindpay-primary-sources-2026-04-30.md

Internal linkages

• Product-layer note: blindpay.
• Useful adjacent company reads: bridge-xyz, coinflow, bvnk, and openpayd.
• Reusable lens: corridor vendors often need a separate company cut when quote construction, receiver approval, compliance gating, and webhook truth live behind one named operator.

Protocol / company boundary

• Keep blindpay focused on the product surface: receivers, quotes, wallets, virtual accounts, bank-account objects, webhook and API mechanics, and the agent / MCP / CLI integration shape developers actually touch.
• Keep this note focused on the company boundary above that surface: corridor coverage, partner and receiver approval, compliance review, credential issuance, payout exception handling, refund behavior, and the published lifecycle truth software depends on.
• That split matters because how do BlindPay's APIs and agent surfaces work? and which company controls whether those payout corridors, reviews, and callbacks are live and trustworthy? are related but not identical questions.

Control surface

• Practical authority sits in corridor coverage, quote construction, receiver and partner approval, compliance review, API-key and agent-tooling access, payout exception handling, refund policy, and webhook publication.

• Non-custodial does not remove operator leverage here. It mostly relocates it into routing, onboarding, review, and state-publication authority.

• Read BlindPay as a company-operated corridor and payout-control shell, not as a neutral payment rail.

• Last reviewed: 2026-08-10 UTC