Removed tools

GetV1EPayoutsById, GetV1EPayinsById and GetV1ETransfersById wrapped the /v1/e/ endpoints behind BlindPay's shareable tracking pages. Those endpoints only answer requests from the tracking pages themselves, so a call from an MCP client always failed. Use the authenticated tools instead, which return the same payout, payin or transfer:

MCP clients pick up the change on their next tools/list.

Better descriptions

GetV1AvailableRails and GetV1AvailableBankDetails now describe what they return and how they fit together: list the rails first, then pass a rail's value to bank details to get the fields, validation patterns and picklists a bank account needs for that rail.

What's new

Three read-only endpoints under /v1/instances/{instance_id}/onboarding/ are now part of the public reference and the SDK:

• GET .../business_details: legal name, tax ID, entity type, state of incorporation, formation date, trading names and registered address.
• GET .../business_profile: industry, website, business scenario and expected volume.
• GET .../ownership_documents: owners and ownership documents.

They authenticate with your regular instance API key. Use them to keep the records you hold about your own instance in sync with what BlindPay has on file. Updating this information still happens through the dashboard.

TL;DR

• Yield (private beta): turn it on for a managed wallet and the idle USDC balance starts earning
• ACH pull (private beta): customers connect their bank account once and payins pull the funds, no manual transfer
• Tempo and Arc: two new networks for wallets, payins, payouts and transfers
• Prompt library: ready-to-paste prompts that build a full BlindPay integration with your AI coding agent

Yield (private beta)

Managed wallets can now earn on the stablecoins they hold. Turn yield on once per wallet and BlindPay moves the idle USDC into a lending vault, keeps it earning, and pulls it back automatically whenever a payout or transfer needs the funds. Turn it off and the full position returns to the wallet. There is no fee on the balance, only a performance fee on gains, and the APY we report is already net of it.

Yield is in private beta. Reach out to your BlindPay contact to enable it on your instance. Read the Yield guide.

ACH pull (private beta)

Payins in the US no longer depend on the customer sending a transfer. The customer connects their bank account once through a hosted page, and from then on a payin with the new ach_pull payment method debits that account directly. Connected accounts are verified as first party before they can be used.

ACH pull is in private beta. Reach out to your BlindPay contact to enable it on your instance. Read the bank accounts guide.

Tempo and Arc networks

Tempo and Arc are live for managed wallets, offramp wallets, payins, payouts and transfers. Tempo supports USDC.e and USDT0, Arc supports USDC. Both have a matching testnet on development instances. See the supported networks.

Prompt library

We published a library of prompts that walk an AI coding agent through a complete BlindPay integration, from a payin or payout quickstart to payables and wallets, with the API gotchas already encoded. Copy one into your agent and let it build. Browse the prompts.

TL;DR

• Payables: pay invoices, boletos, PIX copia e cola codes, utility bills and tax slips from USDC or USDT
• Cross-chain USDC transfers: move USDC between supported networks in a single transfer
• Virtual account upgrades: partner fees per account, and deposits of any size are processed

Payables: pay invoices and bills from stablecoins

Payables is a new product to pay the bills your business owes directly from stablecoins. Upload an invoice, a boleto, a PIX copia e cola code, a utility bill or a tax slip, and BlindPay figures out the amount, the beneficiary and the due date, then pays it through the right rail. Available today in the dashboard and the API. Read the Payables guide.

Cross-chain USDC transfers

You can now move native USDC between networks in a single transfer. Send from a wallet on one network, deliver to a wallet on another. Check out the Transfers guide.

Virtual account upgrades

You can now set a different partner fee on each virtual account with the new partner_fee_id field, and deposits of any size are processed, including $0.01 verification micro-deposits. Read the full details.

TL;DR

• New partner_fee_id field on virtual account create and update: pin a partner fee to one account, overriding the instance-wide default
• Every deposit now creates a payin, including $0.01 account-verification micro-deposits; at least $0.01 always reaches the linked wallet
• BlindPay fees on deposits below $100.00 accrue to your monthly invoice (billing_fee_amount); deposits of $100.00 and above are charged at transaction time (transaction_fee_amount)

Partner fees per virtual account

Until now, virtual accounts supported a single partner fee for the entire instance: one fee configuration flagged for virtual accounts applied to every account's deposits. You can now pin a fee to each account individually.

Pass partner_fee_id when creating a virtual account, or set it later with the update endpoint:

curl --request POST \
  --url https://api.blindpay.com/v1/instances/in_000000000000/customers/re_000000000000/virtual-accounts \
  --header 'Authorization: Bearer YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "banking_partner": "cfsb",
    "token": "USDC",
    "blockchain_wallet_id": "bw_000000000000",
    "partner_fee_id": "pf_000000000000"
  }'

How the two levels interact:

• A fee pinned to an account overrides the instance-wide default for that account's deposits.
• Accounts without a pin keep using the instance-wide default (the fee configuration created with virtual_account_set: true), so existing setups keep working unchanged.
• Updating an account with partner_fee_id: null clears the pin and falls back to the default.
• Deleting a fee configuration automatically unpins it from any accounts referencing it; those accounts revert to the default.

The dashboard's virtual account create dialog and edit pane both gained a partner fee selector.

Micro-deposits are now collected

Deposits below $5.00 into a virtual account used to be ignored. Every deposit of any size now creates a payin, including the $0.01 account-verification micro-deposits sent by services like Plaid and Square, and always delivers at least $0.01 of stablecoin to the linked wallet.

Because fees can exceed a small deposit, partner fee collection is now partial rather than all-or-nothing: the fee collects as much as the deposit can bear while preserving the $0.01 delivery floor. A $5.00 fee on a $5.00 deposit collects $4.99; a micro-deposit collects nothing.

When BlindPay fees are charged

BlindPay fees on virtual account deposits now follow an amount-based rule:

This keeps small deposits from being consumed by fees at transaction time while charging larger deposits immediately. Instances configured for end-of-month billing keep accruing every fee to billing_fee_amount, regardless of amount.

What you need to do

Nothing is required. Existing virtual accounts keep their behavior: the instance-wide partner fee still applies to accounts without a pin, and fee totals are unchanged, only the timing of when small-deposit fees are charged moves to the monthly invoice. If you reconcile payins, read both billing_fee_amount and transaction_fee_amount rather than assuming one of them.

To adopt per-account fees, create additional fee configurations and pass partner_fee_id on virtual account create or update.

Learn more

• Virtual accounts guide: fee rules, account types, and statuses
• Partner fees guide: defaults vs. per-account pins for virtual accounts, and quotes
• Create a virtual account: full request reference

Timing: the renames below are not live yet. They ship with the final release, which will be announced on this changelog. Until then, the receiver_* request fields remain the accepted shape on the current API (sending customer_* request fields today is rejected). Use this guide, and the AI prompt at the end, to prepare your migration diff now, and deploy it when the release goes live.

Endpoints

Every legacy /receivers path now returns 301 Moved Permanently pointing at its /customers equivalent.

This covers the customer collection and item routes plus every sub-resource: bank accounts, wallets, blockchain wallets, virtual accounts, offramp wallets, limits, limit increases, and RFIs. The /e/ external invite-flow variants redirect too.

Note that external-receiver-token is renamed even though it has no /receivers/ path segment.

Webhooks

