---
title: "Using two stablecoin providers: how to pair an account platform with a local payout API"
seoTitle: "Pairing a stablecoin account platform with a payout API"
description: "How to run a stablecoin account platform and a local payout API side by side: the handoff, routing rules, fallback, and one reconciliation key."
date: "2026-10-15"
updated: "2026-10-15"
category: "payments"
author: "BlindPay Team"
howto:
  name: "How to pair a stablecoin account platform with a local payout API"
  steps:
    - name: "Split the jobs"
      text: "Write down which provider owns balances, wallets, cards, and issuance, and which owns the last mile to local bank accounts. One owner per job, so a payment never has two systems of record."
    - name: "Pick the handoff pattern"
      text: "Either send stablecoins from the account platform to a payout API deposit address tied to a bank account, or request a payout quote and fund it from a wallet you control. The first is simpler, the second locks the rate before funds move."
    - name: "Write the routing rules"
      text: "Route by destination currency and rail, then by amount and recipient type. Keep the rules in config, not code, so finance can read them and change a corridor without a deploy."
    - name: "Add a fallback and a kill switch"
      text: "Define what happens when one provider rejects a payout, is slow, or is down. Fail over only before funds leave your wallet, never after, so one payment cannot be paid twice."
    - name: "Reconcile on one internal ID"
      text: "Carry your own payment ID through both providers: the transfer reference on the account platform side and the external reference on the payout side. Match on it daily, and alert on any leg without a partner."
faq:
  - q: "Why would a company use two stablecoin providers?"
    a: "Because the jobs differ. An account platform holds balances, issues wallets or cards, and converts between fiat and stablecoins. A local payout API turns stablecoins into BRL, MXN, EUR, or USD in a recipient's bank account over Pix, SPEI, SEPA, or ACH. Few teams find one provider that is the strongest choice for both, so they split the stack by job."
  - q: "How do funds move from one stablecoin provider to another?"
    a: "On-chain, as a stablecoin transfer. The account platform sends USDC or USDT to an address the payout provider gives you. With BlindPay, that address can be an offramp wallet tied to one bank account, which converts and pays out every deposit automatically, or your own wallet that funds a quoted payout after an on-chain approval."
  - q: "Does using two providers double the compliance work?"
    a: "Partly. Each regulated provider runs its own KYC or KYB on the parties it serves, so a payee may be verified twice. You also keep your own program obligations either way. Plan the onboarding order, collect documents once in your product, and submit them to both providers, so the user does not upload the same passport twice."
  - q: "How do you reconcile payments across two providers?"
    a: "Create your own payment ID before any money moves and carry it into both systems: in the transfer reference on the account side and in an external reference on the payout side. Store the on-chain transaction hash that links the two legs. A daily job then matches account debits, on-chain transfers, and payout statuses by that ID."
  - q: "Is it safe to fail over a payout to a second provider?"
    a: "Only if the first provider never received the funds. Fail over on quote errors, rejected bank details, or an outage before you send stablecoins. Once funds have left your wallet, wait for the first provider's final status or refund. Sending a second payout while the first is still processing is how a payment gets paid twice."
  - q: "Who are BVNK and Bridge owned by in 2026?"
    a: "Both now sit inside large payment companies. Mastercard said it completed its acquisition of BVNK on August 3, 2026, and Stripe said it completed its acquisition of Bridge on February 4, 2025. Ownership changes can move contracts, entities, and roadmaps, so confirm which legal entity you sign with and read each provider's current terms during due diligence."
---

Pairing two stablecoin providers means giving each one a single job: an account platform holds balances, wallets, cards, or conversion, and a local payout API like BlindPay delivers local currency to bank accounts. Funds move between them as an on-chain stablecoin transfer, routing rules pick the provider per payment, and one internal ID ties both legs together.

The hub page on [blockchain payments vs crypto payments](/resources/more/blockchain-payments-vs-crypto-payments) explains the rails underneath. This page is about the stack on top: what to give each provider, how the handoff works, and where two-provider setups break.

**Key takeaways**

- Split by job, not by vendor: balances and wallets on one side, the local payout leg on the other.
- The handoff is a stablecoin transfer. Either send to a deposit address that pays out automatically, or fund a quoted payout from your own wallet.
- Route by destination currency and rail first, then by amount and recipient type.
- Fail over only before funds leave your wallet. After that, wait for a final status.
- Reconcile everything on one internal payment ID plus the on-chain transaction hash.

## Why do companies combine stablecoin providers?

Because no provider is the strongest option for every job in a stablecoin stack. Teams pick an account platform for holding and converting money, then add a specialist where the account platform is thin, most often the last mile into local bank rails.

