Using two stablecoin providers means splitting a payment stack so each provider owns separate jobs, for example one holds balances and conversion while the other delivers local currency. Routing rules pick the provider for each payment, and one internal ledger ties both legs together. The split works only when it is written down before the first payment.
The guide covers the split, handoff, routing, failover, webhooks, the ledger and KYB (know your business, the verification of a company and its owners). Choosing one provider is covered in choose a stablecoin infrastructure provider. Replacing one is covered in migrate a stablecoin payout provider.
Why run two stablecoin providers at all?
Because no single provider is the strongest option for every job in a stack. Four reasons come up:
Coverage. One provider reaches a country or rail that the other does not, so each payment goes where it can land.
Specialization. One provider is built to hold balances and convert, the other to deliver local currency to a bank account.
Price on a specific route. Two providers quote one route differently, and the delivered amount decides.
Concentration risk. A second path means an outage or a hold does not stop every payout.
A second provider adds a contract, a KYB file, a webhook format and a ledger leg. If none of the four reasons applies to a route you run today, one provider is the right answer.
What job does each provider take?
One system of record per job. Write the split as a table, because the first argument in an incident is always about who owned what.
An example split of jobs between two providers, with what Lumx covers on its side, from the Lumx docs read on November 1, 2026.
Job | Owner in the split | Why it sits there | What Lumx covers |
Holding balances and treasury conversion | Provider A | One balance view for finance | A custodial wallet for each customer, with an address per supported blockchain, holding USDC and USDT |
Collecting local currency from payers | Provider B or A, never both for one payer | Deposits must land in one ledger | BRL and MXN named virtual accounts, in the customer's own name, collect by Pix (Brazil's instant payment system, run by the Central Bank) and SPEI (Mexico's interbank transfer system, run by Banxico); the COP account collects by Bre-B (Colombia's instant payment system) and PSE, and is named only for Colombian customers |
Paying local currency to a bank account | The provider with the best local rail for that route | Last mile quality decides delivery | Local payouts by Pix, SPEI and Bre-B, plus USD by wire, ACH and SWIFT, EUR by SEPA and GBP by Faster Payments (Faster Payments is the UK's real-time bank transfer network) |
Stablecoin to external wallet | Whichever holds the funds at the time | Avoids a conversion that nobody needs | Transfer to an external wallet in USDC or USDT |
Customer verification | Each provider, under its own rules | Each provider answers to its own regulator and bank | Business customers go through the Lumx KYB flow |
The account type behind the collection row is in what a named virtual account is and the product page.
On Lumx, a customer is created once, asks for the currencies it needs in the accounts array, and gets a wallet. What the other side of your split does is your own contract to read.
How funds move from one provider to the other
Funds move as a stablecoin transfer on a blockchain network, which you design as one more payment with its own failure modes.
Three details decide whether the handoff is boring:
Network. Both providers must support the same network for the same coin. Check that before you route anything.
Address. Send to an address the receiving provider issued for that customer, and save it. A first transfer of a small amount proves the path.
Timing. A quote on the receiving side can expire while funds are in transit. Move the funds first, then ask for the quote.
Compliance reads this step differently. The receiving provider can screen an inbound transfer from another provider's address and hold it until it is cleared, so a small first transfer also tests that. The sender of record is your company, and the source of funds and the counterparty may need to be declared to the receiving provider. While funds are in transit they are in custody at two companies, so keep the window short.
On Lumx, each customer's wallet has an address on every supported blockchain, and each address is a real blockchain address, so funding from another provider is a transfer to it and needs no on-ramp call. Wallets are enabled once the customer is APPROVED, and every transaction in or out is screened before it executes. Blockchain activity, including a transfer received from an external address, is monitored with Chainalysis KYT, which covers every type of wallet. Fiat legs use Lumx's own systems and banking-partner oversight. Going the other way, the Transfer endpoint moves USDC or USDT from a customer to an external wallet address, on the networks in the wallets documentation, with the coin each supports: USDC and USDT on Ethereum and Polygon, USDC only on Base, USDT only on Tron. Stellar carries USDC for the BRL on-ramp only. A transfer is a transaction with its own status, from TRANSFERRING_STABLECOIN to SUCCESS.
Routing rules, written as a table finance can read
Rules are checked in order, and the first match wins. Put them in configuration, so a route change is a table edit, not a deploy.
An example routing table. The order matters: the first row that matches decides.
Order | Input | Rule | If no rule matches |
1 | Destination currency and rail | Send to the provider that runs that rail | Hold the payment for review |
2 | Recipient type (business, individual, own account) | Some routes need extra documents from one provider | Route to the provider with the lighter file |
3 | Amount | Check each provider's per-payment limit and minimum | Split only where the rail allows it |
4 | Where the funds are now | Pay from the provider that holds them | Plan a transfer, never improvise one |
5 | Delivered amount | If both serve the route, compare the final amount from a live quote, not a headline rate | Use the default provider |
Never let the rule engine pick a provider for an in-flight payment: that is how one payment becomes two.
Routing across wider sets of providers is in payment orchestration with stablecoins.
On Lumx, the rule inputs you read are the destination's rail, its holder.relationship and the purpose of the payment. Price comes from a locked exchange rate of 30 seconds, one minute or five minutes, and the 30-second lock has no fee. Limits that apply to a customer are global and documented under transaction limits. Pass the exchangeRateId on the off-ramp request to settle at that quote.
Failover: what is safe to retry and what is not
Fail over only while the money is still yours. The line is the moment the stablecoin leaves your account at provider A. Before that line a second route is a retry. After it, a second route is a second payment.
Where a payment stands, whether funds have left, and the safe action.
Failure | Funds already sent? | Safe action |
Quote request rejected (unsupported pair, below minimum) | No | Route to the other provider |
Destination fails verification | No | Fix the details, then retry on the same provider |
API timeout on create | Unknown | Retry with the same idempotency key before any other route |
API returns a validation error | No | Fix the request. Do not fail over |
Locked quote expired before submit | No | Request a new quote, then submit |
Payment in a processing status longer than usual | Yes | Wait, track, contact support. Never send again |
Payment reported as failed after the transfer started | Yes | Confirm where the funds are before re-routing |
Webhook endpoint down on your side | Not applicable | Read the payment by ID. Do not infer the outcome from silence |
The processing row and the failed-after-start row cause double payments: both look like a reason to try the other provider.
Test the failover before you need it. Run a drill on one route with a small real payment: block the primary, confirm the router sends the next payment to the second provider, and confirm the first payment is not sent twice. Repeat it after any change to the routing table. Ask each provider, too, for its service level, its support escalation contact and how much notice it gives before a change; the questions are in on and off-ramp provider contract terms. Lumx publishes its service level agreement, is compliant with SOC 2 and ISO 27001 (not yet certified) and runs penetration tests.
On Lumx, any POST, PUT or PATCH can carry an Idempotency-Key header with a UUID v4. The same key and body return the stored response with an X-Idempotency-Cached: true header, and the same key with a different body returns a 409. Keys expire after 24 hours, and failed responses are cached too, so a retry with the same key returns the same error. A deliberate new attempt after a failure needs a new key. The outcome of an off-ramp is read from the transaction by ID, and the offramp.failed event signals a failure.
One webhook consumer for both providers
Give both providers' events one internal shape before they touch your code.
An adapter per provider maps each event to your own statuses. Three habits matter most:
Verify the signature on the raw body, before any JSON parsing.
Deduplicate on the event ID, because delivery is at least once.
Treat the payment record fetched by ID as the truth, not event order.
On Lumx, every event carries eventId, eventType and data. Delivery headers are webhook-id, webhook-timestamp and webhook-signature, and webhook-id is the one to deduplicate on. If your endpoint does not return a 2xx, Lumx retries up to eight times on a schedule that runs from immediately to 10 hours. After that the message is marked failed, and it can be retried by hand from the Dashboard. Event types follow the transaction lifecycle, for example offramp.transferring_fiat and offramp.success, as listed in the webhooks documentation.
One payment ID, one ledger
Create your own payment ID before any money moves, and put it on every leg. A payment across two providers leaves at least three records: a movement at provider A, a blockchain transfer, and a payout at the second. Without a shared ID, matching them is a daily manual job.
Orphans worth an alert, when a leg exists without the next one.
Orphan | What it usually means | Alert after |
Debit at provider A, no transfer hash | Transfer stuck or never created | One hour |
Transfer hash, no payout at provider B | Funds arrived and nobody asked for the payout | One hour |
Payout in progress at provider B, no delivery | Normal for a slow rail, stuck for a fast one | The rail's cut-off plus one business day |
Ledger entry, no payout anywhere | Duplicate or phantom write | Immediately |
On Lumx, a transaction accepts a metadata object with any valid JSON, so your payment ID travels with the transaction and comes back in the webhook data. Put it there on every request. A transfer response also carries the transaction ID and a state object, which is what you store next to your own ID.
Collect KYB once, submit it to each provider
KYB is the one job you cannot hand to a second provider. Each provider verifies the same company under its own rules, so a file approved at one is not accepted at the other by default. What you can do is collect the documents once and submit them to each provider in its own format.
Collect these once, in your own system: incorporation articles, the shareholder and directors registries, proof of address dated within the window each provider sets (often 90 days or less), and each beneficial owner's identity document. The basics are in what KYB is.
On Lumx, a business customer accepts the terms of service, sends additional information, uploads company documents, adds associated parties (at least one beneficial owner, one shareholder and one representative, and one person can fill several roles) and starts the verification. Statuses include UNDER_VERIFICATION, APPROVED, RFI (request for information, a hold that asks for a document) and FINAL_REJECTION. Lumx targets one business day for a standard KYB review once documents are in, a target and not a promise. Identity reuse through a Sumsub share token exists for individuals only, so a business goes through the full flow.
When two providers are the wrong call
Skip it when the second route's volume is too small to pay for the extra ledger leg, when one provider covers every route you run, when your team cannot explain the failure the second provider would fix, and when the plan is to send every payment to both and keep the cheaper one: that creates duplicate payments, not redundancy. A single provider with a tested failure plan beats two providers with none.
I would not add a second provider until the first one has a failure I can name, and I would add it to one route only. Every extra provider brings a ledger leg and a webhook format that someone has to own. When a second route has run in parallel for a full month with the first still live, finance can compare delivered amounts and support tickets, and then the default route moves.
What a two-provider stack looks like with Lumx on the local side
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
In a split, the local side is where Lumx fits: collection in the customer's own name and local payouts. Coverage is on the coverage page, the operator map and the supported countries list. The rails and account types are described in global payments, and the vocabulary for the routes in what a stablecoin corridor is and what a stablecoin API is.
From your side of the split, Lumx is customers, wallets, destinations and transactions, with signed webhooks.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Denys Nevozhai on Unsplash.
Can you use two stablecoin providers at the same time?
Yes. Give each provider separate jobs, write routing rules that pick one per payment, and keep one payment ID across both. The risk is a double payment, which confirming where the funds are before any re-route prevents. On Lumx, you create the customer once with the currencies it needs, route payments to Lumx by rail, and carry your own payment ID in the transaction metadata.
How do you decide which provider handles a payment?
Check rules in a fixed order: the destination currency and rail, the recipient type, the amount, where the funds are now, and last the delivered amount from a live quote. Write the order down in configuration finance can read. On Lumx, the rail comes from the destination, the quote from a locked exchange rate of 30 seconds, one minute or five minutes, and the 30-second lock has no fee.
What happens if one of the two providers is down?
Fail over only before the funds leave provider A. After that, wait for a final status and read the payment by ID. Retry timeouts with the same idempotency key before trying another route. On Lumx, an Idempotency-Key replays the stored response for 24 hours, and a failed response is stored too, so a deliberate new attempt needs a new key.
Do you need to do KYB twice with two providers?
You collect the documents once but each provider reviews the company under its own rules, so expect two approvals. On Lumx, a business customer completes the full KYB flow, which targets one business day for a standard review once all documents are uploaded.
How do you track one payment across two providers?
Create your own payment ID before money moves, send it on every leg, and match the legs daily. On Lumx, put your ID in the transaction metadata, deduplicate events on the webhook-id header, and read the transaction by ID as the source of truth.