receiver.new, receiver.update, and receiver.delete no longer fire. Subscribe to customer.new, customer.update, and customer.delete instead; they carry the same payloads. The dual-emit behavior from the transition window is gone, so you now receive exactly one event per action.

Renamed fields

The one field that keeps its name

receiver_amount is not renamed. It stays receiver_amount on quotes, payins, payouts, and transfers, because there it means "the amount the receiving side gets", a leg of the transaction rather than a reference to the customer resource.

Do not confuse it with receivers_amount (plural), which is renamed to customers_amount. That one is the customer count on an instance.

This is the single reason a blind find-and-replace of receiver to customer will break your integration.

Renamed error codes

The code field on error responses is a stable identifier meant for programmatic handling, and eleven of them changed prefix.

Renamed error messages

The legacy message slug also changed on the errors below. If you branch on message rather than code, update both.

Two message slugs are deliberately unchanged, because they describe the receiving leg of a transaction rather than the customer resource: otc_only_supported_for_sender_without_cover_fees_and_receiver_with_cover_fees, and every slug involving receiver_amount. The currency_type request enum also keeps its sender and receiver values.

Deprecation headers are gone

/receivers responses no longer carry Deprecation: true, Sunset, or Link: rel="successor-version". If you set up the CI smoke test suggested in the June changelog, it now passes trivially instead of catching anything. Replace it with a check that asserts no 301 responses from BlindPay.

IDs are unchanged

Customer IDs keep the re_ prefix, and customer records keep both id and its canonical alias customer_id. No data migration is needed. Do not rewrite stored IDs.

Migrate your code with an AI agent

If you use an AI coding agent (Claude Code, Codex, Cursor, Windsurf, or similar), paste the prompt below into it from the root of your integration. It contains every rename from this changelog and the June announcement, including the exceptions that make a naive find-and-replace unsafe.

Migrate this codebase off the deprecated BlindPay "receivers" API surface and onto
"customers". This is a rename of the API surface only: resource IDs are unchanged.

Work through the steps in order and show me a diff before applying anything.

STEP 1 - Find every call site.
Search the whole repo (including tests, fixtures, recorded HTTP cassettes, env
files, OpenAPI/Postman collections, infrastructure config, and docs) for:
  receivers, receiver_, receiverId, RECEIVERS_, "receiver." (webhook event names)

STEP 2 - Rewrite URL paths.
  /v1/instances/{id}/receivers               -> /v1/instances/{id}/customers
  /v1/e/instances/{id}/receivers             -> /v1/e/instances/{id}/customers
  /v1/instances/{id}/limits/receivers/{rid}  -> /v1/instances/{id}/limits/customers/{rid}
  /v1/instances/{id}/external-receiver-token -> /v1/instances/{id}/external-customer-token
Apply to all sub-resources as well: bank-accounts, wallets, blockchain-wallets,
virtual-accounts, offramp-wallets, limit-increase, rfi.
The old paths still answer 301, so nothing breaks immediately, but every call
costs an extra round-trip until this is done.

STEP 3 - Rename request and response fields.
  receiver_id                      -> customer_id
  receiver_name                    -> customer_name
  receiver_local_amount            -> customer_local_amount
  receiver_wallet_address          -> customer_wallet_address
  receiver_network                 -> customer_network
  receiver_token                   -> customer_token
  receiver_invite_redirect_url     -> customer_invite_redirect_url
  receiver_rfi_emails_enabled      -> customer_rfi_emails_enabled
  receivers_amount                 -> customers_amount
  receiver_type                    -> customer_type
  receiver_kyc_status              -> customer_kyc_status
  receiver_aiprise_session_id      -> customer_aiprise_session_id
  receiver_aiprise_user_profile_id -> customer_aiprise_user_profile_id

STEP 4 - CRITICAL EXCEPTION. Do NOT rename receiver_amount.
receiver_amount (singular) is still called receiver_amount on quotes, payins,
payouts, and transfers. It means "amount the receiving side gets", not a
reference to the customer resource. Renaming it will break those calls.
Note the near-miss: receivers_amount (plural, the customer count on
GET /v1/instances) IS renamed to customers_amount. Handle each explicitly.
Never run a blanket s/receiver/customer/ over this repo.

STEP 5 - Rename webhook event names and handlers.
  receiver.new    -> customer.new
  receiver.update -> customer.update
  receiver.delete -> customer.delete
Payloads are identical. Also update the subscription list in the BlindPay
dashboard; a code-only change will leave your endpoint silent.
The old dual-emit is gone, so if a handler was de-duplicating receiver.* against
customer.* for the same action, that workaround can be removed.

STEP 6 - Rename error codes checked in code.
Any comparison against the code field on an error response:
  RECEIVERS_NOT_FOUND -> CUSTOMERS_NOT_FOUND, and the same CUSTOMERS_ prefix
  swap for ALREADY_APPROVED, KYC_NOT_APPROVED, ONBOARDING_INCOMPLETE,
  INVALID_DATA, INVALID_PHONE, INVALID_TAX_ID, ID_DOCUMENT_INVALID,
  COUNTRY_NOT_SUPPORTED, ENHANCED_KYC_REQUIRED,
  BUSINESS_ENHANCED_NOT_AVAILABLE.

STEP 6b - Rename error message slugs checked in code.
If you branch on the message field instead of code, these changed too:
  receiver_not_found            -> customer_not_found
  receiver_id_not_found         -> customer_id_not_found
  receiver_already_approved     -> customer_already_approved
  receiver_kyc_not_approved     -> customer_kyc_not_approved
  receiver_not_approved         -> customer_not_approved
  receiver_limit_not_found      -> customer_limit_not_found
  receiver_already_has_limit_increase_in_review
    -> customer_already_has_limit_increase_in_review
  vm_invalid_receiver_data      -> vm_invalid_customer_data
  vm_receiver_country_not_supported -> vm_customer_country_not_supported
  vm_unsupported_receiver_type  -> vm_unsupported_customer_type
  zenus_business_va_requires_business_receiver
    -> zenus_business_va_requires_business_customer
  beneficiary_name_must_match_receiver_for_first_party
    -> beneficiary_name_must_match_customer_for_first_party
  blockchain_wallet_does_not_belong_to_receiver
    -> blockchain_wallet_does_not_belong_to_customer
  sender_and_receiver_networks_must_be_the_same
    -> sender_and_customer_networks_must_be_the_same
  sender_and_receiver_tokens_must_be_the_same
    -> sender_and_customer_tokens_must_be_the_same
Leave unchanged: any slug mentioning receiver_amount, and
otc_only_supported_for_sender_without_cover_fees_and_receiver_with_cover_fees.

STEP 6c - Do NOT change the currency_type request value.
currency_type still accepts 'sender' and 'receiver'. Sending 'customer' is
invalid. This pairs with the receiver_amount exception in step 4.

STEP 7 - Update the SDK accessor, if you use an official SDK.
  blindpay.receivers.*  ->  blindpay.customers.*
  blindpay.receivers.bankAccounts.create(...)
    ->  blindpay.customers.bankAccounts.create(...)
Method signatures are identical; only the accessor renames. Bump to the latest
release of your current major, which added customers with no import changes.

STEP 8 - Do NOT touch stored IDs.
Customer IDs keep the re_ prefix (re_abc123456789). Leave every stored ID,
fixture, and database value exactly as it is. There is no data migration.