> **Definition:** A **stablecoin account platform** holds fiat and stablecoin balances for a business, converts between them, and moves funds through one account and API. A **local payout API** takes stablecoins and pays local currency into a named bank rail, such as Pix in Brazil or SPEI in Mexico, for a specific recipient.

The two account platforms buyers mention most are BVNK and Bridge, and both now belong to large payment companies:

- **BVNK.** Mastercard said it [completed its acquisition of BVNK on August 3, 2026](https://s25.q4cdn.com/479285134/files/doc_news/Mastercard-completes-acquisition-of-BVNK-to-advance-global-stablecoin-capabilities-2026.pdf), describing BVNK as infrastructure that lets businesses "hold, move, manage and convert value across fiat and digital currencies". BVNK's [send page](https://www.bvnk.com/send) (reviewed October 2026) says customers can fund payouts in EUR, GBP, or USD, that BVNK converts to USDC, USDT, or EURC for the final payout, and that it moves money across 130+ countries.
- **Bridge.** Stripe said it [completed its acquisition of Bridge on February 4, 2025](https://stripe.com/us/newsroom/news/stripe-completes-bridge-acquisition). Bridge's [API docs](https://apidocs.bridge.xyz/) (reviewed October 2026) list virtual accounts for deposits in USD, EUR, GBP, MXN and more, orchestration for on-ramps, off-ramps and crypto-to-crypto transfers, custodied wallets, stablecoin-backed cards, and stablecoin issuance.

Those are broad platforms. A team paying contractors in Brazil, suppliers in Mexico, or sellers in the SEPA zone still has to pick who carries the money from a stablecoin into the recipient's bank account. That is where a second provider comes in.

## What job does each provider take?

Give each provider the jobs it is built for, and write the split down. The rule is one system of record per job.

| Job | Usually owned by | Why |
| --- | --- | --- |
| Local payouts over Pix, SPEI, ACH, RTP, SEPA, Faster Payments, SWIFT (POBO/COBO) | BlindPay (payout API) | Named rails per country, compliance in the API, live quotes before execute |
| Collecting US bank transfers into stablecoins | BlindPay virtual accounts, or the account platform | Both can do it; pick one so deposits land in one ledger |
| Holding fiat and stablecoin balances in one enterprise account | Account platform (for example BVNK) | Account model, licensed for e-money in its markets |
| Custodied wallets, cards, or issuing your own stablecoin | Account platform (for example Bridge) | Its documented product areas |
| Treasury conversion between fiat and stablecoins | Either | Compare live rates per conversion |

BlindPay pays out over ACH, wire, RTP, and SWIFT (POBO/COBO) in the US and internationally, Pix in Brazil, SPEI in Mexico, ACH COP in Colombia, Transfers in Argentina, SEPA in Europe, and Faster Payments in the UK, per its [payout overview](/docs/overview). SWIFT payouts carry a UETR and map the payment reference to MT103 field 70, as the [POBO and COBO guide](/docs/kb/pobo-cobo) explains. For the wider category map, see [types of stablecoin APIs](/resources/more/types-of-stablecoin-apis).

## How do funds move from one provider to the other?

As a stablecoin transfer on a blockchain network. There are two ways to set up the receiving side with BlindPay, and they trade simplicity against rate control.

**Pattern A: send to an offramp wallet.** An [offramp wallet](/docs/offramp-wallets?flavor=advanced) is a deposit address BlindPay creates for one of your customer's bank accounts. Every USDC or USDT deposit it receives is converted and paid out to that bank account automatically, with no quote or execute call. The account platform just sends funds to the address. It accepts deposits on Tron, Solana, Ethereum, Polygon, Arbitrum, Base, Tempo, and Arc, with per-network minimums and fees listed in the docs.

**Pattern B: fund a quoted payout from your wallet.** You request a [payout quote](/docs/payout-quotes) that locks the rate and fees, then fund it from a wallet you control. On EVM chains you approve the quoted ERC-20 amount, on Stellar you sign a transaction, on Solana you delegate the tokens. The quote expires after 5 minutes, so move the stablecoins from the account platform to your wallet first, then quote and execute.

| | Pattern A: offramp wallet | Pattern B: quote then execute |
| --- | --- | --- |
| Calls on the payout side | Create the wallet once | Quote and execute per payout |
| Rate | Converted at deposit time (USDC at the live rate) | Locked in the quote for 5 minutes |
| Best for | Recurring payouts to the same bank account | One-off payouts, exact recipient amounts |
| Watch out for | A deposit smaller than its fees is not converted and stays at the address | Quote expiry while funds are still in transit |

Pattern A is the shortest integration. Pattern B gives finance a firm number before money moves, and supports quoting in the recipient's currency so an exact amount lands.

## How do you decide which provider handles a payment?

With written routing rules, checked in order. Most teams route on four inputs.

1. **Destination currency and rail.** BRL over Pix, MXN over SPEI, EUR over SEPA, and the other local rails go to the payout API. Stablecoin-to-wallet payouts can stay on the account platform.
2. **Recipient type.** Business, individual, or your own account changes the documents needed. A SWIFT payout to a third party needs compliance documents after creation, for example.
3. **Amount.** Check each provider's minimums and limits per rail before you send.
4. **Price.** If both providers serve a corridor, compare the delivered amount from live quotes, not a headline rate. BlindPay combines a monthly plan with per-transaction fees that vary by rail and network and are disclosed in the live quote before execute.

Keep these rules in configuration that finance can read. When a corridor's economics change, you edit a table, not your payment code. The [payment orchestration guide](/resources/more/stablecoin-payment-orchestration-cross-border-payouts) covers routing engines in more depth.

## What happens when one provider fails or rejects a payout?

You fail over only while the money is still yours. The line is the moment stablecoins leave your wallet or account.

| Failure | Funds already sent? | Safe action |
| --- | --- | --- |
| Quote request rejected (unsupported pair, below minimum) | No | Route to the other provider or fix the request |
| Bank details rejected at creation | No | Fix the details, then retry |
| Provider API down or timing out | Unknown | Retry with the same idempotency key before trying elsewhere |
| Payout `processing` or `on_hold` for longer than expected | Yes | Wait, track, contact support. Do not send again |
| Payout `failed` or `refunded` | Yes | Confirm where funds went, then re-route |

BlindPay accepts an `Idempotency-Key` header on mutating calls, so a retry after a timeout replays the original response instead of creating a second payout ([idempotency docs](/docs/learn/idempotency)). On the refund question, be precise about custody. BlindPay operates as a non-custodial payment processor for payout flows from customer-controlled wallets: you authorize the exact amount and BlindPay executes that single transaction. If a payout cannot be delivered after the stablecoins are collected, BlindPay refunds them to the quote's refund wallet, or to the sending wallet when none is set; on Pix and other non-USD local rails the refund is automatic, while USD payouts and payouts whose review times out are refunded after an operator review. Optional BlindPay-managed wallets (beta) are custodial when you choose that path.

That refund path matters for the routing design. A refunded payout lands back in a wallet, not at the account platform, so your rules need a step that moves it back or re-routes it. The [provider failure guide](/resources/more/what-happens-if-a-stablecoin-payment-provider-fails) covers the bigger case, a provider going away.

## How do you reconcile two providers?

On one ID you create before any money moves. Every leg carries it, and a daily job matches the legs.

A single payment produces three records: a debit or transfer on the account platform, an on-chain transaction, and a payout at BlindPay. Link them like this:

- **Your payment ID** goes in the account platform's transfer reference and in BlindPay's `external_id` where the object has one, such as an offramp wallet.
- **The transaction hash** links the on-chain leg. BlindPay payout and payin objects expose tracking objects with the hash once it exists.
- **Webhooks** drive status. Listen for `payout.new`, `payout.update`, and `payout.complete` on the BlindPay side, and read the `status` field, since a failed payout can arrive as an update.

Alert on any orphan: an account debit with no on-chain hash after an hour, or a hash with no payout. The [webhooks and reconciliation guide](/resources/more/stablecoin-api-webhooks-reconciliation) has the matching logic, and [Bridge and BlindPay for cards plus payouts](/resources/more/bridge-cards-and-blindpay-payouts) shows the same split for a card program.

## What should a two-provider rollout look like?

Start with one corridor, run it in parallel, then widen. A sensible order:

1. Pick one corridor where the payout API clearly fits, such as USDC to BRL over Pix.
2. Build the handoff in a development instance. BlindPay development instances use USDB on testnets and complete payouts automatically, so you can test the full loop without real funds.
3. Run 20 to 50 production payouts through the new path while the old path stays live.
4. Compare delivered amount, time to `completed`, and support tickets per 100 payouts.
5. Move the corridor's default route, keep the old route as fallback, and repeat for the next corridor.

Before you sign either contract, run both through the [provider red flags list](/resources/more/blockchain-payment-provider-red-flags) and the [full-stack platform vs payout API comparison](/resources/more/stablecoin-platform-vs-payout-api).

## What to do next

Write your job split as a two-column table today, then pick the first corridor to move. If the job on the right side is local payouts, [create a BlindPay development instance and run a test payout from the payout quickstart](/docs/quickstart-payout).