STEP 9 - Verify.
  - grep the repo: no receivers, receiver_id, or receiver.* webhook names left
  - confirm receiver_amount is still present and untouched wherever it was before
  - run the test suite, and update fixtures or cassettes that assert on renamed
    fields
  - check logs for 301 responses from api.blindpay.com; each one is a path you
    missed

Report anything ambiguous rather than guessing.

What you need to do

1. Update API paths from /receivers to /customers, including the /e/ invite-flow variants and external-customer-token.
2. Rename request and response fields per the table above, leaving receiver_amount alone.
3. Update error handling: code comparisons from RECEIVERS_* to CUSTOMERS_*, and message comparisons from receiver_* to customer_*.
4. Subscribe to customer.* webhooks in the dashboard and update your handlers.
5. Update your SDK to the latest release of its current major, then switch receivers.* calls to customers.*.
6. Leave stored IDs untouched. The re_ prefix is permanent.

If you completed the migration before July 3, 2026, the only new work is step 3, the error code and message renames, which ship with this release.

Verification checklist

• Logs show zero 301 responses from api.blindpay.com, since each one is an unmigrated path
• Logs show zero requests to /v1/instances/*/receivers* and /v1/e/instances/*/receivers*
• No code path reads response.receiver_id or any other renamed field
• receiver_amount is still read correctly on quotes, payins, payouts, and transfers
• No code path compares an error code against a RECEIVERS_* value, or an error message against a receiver_* slug
• Requests still send currency_type: 'receiver', not 'customer'
• Webhook handlers process customer.new, customer.update, and customer.delete, and the dashboard subscription lists them
• SDK updated, with no remaining receivers.* accessor calls
• Saved dashboard URLs use /customers/

FAQ

What breaks if I do nothing?

Requests keep working through the 301 redirects, at the cost of an extra round-trip per call, as long as your HTTP client follows redirects (browsers, curl, requests, axios, the official SDKs, and Postman all do by default). Three things break outright: receiver.* webhook subscriptions go silent, code that reads a renamed receiver_* response field gets undefined, and error handling that branches on a RECEIVERS_* code or a receiver_* message stops matching.

Do I need to migrate my stored IDs?

No. All IDs keep the re_ prefix, and both id and customer_id carry the same value. We renamed the API surface, not the underlying resource.

Why does receiver_amount keep its name?

Because it does not refer to the customer resource. On a quote or a payment it means the amount landing on the receiving side, the counterpart to sender_amount. Renaming it to customer_amount would have made it read like a property of the customer record.

Will a find-and-replace work?

Not safely. receiver_amount must survive untouched while receivers_amount must change, and stored re_ IDs must not be rewritten. Use the agent prompt above, which encodes those exceptions, or do the renames field by field.

How do I report issues with the migration?

Use the feedback button in the dashboard (under your profile dropdown) or email support@blindpay.com with migration in the subject. Including the request ID from the response (x-blindpay-request-id header) speeds up the lookup.

TL;DR

• Public error codes: every API error now returns a stable code and a safe-to-display description
• New documentation: rebuilt navigation, REST-only quickstarts, and a self-hosted API reference
• AI in the docs: an assistant that knows our entire API and answers instantly
• Idempotency keys: opt-in Idempotency-Key header on all mutating v1 endpoints

Public error codes

Every API error response now includes two additive fields: code, a stable identifier like PAYOUTS_INSUFFICIENT_BALANCE, and description, human-readable text safe to show your end users. Existing responses are unchanged, so nothing breaks.

Each code is documented with its retry semantics, so your integration knows whether to retry, stop, or ask the user to act. Browse the full list in the API reference{target="_blank"}.

New documentation

We rebuilt blindpay.com/docs from the ground up. Navigation is organized around what you are doing (Payins, Payouts, Send, Receive, Store), and every quickstart is REST-only with managed wallets, so you can integrate without touching blockchain tooling.

The API reference now lives at blindpay.com/docs/api/reference{target="_blank"} with one URL per endpoint. All old URLs redirect.

AI in the docs

The docs now answer back. An AI assistant trained on our entire documentation and API reference is built into every page: ask "how do I create a payout quote" or paste an error code, and it gives you a direct answer with working request examples, no page hunting.

It is the fastest way to integrate BlindPay. Most questions that used to become support tickets now get answered in seconds, right where you are working.

And this is just the start: the same AI is coming to the dashboard next, where you will be able to run your entire operation by simply asking in plain language.

Idempotency keys

Mutating v1 endpoints now accept an optional Idempotency-Key header. Retry with the same key and you get the original response back instead of a duplicate action, making timeouts and retries safe on payment-creating calls.

TL;DR

• New endpoints: GET /v1/instances/{instance_id}/rfi and POST /v1/instances/{instance_id}/rfi
• Same section and field format as customer RFIs
• Standalone by design: no status changes, no blocked payments, ever
• If the 27-day window passes, the request simply expires and compliance follows up directly
• Email cadence to all instance members at day 0, 7, and 17, plus an expiry notice

How it works

When compliance opens an instance RFI, every active member of your instance receives an email and the request appears under Settings → Instance in the dashboard. Fetch it with GET /v1/instances/{instance_id}/rfi, collect the requested fields, and submit them in a single shot with POST /v1/instances/{instance_id}/rfi.

Unlike customer RFIs, an instance RFI never touches your onboarding or KYB status and never blocks payins or payouts. See the Instance RFI documentation and the Instance RFIs guide for details.

TL;DR

• New endpoint: POST /v1/upload/analyze
• Returns approval_rate of low, medium, or high plus a one-line description
• Supports 13 document types, from identity and passport to bank and financial statements
• Optional metadata cross-checks values you already collected against the document

How it works

Send a file (PDF, JPG, or PNG up to 5MB) and a type. The analysis runs the document against the rule set for that type and returns how confident it is that the document should be approved, with a short reason you can show to the customer or your reviewers.

The result is a signal, not a decision. KYC approval still comes from the verification flow; this lets you catch an expired ID or an out-of-date proof of address early, before submitting.

Optional metadata

Pass metadata as a JSON string of values you already have, such as full_name, date_of_birth, or address, and they are matched against the document. A clear mismatch caps the rating at low and the reason explains it. Requested transaction limits (requested_per_transaction, requested_daily, requested_monthly) are checked for sufficient capacity instead of an exact match.

Get started

See the Analyze Document documentation. The full request and response schema is in the BlindPay API Docs{target="_blank"}.

TL;DR

• USDC for SEPA is now accepted on Polygon, Ethereum, Arbitrum, Base, Solana, and Stellar
• Quotes can be requested by the EUR amount the receiver should get, minimum 10 EUR. The existing USDC-amount mode is unchanged, minimum 11 USDC
• SEPA bank accounts can be paired with offramp wallets on any of the supported deposit chains

Multi-chain deposits

When you create a SEPA payout the USDC can come from any of these chains: Polygon, Ethereum, Arbitrum, Base, Solana, and Stellar. Settlement to the receiver's IBAN is unaffected, funds arrive within 5 to 30 minutes regardless of the source chain.

Native USDC only on each chain. Tron is not supported for SEPA.

Quote by EUR amount

Until now, every SEPA quote took a USDC amount and returned the EUR the receiver would get. You can now do the reverse: specify the EUR amount the receiver should receive and we calculate the USDC you need to send.

The mode is selected on the quote request via currency_type:

• currency_type: "sender" for the USDC-amount path. Minimum 11 USDC.
• currency_type: "receiver" for the EUR-amount path. Minimum 10 EUR.

Offramp wallets

SEPA bank accounts can now be linked to offramp wallets on Polygon, Ethereum, Arbitrum, Base, and Solana. Funds sent to the offramp wallet are converted to EUR and settled to the linked IBAN automatically, with the same 5 to 30 minute window. Tron offramp wallets cannot be paired with SEPA bank accounts.

See the offramp wallets documentation to get started.

Get started

These updates are live for every account that already has SEPA enabled. Existing SEPA bank accounts work with all the new chains and the EUR-amount quote mode without any reconfiguration.

TL;DR

• All /receivers endpoints now have /customers equivalents
• Both /receivers and /customers paths work identically through July 3, 2026
• After that date, /receivers endpoints return 301 Moved Permanently
• IDs stay the same (re_ prefix), no data migration needed
• SDKs add a customers accessor to their current majors and receivers is deprecated alongside, no import changes required

What changed

Every API endpoint that previously used /receivers in its path now has a /customers equivalent:

GET    /v1/instances/{instance_id}/receivers                →  GET    /v1/instances/{instance_id}/customers
POST   /v1/instances/{instance_id}/receivers                →  POST   /v1/instances/{instance_id}/customers
GET    /v1/instances/{instance_id}/receivers/{receiver_id}  →  GET    /v1/instances/{instance_id}/customers/{customer_id}
PUT    /v1/instances/{instance_id}/receivers/{receiver_id}  →  PUT    /v1/instances/{instance_id}/customers/{customer_id}
DELETE /v1/instances/{instance_id}/receivers/{receiver_id}  →  DELETE /v1/instances/{instance_id}/customers/{customer_id}

This applies to all sub-resources too: bank accounts, wallets, virtual accounts, blockchain wallets, offramp wallets, and limit increases.

Response changes

During the transition period, every customer record returned by either /customers or /receivers carries a customer_id alias of its primary key. The underlying ID still uses the re_ prefix and remains in the id field:

{
  "id": "re_abc123456789",
  "customer_id": "re_abc123456789",
  "first_name": "Alice"
}

Payouts and payins that reference a customer expose both receiver_id and customer_id foreign-key fields during the transition; either accepts the same re_* value. Sub-resources scoped under /customers/{id}/… (bank accounts, wallets, virtual accounts, blockchain wallets, offramp wallets) derive the parent from the URL, so no FK alias appears in the response body.

After the sunset, the customer_id alias becomes the canonical field name across the API.

Webhook changes

Three new webhook events fire alongside the existing ones:

• customer.new: fires whenever receiver.new fires
• customer.update: fires whenever receiver.update fires
• customer.delete: fires whenever receiver.delete fires

You must subscribe to customer.* before July 3, 2026. After the sunset, receiver.* events stop firing entirely. If you don't migrate, your endpoint goes silent.

During the transition window (June 4 → July 3), every create and update emits both events: the legacy receiver.* and its customer.* counterpart. If your endpoint is subscribed to both, your handler receives the same action twice. We intentionally dual-emit so you can migrate your handlers in any order, but make sure your processing is idempotent on the resource id, or drop the receiver.* subscription once customer.* is wired up.

SDK updates

No import path changes during the transition. Just update to the latest version of your current major and the customers accessor is there. For Node, Python, PHP, and Swift, a future major release (after sunset) removes the deprecated receivers surface; that's when imports change in those SDKs.

Go is treated differently. receivers stays as a thin deprecated forwarder in v1 indefinitely. gopls, staticcheck SA1019, and godoc will flag usage; nothing breaks.

Method signatures are unchanged. Only the resource accessor renames. For most projects this is a single find/replace. Example in Node.js SDK:

- await blindpay.receivers.list()
+ await blindpay.customers.list()

- await blindpay.receivers.bankAccounts.create({ ... })
+ await blindpay.customers.bankAccounts.create({ ... })

What you need to do

1. Update your API calls to use /customers instead of /receivers
2. Update field references from receiver_id to customer_id in your code
3. Update webhook subscriptions to use customer.new, customer.update, and customer.delete
4. Update your SDK to the latest version of its current major. The customers accessor is added there, no import changes required

Timeline

• June 4, 2026: /customers endpoints live. Both /receivers and /customers accept requests. Receiver responses include Deprecation: true and Sunset: Fri, 03 Jul 2026 00:00:00 GMT headers, plus a Link: rel="successor-version" pointing to the customer equivalent.
• July 3, 2026: Sunset date. /receivers endpoints return 301 Moved Permanently redirecting to /customers. SDK code calling receivers.* continues to work via the redirect.
• Later: /receivers endpoints removed entirely. New SDK majors ship for Node (v4), Python (v2), PHP (v2), and Swift (v2), dropping the deprecated receivers surface. The Go SDK keeps receivers as a deprecated forwarder in v1; no v2 planned for this rename. Previous SDK majors enter maintenance mode (security fixes only).

Detect deprecation programmatically

Every /receivers response carries deprecation metadata you can monitor in tests or runtime logs:

HTTP/1.1 200 OK
Deprecation: true
Sunset: Fri, 03 Jul 2026 00:00:00 GMT
Link: </v1/instances/{instance_id}/customers>; rel="successor-version"
Content-Type: application/json

Useful in CI: fail a smoke test if production traffic still hits Deprecation: true endpoints close to the sunset date.

Verification checklist

Before considering your migration complete:

• Logs show zero requests to /v1/instances/*/receivers* paths from your services
• CI / monitoring asserts no Deprecation: true header on production responses
• Webhook handlers process customer.new, customer.update, and customer.delete
• No code paths reference response.receiver_id
• SDK updated to the latest minor release of its current major
• Saved dashboard URLs use /customers/

FAQ

What if I don't migrate before July 3, 2026?

/receivers paths return 301 Moved Permanently pointing to the equivalent /customers URL. Most HTTP clients (browsers, curl, requests, axios, official SDKs, Postman) follow redirects automatically, so traffic keeps working, but you spend an extra round-trip per call and rely on redirect semantics. Migrate before that date.

Can I migrate one resource group at a time?

Yes. The customer mirrors are independent per resource group (customers, bank accounts, wallets, virtual accounts, etc.). You can switch your customer-creation flow over this week and your bank-account-creation flow next week without coordination. Each endpoint accepts the new path independently.

Will I get duplicate webhook events during the transition?

Yes, every create and update emits both receiver.* and customer.* if you are subscribed to both. We dual-emit so you can migrate handlers in any order. Subscribe to one set or the other to avoid handling the same event twice.

Do I need to migrate my stored IDs?

No. All IDs keep the re_ prefix. The same ID works with both /receivers and /customers endpoints. We are renaming the API surface, not the underlying resource.

How do I report issues with the migration?

Use the feedback button in the dashboard (under your profile dropdown) or email support@blindpay.com with migration in the subject. Including the request ID from a deprecated response (x-blindpay-request-id header) speeds up the lookup.

TL;DR

• Send USDC and pay receivers in EUR across 40 SEPA-zone countries
• USDC on Polygon or Ethereum
• Minimum payout: 11 USDC
• Per-payout maximum: $100,000 when the receiver is an individual, $300,000 when the receiver is a business
• Settlement in 5 to 30 minutes after we receive your USDC
• Supports B2B, B2C, C2B, and C2C use cases. 7 countries are C2C-only (see below)
• Same payout API as every other rail. Create a SEPA bank account, request a quote, execute the payout

How it works

The flow is identical to your existing payouts:

1. Create a bank account with type: "sepa", the receiver's IBAN, BIC, full name, and address. The country of the IBAN determines which use cases are available (see the C2C-only list below).
2. Request a quote for the USDC amount you want to send. We return the EUR your receiver will get.
3. Execute the payout. EUR settles to the receiver's IBAN within 5 to 30 minutes after we receive your USDC.

Rules

• Minimum: 11 USDC per payout.
• Per-payout maximum: $100,000 when the receiver is an individual (B2C, C2C) and $300,000 when the receiver is a business (B2B, C2B).
• No fixed EUR amounts: quotes take a USDC amount and return the EUR your receiver gets.
• Networks: USDC on Polygon or Ethereum mainnet. Native USDC only.
• Receiver country: must be one of the 40 SEPA-zone countries listed below.

Supported countries

All 40 countries below support B2B, B2C, C2B, and C2C use cases unless flagged:

Andorra (AD), Albania (AL), Austria (AT)*, Belgium (BE), Bulgaria (BG), Switzerland (CH), Cyprus (CY), Czech Republic (CZ), Germany (DE), Denmark (DK), Estonia (EE)*, Spain (ES), Finland (FI)*, France (FR)*, United Kingdom (GB), Greece (GR), Croatia (HR), Hungary (HU), Ireland (IE), Iceland (IS), Italy (IT), Liechtenstein (LI), Lithuania (LT)*, Luxembourg (LU), Latvia (LV), Monaco (MC), Moldova (MD), Montenegro (ME), North Macedonia (MK), Malta (MT), Netherlands (NL), Norway (NO)*, Poland (PL), Portugal (PT)*, Romania (RO), Sweden (SE), Slovenia (SI), Slovakia (SK), San Marino (SM), Vatican City (VA).

* C2C-only countries: Austria (AT), Estonia (EE), Finland (FI), France (FR), Lithuania (LT), Norway (NO), and Portugal (PT) only accept C2C (individual to individual) payouts. Sending to a business beneficiary in these countries (B2B, C2B) or sending from a business sender (B2C) is not supported.

The use case is derived from the sender (your customer) and the receiver:

• B2B: business sender to business beneficiary
• B2C: business sender to individual beneficiary
• C2B: individual sender to business beneficiary
• C2C: individual sender to individual beneficiary

Get started

If your account already has KYC approved, SEPA is available immediately, no extra activation. Create a SEPA bank account from the dashboard or the API, and you're ready to send your first payout.

TL;DR

• RFI APIs: programmatic Request for Information flow
• Audit Logs: full visibility into sensitive team actions
• TED: high-volume payouts in Brazil

RFI APIs

Compliance review is now fully programmatic. You no longer need to email supporting documents when a customer requires additional information. Once you create a customer, we will notify you by email and webhook whenever a Request for Information (RFI) is opened, and your team can respond directly through the API.

This eliminates manual handoffs, shortens KYC/KYB turnaround times, and keeps the entire review trail inside your own systems. Read the RFI documentation to get started.

Audit Logs

Every sensitive action performed by members of your organization is now recorded in a dedicated audit trail, accessible under Settings → Audit logs. Each entry captures the actor, the affected resource, IP address, and a UTC timestamp, providing the traceability that internal and external auditors expect.

Audit Logs are part of our ongoing security commitment and are designed to support SOC 2, ISO 27001, and customer-led audit workflows. Read more in the Audit Logs changelog.

TED Payouts in Brazil

BlindPay now supports TED (Transferência Eletrônica Disponível) as a payout rail in Brazil, complementing our existing PIX coverage. TED is the preferred rail for high-value, business-to-business transactions and enables you to settle larger volumes with the same instance configuration you already use today.

TED is available as a selectable bank account type and as a payin method. Review the Payouts documentation and the Bank Accounts reference for setup details.

TL;DR

• Fixed USDB issuer mismatch on Stellar testnet trustline and mint endpoints
• Rotated the BlindPay operational wallet on Stellar mainnet
• Rotated the USDB issuer on Stellar testnet (action required for development instances)

Bug fix: USDB issuer mismatch on Stellar testnet

The POST /create-asset-trustline and POST /mint-usdb-stellar endpoints were referencing a different USDB issuer than the one used by payins and payouts. This caused development-instance customers to see different tokens depending on the operation. Both endpoints now use the same issuer as all other operations.

No API contract changes — request and response schemas remain the same.

Mainnet operational wallet rotated

The BlindPay treasury wallet on Stellar mainnet has been rotated to GCOSSQDM2SWMHRP7CDBOLL2V45NHCRLUWUCEHPPBA2ABCOOLPOLZKIHE. This wallet receives payout crypto and sends payin crypto on Stellar mainnet. No action is required from customers — the system already uses the new wallet.

Testnet USDB issuer rotated

The USDB asset issuer on Stellar testnet has been rotated to GCQSSIMOW5OCGULZATDXKU5MOJBOMFX6G65X6CXZDQ7AIB3SKFUZ67NX.

Action required for development instances on Stellar testnet:

1. Create a new USDB trustline via POST /create-asset-trustline
2. Mint new USDB via POST /mint-usdb-stellar

Old USDB balances from the previous issuer are orphaned and no longer recognized by the system.

TL;DR

• Audit trail for actions on your instance
• Dashboard UI under Settings → Audit logs
• API endpoints for programmatic access
• Tracks actor identity, passkey usage, IP address, country, user agent, and metadata
• Distinguishes between dashboard (user) and API key actions
• Filterable by feature, operation, actor type, user ID, API key ID, and entity ID

What's logged

Create, update, and delete operations across the platform are recorded:

• Customers - create, update, delete
• Bank accounts - create, delete
• Blockchain wallets - create, delete
• Blockchain operations - asset trustlines, USDB minting, Solana delegation
• Offramp wallets - create
• Virtual accounts - create, update
• Wallets - create, delete
• Payins - create
• Payouts - create, update (document submission)
• Transfers - create
• Customer limit increases - create
• API keys - create, delete
• Team members - update role, remove
• Invites - create, accept, delete
• Partner fees - create, delete
• Billing - update details, pay invoice, collect fees, portal session
• Onboarding - every step from business details to completion
• Webhook endpoints - create, delete

What each log captures

Every audit log entry includes:

Dashboard

Navigate to Settings → Audit logs to browse your instance's activity. Click any entry to open the detail pane with the full breakdown: actor info, request metadata, and action-specific context.

Use the filters to narrow down by feature, operation, actor type, user ID, API key ID, or entity ID.

API

Two new endpoints are available:

GET /v1/instances/{instance_id}/audit-logs
GET /v1/instances/{instance_id}/audit-logs/{id}

The list endpoint returns a paginated list of audit logs for your instance. It supports cursor-based pagination and the same filters available in the dashboard, plus date range filtering with start_date and end_date. The detail endpoint returns a single audit log entry by ID.

Permissions

Only owner and admin roles can view audit logs.

TL;DR

• ACH, Wire, RTP, and SWIFT updates
• 1 Business Day SLA
• BlindPay AI & CLI
• Passkey Enforcement

ACH, Wire, RTP, and SWIFT Updates

Over the last three months, we've been adding more providers and enhancing the payments experience at BlindPay. Here's a summary of what's available today:

1 Business Day SLA

We've made our onboarding process more seamless. No additional information beyond what's in the documentation will be required, and the SLA has been reduced from 3 to 1 business day.

If you're having trouble with the KYC/KYB process, please reach out directly to bernardo@blindpay.com.

BlindPay AI & CLI

We launched our new CLI and AI page, where you can see all the tools we've been shipping to improve your integration experience.

You can ask AI to run commands like blindpay customers list --json to debug or test things faster. Learn more here.

Passkey Enforcement

You can now require all team members using the BlindPay platform to enable passkeys. Once enforced, critical actions — such as initiating a payout, adding a bank account, creating wallets, or inviting new members — will require passkey verification.

Go to your instance > Settings > toggle the Enforce Passkey option.

TL;DR

• KYB verification reduced from 3 business days to 1
• No more RFIs — only documents listed in our API docs will ever be requested
• Breaking change (May 2, 2026): the website field becomes required when creating a Business customer

KYB Verification in 1 Business Day

KYB verification now completes within 1 business day, down from 3. No changes needed on your side — faster turnaround applies automatically to all new submissions.

No More RFIs

We will only ever request documents that are explicitly listed in our API documentation. Ad-hoc Requests for Information (RFIs) are eliminated. If it's not in the docs, we won't ask for it.

The only two exceptions where an RFI may still be issued:

• Unreadable or mismatched documents — when a submitted document cannot be processed by our KYC software (e.g., blurry scans, corrupted files) or when the document doesn't match the data provided (e.g., a proof of address missing the customer's name or showing a different address)
• Nested payment scenarios — when we identify that the company being onboarded operates a nested payment structure

website Field Required for Business Customers

Effective May 2, 2026, the website field will be required when creating a Business customer. Requests without it will be rejected.

Action required: Update your integration to include the website field before May 2 to avoid failed requests.

TL;DR

• Monthly invoicing with automated generation on the 1st of each month
• Transparent fee breakdown on every invoice
• Partner fees moved from per-transaction to monthly settlement
• Pay invoices via Stripe (card or US bank account) or stablecoins (USDT on Tron, USDC on Solana)
• New billing screen with real-time usage tracking
• Automated email notifications and overdue management
• Plan upgrade is one click and one call away, see blindpay.com/pricing
• Addons support for custom recurring charges (e.g., SWIFT access)

Monthly Invoicing

Invoices are now generated automatically on the 1st of each month, covering the previous calendar month. Each invoice consolidates all your charges and partner fee earnings into a single document, giving you a clear picture of what you owe or what you've earned.

How it works:

• Invoices are generated on the 1st of every month
• Each invoice covers a full calendar month (e.g., Feb 1 – Feb 28)

Invoices can have the following statuses:

• Owing — Invoice is unpaid, waiting for payment
• Paid — Payment has been received
• Claimable — You have partner fees to claim
• Collected — Partner fees have been sent to your wallet
• Overdue — Invoice is past the due date

Transparent Fee Breakdown

Every invoice now shows an itemized breakdown of your charges, so you always know exactly what you're being billed for.

Invoices include the following line items:

• Subscription plan amount — Your monthly plan fee (Basic, Business, or Enterprise)
• Virtual account fees — Charged per active KYC-approved virtual account
• Payin billing fees — Transaction fees collected on inbound payments
• Payout billing fees — Transaction fees on outbound payments
• Partner fee earnings — Your share of transaction fees, shown as a credit that offsets your charges
• Addons — Recurring charges like SWIFT access, etc.

Invoice calculation:

Your net amount is calculated as total charges minus partner fee earnings. If a minimum monthly amount applies to your plan, the minimum is used when your net is below it. If your partner fee earnings exceed your charges, the excess is claimable — you get paid instead.

Partner Fees — Monthly Settlement

Partner fees have transitioned from per-transaction settlements to a monthly settlement model. Instead of receiving a blockchain transfer after every transaction, your partner fee earnings are now accumulated throughout the month and settled on the invoice.

What changed:

• Partner fees are calculated per transaction and tracked in each quote (payin and payout)
• At the end of the month, all partner fees are totaled and applied as a credit on your invoice
• If your partner fee earnings exceed your charges, the remaining balance is claimable directly to your wallet

How to claim partner fees:

1. Open the invoice in the billing screen
2. If the invoice status is Claimable, click Collect
3. Enter your wallet address (EVM-compatible, e.g., Polygon)
4. BlindPay sends USDT to your wallet, typically arrives within a few minutes

Multiple Payment Methods

You can pay invoices via Stripe (credit card or US bank account) or directly with stablecoins on the blockchain.

Stripe payments:

• Add a credit card or US bank account via the Stripe Customer Portal
• Invoices can be paid directly through the Stripe-hosted invoice page
• Manage your payment methods at any time from the billing screen

Blockchain payments (USDT on Tron, USDC on Solana):

1. Open an invoice and click Pay, then select Blockchain
2. A dedicated wallet address is displayed along with the exact amount to send
3. Send the exact amount of stablecoins to the wallet address
4. Payment is detected automatically and the invoice status updates within minutes

Billing Screen

A completely new billing screen is available under Settings > Billing in the BlindPay app.

What you'll find:

• Subscription card — Your current plan, status, and subscription start date
• Current usage — Real-time view of your charges for the current billing period, including virtual account count, payin/payout fees, partner fee earnings, and addons
• Invoice history — All past invoices with status, amounts, and links to the Stripe-hosted invoice
• Invoice detail view — Click any invoice to see the full breakdown: fees, partner fee earnings, addons, discounts, and credit notes
• Fees table — Expandable table showing your payin and payout fee rates per payment method (ACH, Wire, Pix, SWIFT, etc.) and per blockchain network (Tron, Ethereum, Polygon, etc.)
• Payment method — View your saved payment method and open the Stripe Customer Portal to update it
• Billing details — Manage your billing contact information (name, email, tax ID, and address). All billing-related communications are sent to the billing email set here; if none is configured, the instance owner's email is used as fallback.

Automated Notifications and Overdue Management

You'll receive email notifications throughout the invoice lifecycle to help you stay on top of payments.

Notification schedule:

• Invoice created — "Your Invoice is Ready" email with amount, due date, and a link to view and pay the invoice
• 7 days before due — Upcoming invoice reminder
• 2 days before due — Payment reminder
• Due date — Due today notice
• 1 business day overdue — Past due alert
• 4+ business days overdue — Overdue action required

Overdue blocking:

If an invoice remains unpaid for more than 4 business days past the due date, the instance is automatically blocked. Blocked instances cannot process new transactions. An instance is unblocked only when no invoice is overdue for more than 4 business days. After paying the overdue invoice, the instance is unblocked automatically.

Migration Notes

• Partner fee settlement model changed: Partner fees are no longer sent per transaction. All partner fee earnings are accumulated and settled monthly via the invoice.
• Fee structure updated: Fees are now structured per payment method and per blockchain network.
• Stripe and blockchain payments: Each instance is linked to a Stripe customer. Invoices are created in Stripe with itemized line items and can be paid through Stripe or via blockchain with stablecoins.

TL;DR

• New banking partner for virtual accounts (beta)
• Billing and partner fees revamped
• BlindPay Skills

New Banking Partner for Virtual Accounts

Issue virtual accounts for your customers with full support for ACH, Wire, and SWIFT. All transactions, inbound and outbound, are named, and a UETR is provided for external tracking. Sender data is also collected on payins, giving you full visibility into who's sending funds to each virtual account.

This integration requires a few additional fields. Explore documentation

Billing and Partner Fees Revamped

The billing system has been rebuilt from the ground up. You can now see exactly what BlindPay charges per payment method and blockchain in one place.

Partner fees have moved from per-transaction to a monthly settlement model. All fees are consolidated and collectible at the end of each month from the new billing page. Review partner fees

BlindPay Skills

Give your AI coding assistant — Cursor, Claude Code, Codex, and others — instant knowledge of BlindPay's API and payment infrastructure. Install once, and your AI handles the integration.

Learn more about BlindPay Skills

All ACH and RTP bank accounts have been deprecated. New fields and rules apply to bank account creation for both ACH and RTP.

TL;DR

• ACH and RTP payouts now available in the US with a new banking partner (no Virtual Accounts)
• All existing ACH and RTP bank accounts are deprecated — new accounts must be created with the new rules
• Business customers require business_industry (NAICS code)
• Individual customers require local tax_id (e.g. CPF for Brazil, SSN for US)
• ACH and RTP payouts are capped at $50K for now
• All USD payouts will go to compliance_reviewing for manual review during the first few days

Rules you need to know

Customer-level rules

• Business customers: You must add business_industry (NAICS code) when the customer is a business.
• Individual customers: You must set tax_id to the local tax ID for the beneficiary's country (e.g. CPF for Brazil, SSN for the US). The system validates and formats it per country where required.

Payout limits and status

• All ACH and RTP payouts are capped at $50K for now.
• All USD payouts will be pushed to compliance_reviewing status so our team can manually review them for the first few days.

Bank account creation — New fields and rules

These rules apply to both ACH and RTP bank account creation.

Business accounts

• business_industry (NAICS code) is required when the customer or account class is "business".

Individual customers

• tax_id must be the local tax ID for the beneficiary’s country (e.g. CPF for Brazil, SSN for the US). The system validates and formats it per country where required.

Phone number

• phone_number is required when the beneficiary’s country is one of: BR, CN, CO, HK, MY, MX, PH, UG, UY.

Tax ID

• tax_id is required when the beneficiary’s country is one of: AR, BY, BR, CL, CN, CO, CR, EC, GT, HN, JP, KZ, KR, MX, PK, PE, PH, RU, TH, UY.

What this means for you

Action required: Recreate any ACH or RTP bank accounts with the new required fields and rules. Do not use deprecated ACH or RTP bank accounts.

For technical details, check our documentation and Api reference{target="_blank"}.

TL;DR

• SWIFT payouts now require document upload before processing
• Payouts remain on hold while documents are reviewed
• Documents can be resubmitted if rejected

Why are we making these changes?

International transfers via SWIFT require additional compliance documentation to meet regulatory requirements. This verification process ensures all cross-border payments are properly documented and compliant with international banking standards.

New payout flow for SWIFT

When you create a SWIFT payout, the flow is now:

1. Payout created → On hold while documentation is not provided or under review
2. Documents submitted → Compliance review begins
3. Compliance approved → Payout proceeds normally
4. Compliance rejected → Submit updated documents and review restarts

Compliance review timing varies based on region and case complexity. Payouts remain on hold pending approval, with an 8-hour SLA for document review.

TL;DR

• New mandatory fields for ACH bank accounts
• New mandatory fields for Wire/RTP bank accounts
• New mandatory fields for SWIFT bank accounts
• All deprecated US bank accounts must be recreated

Why are we making these changes?

We are getting compliant with the new US banking partners we're adding to the BlindPay ecosystem. These changes will ensure that all transactions are processed correctly, with BlindPay or the virtual account holder as the debitor and the recipient as the creditor.

New mandatory fields for ACH bank accounts

When creating an ACH bank account, the following fields are now mandatory:

• recipient_relationship
• address_line_1
• address_line_2 (optional)
• city
• state_province_region
• country
• postal_code

New mandatory fields for Wire/RTP bank accounts

When creating a Wire or RTP bank account, the following fields are now mandatory:

• account_class
• recipient_relationship

New fields for SWIFT bank accounts

When creating a SWIFT bank account, the following fields have been added:

• account_class (mandatory)
• recipient_relationship (mandatory)
• swift_payment_code (required only for: PK, PH, KE, JP, IN, ID, CN, CH, BH)

How to get the new field requirements

All new fields and their validation rules can be requested on the available bank details endpoint.

What this means for you

Action required: You will need to recreate all US bank accounts (ACH, Wire, RTP, and SWIFT) with the new mandatory fields.

Benefits: All transactions will be sent correctly, with BlindPay or the virtual account holder as the debitor and the recipient as the creditor. This ensures compliance with US banking regulations and improves transaction reliability.

TL;DR

• BlindPay MCP Launch
• Infrastructure Upgrade and Security
• UETR, ACH Trace ID and Wire IMAD

BlindPay MCP Launch

Now you can ask Cursor or Claude Code to collect data from customers, bank accounts, pay-ins, and payouts. You can also build reports or initiate payments as needed. Integrate with our MCP now.

UETR, ACH Trace ID, and Wire IMAD

New fields have been added to the payout API. Every day, we will now update jpm_track_data to show all information for SWIFT UETR, ACH Trace ID, and Wire IMAD. Check our documentation.

Infrastructure Upgrade and Security

We migrated all our infrastructure to AWS and we're targeting SOC 2 by Q1 2026. This means the response time from all our services is faster and more secure.

TL;DR

• Onramp in Argentina and Colombia
• Multiple Virtual Accounts
• Solana is Fully Deployed
• New Upload Endpoint

Onramp in Argentina and Colombia

Now you can collect payments in Argentina and Colombia, both in real time. BlindPay is adding two new rails: Transfers 3.0 for Argentina and PSE Colombia, enabling your customers to fund their accounts instantly using local payment methods. Integrate it now.

Multiple Virtual Accounts

You can now issue multiple virtual accounts for every customer, allowing you to separate funds by purpose and better organize your payment flows. See the documentation.

Solana is Fully Deployed

All BlindPay features are now live on Solana, including payins, payouts, and virtual accounts. This means you can leverage Solana's fast transaction speeds and low fees across our entire product suite, giving you another powerful blockchain option alongside our existing networks. Learn more.

New Upload Endpoint

The new endpoint allows you to handle user privacy and data protection in the best way possible: simply upload the required documents, receive a secure URL, and use it to complete the verification process. This streamlines your compliance workflow while maintaining the highest privacy standards. Start integration.

Important compliance changes are coming to BlindPay's onboarding process to ensure continued regulatory compliance.

TL;DR

• PoA documents for UBOs are now mandatory
• New updates to Business PoA documents

PoA documents for UBOs are now mandatory

Starting January 8th, 2026, it will be mandatory for all Ultimate Beneficial Owners (UBOs) to submit a valid proof of address document as part of the onboarding process. For comprehensive guidance on accepted documents and submission procedures, please refer to the documentation here.

New updates to Business PoA documents

If you are onboarding a contractor or freelancer company in Brazil (with a single UBO), and the company's registered address is that of the accountant, we will accept a document co-signed by both the accountant and the UBO. This document should clearly explain their relationship and the reason for using the accountant's address as the company's official registration.

TL;DR

• New Website
• Solana offramp wallets is now live
• New Swift SDK

New Website

Our belief is simple: great developer experience and stablecoin abstraction will be the competitive advantage in the stablecoin space. We've completely refreshed our website to reflect this vision. Check it out here.

Solana Offramp Wallet

You can now generate a Solana wallet that automatically offramps all USDC transactions. Full Solana support across the BlindPay ecosystem is coming soon. View documentation.

Swift SDK

Apple developers can now integrate BlindPay with just a few lines of code. See GitHub docs.

TL;DR

• Ethereum Mainnet and Solana Devnet Support
• Self-Service Customer Limit Increases
• New SDKs: Node, Python, and Go

Ethereum Mainnet and Solana Devnet Support

You can now send and collect USDC or USDT on Ethereum Mainnet. Ethereum integration works the same way as other EVM chains you're already familiar with.

Solana Devnet is now available on Development Instances using USDB. Check out our Solana documentation for implementation details.

Self-Service Customer Limit Increases

Request limit increases directly through the dashboard or API—no more emails to our compliance team.

Submit your request with supporting documents via the dashboard or API, and our compliance team will review it within 24 hours. You'll receive webhook notifications for every status change and can track the full history of your requests. Check our API reference.

Node, Python and Go SDKs

We're committed to delivering the best developer experience in the industry. Our new Node SDK , Python SDK , and Go SDK make integration faster and easier than ever. We're also updating our website with more detailed guides and examples to help you get the most out of our APIs.

TL;DR

• New terms of service available (breaking changes)
• Customer creation updates (breaking changes)

New terms of service version available

All your customers will be required to accept the new version of our terms of service. This is necessary to allow BlindPay to issue virtual accounts, create wallets and process payments on behalf of them.

Every time you try to create a quote, an error message please_accept_terms_of_service will show up. When you see that, you should pop up the terms of service link and make your customer accept. Consult the terms of service guide for integration details.

You will also receive updated tos.accept webhook events—review the webhook documentation to handle them correctly.

Customer creation updates

The following fields are now updated:

• The fields phone_number and selfie_file are now mandatory for individuals. This is necessary because our US banking partner will require them in the future, so we're already anticipating this.
• The field individual_holding_doc_front_file is deprecated for enhanced KYC because of the addition of selfie_file.
• The field website is now mandatory for businesses.
• The prohibited and high-risk countries list was updated. All customers from high-risk countries must go through enhanced KYC verification.
• We're adding new fraud checks when analyzing customer data. If the KYC is rejected, you'll see details in fraud_warnings.

Update your onboarding forms and validation logic ahead of the deadline to avoid interruptions.

TL;DR

• RTP is now live
• Offramp wallets
• Tron network
• On hold transactions
• Virtual accounts countries update (breaking changes)

Real-time payments in the US

Now you have access to RTP in the US and can send or collect payments from over 4,000 banks. You don't need to wait for ACH or wire settlement times anymore—just submit an RTP payout and watch it settle in real time. Learn how to configure the rail in the payout guide.

Offramp wallets

Generate a dedicated blockchain wallet that automatically converts supported stablecoins into fiat the moment funds arrive. This is perfect for moving assets directly from exchanges or enterprise custodians. Follow the offramp wallet tutorial to begin.

Tron network

BlindPay now supports the Tron network for offramping USDT. Point your Tron wallets at BlindPay and we will handle the conversion to fiat. Right now this is only supported for offramp wallets. We would love feedback as we expand support to additional networks—drop us a note.

On hold transactions

We improved our transaction monitoring solution to prevent fraudulent activities. Now you will see a new payin status On Hold for payments that our KYT software has flagged and our compliance team might request information for before releasing them. The on hold guide explains how to respond quickly.

Virtual accounts countries update (breaking changes)

We added a list of high-risk countries where only customers with enhanced due diligence will be able to create a virtual account. Review the latest requirements in the supported countries guide before onboarding new customers.

TL;DR

• International SWIFT is available
• Export data and filters improved
• Payout receipts

International SWIFT

You can now collect and send SWIFT payments using virtual accounts, unlocking instant access to global banking corridors.

Important compliance reminder: All outgoing SWIFT transactions require supporting documentation for validation. This helps ensure secure, compliant transfers that meet international banking standards. Check the payout API reference for details before submitting payouts.

Export data and filters improved

You can now export all your payouts and payins directly from the platform, making it easier to reconcile transactions across your data sources and streamline your financial reporting.

We've also enhanced our filtering capabilities with new status and customer_id filters available in both the API and dashboard for more precise transaction management. The payouts reference outlines the latest query parameters.

Payout receipts

BlindPay now automatically generates a receipt document for every completed payout, providing you with professional documentation to share with recipient banks and ensure full transaction transparency.

To access your receipts, simply open the external tracking link from any completed payout and click Print receipt to download a PDF copy for your records.

TL;DR

• Role-based access control
• Automated onramp
• Sending international SWIFT (beta)

Role-based access control

Collaborate with your team effortlessly! Invite teammates and assign granular permissions so each person has the exact access they need. Navigate to Settings → Team to add members, then select capabilities like customer creation, payment execution, or analytics-only visibility.

Automated onramp

When funds arrive in your virtual account, BlindPay automatically converts them into stablecoin and deposits directly to your chosen blockchain wallet. Choose to receive either USDC or USDT—it's completely automated. Review the configuration steps in the payin guide to get started.

Sending international SWIFT (beta)

Send payments globally with ease. With BlindPay's international SWIFT capabilities you'll be able to access the entire world with stablecoins. Want to unlock global payments? Contact sales to enable international corridors on your instance.

TL;DR

• Stellar integration
• Virtual accounts documentation
• Support for SWIFT payments

Stellar integration

BlindPay now supports Stellar alongside our existing EVM networks. We are joining the Stellar team in Toronto during Consensus 2025 to help Stellar developers build on top of the BlindPay API. Planning to attend? Book time with our team and we will sync on your roadmap.

Virtual accounts documentation

Virtual accounts are now fully documented. Visit the virtual accounts guide to review settlement flows, fees, and API usage. Note the upcoming fee adjustments: ACH flat fees move to $0.40 and wire flat fees move to $15.00 while percentage-based fees remain unchanged.

SWIFT payments

Every customer with a virtual account can now collect international SWIFT transfers. We are building a way to send SWIFT payments worldwide using stablecoins. Have a use case already? Let us know so we can include you in the beta.

TL;DR

• US named accounts
• Terms of Service API (breaking changes)
• Pagination (breaking changes)

Named Virtual Accounts powered by Tier 1 Bank in the US

BlindPay can issue named virtual accounts backed by Tier 1 Bank in the US. This unlocks customer-facing account numbers that display your client's business or individual name instead of BlindPay. We are already onboarding beta testers—reach out to us if you want early access or pricing details.

Terms of Service API (breaking changes)

For compliance reasons every customer must accept BlindPay’s terms of service before you can create payouts or payins on their behalf. Update your onboarding flow to capture the tos_id returned by the Terms of Service endpoint and persist it when you create customers. All customers must complete this step by May 30 to avoid disruptions.

Pagination (breaking changes)

The /payins and /payouts endpoints now support cursor pagination with the limit, starting_after, and ending_before parameters. The legacy pagination response will be deprecated on June 30. Review the new parameters in the API reference and add the customer_id query filter where needed to segment results by customer.

We also added the first filter related to customers, so you can pass the customer_id on the query parameter as well.