Blog

A contractor in Manila invoices EUR 3,000. You send it by SWIFT on the 28th. It arrives days later, an intermediary bank has taken its cut, and the amount that lands matches neither the invoice nor your ledger. Stablecoin payroll fixes that part: value moves in minutes, on any day of the week, and arrives at the amount you sent. What it does not fix is who your team legally works for. This article covers both: how to pay a global team in USDC or USDT without a local entity, and where the rail stops being the answer.

What stablecoin payroll is, and what it is not

Stablecoin payroll is paying people, usually contractors, in a fiat-pegged token such as USDC or USDT instead of by bank transfer. The company funds in EUR or USD, the payment settles on-chain in minutes, and the recipient holds the token or converts it to local currency. It changes the payment rail, not the employment relationship or its tax obligations.

The word "payroll" oversells it. Payroll for employees means withholding income tax, paying social contributions, issuing payslips and filing returns in the employee's country. You cannot do any of that without being registered as an employer there, either through your own entity or through an employer of record (EOR). A stablecoin transfer does none of it.

So in practice, "stablecoin payroll without a local entity" means one of two things: paying independent contractors directly, or paying through an EOR that itself funds or disburses in stablecoins. Everything else is marketing.

The honest size of the opportunity is also smaller than the headlines. BCG's analysis of on-chain real-economy payments puts business-to-individual payouts (contractor payments, creator earnings, refunds and rebates) at about 10% of stablecoin payment volume. It names the brakes: strong domestic fiat rails in developed markets, regulatory considerations and tax treatment (BCG and Allium, Stablecoin Payments: The Truth Behind the Numbers). Stablecoin payroll wins where a bank corridor is failing, not because the rail is new.

Three ways to pay a team abroad without an entity

Before choosing a rail, choose the legal structure. The rail follows from it.

For most companies reading this, row three is the relevant one: a contractor base spread across Asia, LatAm and non-euro Europe, paid monthly or per milestone. The mechanics of that row are covered in our practical guide to paying contractors and affiliates in USDC. This article covers the decisions around it.

Do you need a payroll platform, or just a payment rail?

Before choosing how to pay international contractors, ask a blunter question: what are you actually paying the intermediary for?

Contractor and payroll platforms such as 4DEV, Garna, Finboo and EasyStaff can do much more than move the money. Depending on the provider and the arrangement, they may handle contracts, invoices, closing documents and contractor administration. For a company that needs that layer, the service has real value.

Not every company does. Some already manage their contractor relationships themselves: the contracts are signed, the amount due is known, and nobody needs a third party to produce the supporting documents for each payment.

The cost of that layer is easy to miss. A typical contractor payment platform may charge around 3% for the service, with another 1–2% where currency conversion is required. That can bring the total cost of the flow close to 5%. For a company paying $1,000,000 a month to international contractors, the difference is material.

In this example, the payment flow through INXY costs 10x less, and in many payment flows the gap is 5x or more. The reason is the model, not a discount. A contractor platform sits between the company and the contractor and charges for the administrative layer around the transaction. INXY provides the infrastructure for the payment itself: you pay your contractors directly, and INXY handles conversion, the blockchain infrastructure, AML, KYT, transaction monitoring and reporting behind the scenes.

AI is making the administrative layer cheaper to run in-house. Creating one invoice was always easy. Creating hundreds of correctly structured invoices and payment records every month used to mean hours of repetitive finance work, which is why outsourcing the whole workflow made sense. AI and modern finance tools now automate much of the generating, checking and processing of that documentation. That does not remove legal, tax or employment obligations, but for a company that already manages its contractors internally, it changes the economics of paying a platform to do it.

So the question becomes: are you paying 3–5% because you need contractor administration, or because it was the easiest way to make the payment? If you need an EOR, employment administration, tax handling, contracts or local compliance support, use a provider that offers those services. If your contractors are genuine independent businesses, your contracts are in place and you can manage the documentation yourself, you may not need another company between you and the people you pay. You may only need a better payment rail.

The risk no payment vendor puts on the landing page

Paying someone in USDC does not make them a contractor. Classification depends on how the work is done: who controls the hours, whether the person is integrated into your organisation, whether they work only for you, and who carries the commercial risk. The currency of the invoice plays no part in it.

Someone paid the same amount on the same day every month, working your hours, with a company email address and a line manager, looks like an employee to a tax authority. That holds whether the money arrived over SEPA or TRON. A cheap, fast rail makes it easy to scale a contractor base in a country where you have no entity, and that is exactly when the classification question tends to get skipped.

For platforms, 2026 has a hard date. The EU Platform Work Directive, Directive (EU) 2024/2831, introduces a legal presumption of employment for people working through digital labour platforms where the facts indicate control and direction. The burden of rebutting that presumption sits with the platform. Member states must transpose it by 2 December 2026. For a freelance marketplace or payroll platform paying through stablecoin rails, this matters more this year than any crypto regulation does.

INXY Payments is payment infrastructure. We move, screen and settle the money; we do not determine anyone's employment status, and neither does any other payment provider. That decision belongs to you and your counsel, and it should come before the first batch, not after the first audit letter.

How the money moves: three legs, one of which you do not control

Every stablecoin payroll run has three legs. Most evaluations only look at the middle one.

Leg 1: funding, which runs on banking hours

You fund in EUR or USD from your company bank account. On INXY, conversion is automatic and your accounting stays in EUR or USD; the finance team never has to hold a wallet or pay gas.

The catch is timing. The chain settles 24/7, but your bank does not. To pay on Monday the 1st, the funding has to clear before Friday's banking cut-off. That means holding a pre-funded balance over the weekend: a small treasury float that nobody puts in the business case, and that every payroll calendar has to allow for.

Leg 2: on-chain settlement, which is the easy part

The transfer itself settles in minutes. The decisions are which token and which network.

On network, the market has already chosen for most corridors. BCG and Allium find TRON carries 60–80% of real-economy stablecoin payment flows, though its share fell from about 74% to about 60% across 2025 as Ethereum, Solana, BNB Smart Chain and Polygon gained. USDT on TRC-20 is still what most contractors in Asia and LatAm can receive and cash out locally. For EEA-facing counterparties, USDC is the practical default because it is authorised as an e-money token under MiCA. The trade-offs are covered in USDT vs USDC for business payments and what each USDT network actually costs.

INXY settles across 20 supported cryptocurrencies on ERC-20, TRC-20, BEP-20, Polygon, TON and other networks, so a single batch can pay each contractor on the network they actually use.

Leg 3: the payee's off-ramp, which sets their real pay

The contractor turns USDT into pesos, lira or rupiah through a local exchange, an OTC desk or a payment app. Their spread, their exchange's reliability and their bank's attitude to crypto-origin deposits all apply here, and you see none of it.

This is the leg that decides whether the programme lasts. A payout that is cheap on your side and expensive on theirs comes back six months later as a rate-increase request. Ask a sample of payees what they actually net after conversion, per corridor, before you roll out.

Who carries the exchange-rate move

Decide this in the contract, not on payday. There are three common set-ups:

• Invoice in EUR, pay the USDT equivalent at payout time. The contractor receives the EUR value; you carry the conversion.
• Invoice in USD, pay USDC one to one. Clean for USD-based companies. A company with EUR books carries the EUR/USD move.
• Invoice in the contractor's local currency. This gives you the most exchange-rate exposure and the most reconciliation work. Avoid it unless the contractor insists.

Running a stablecoin payroll batch: the sequence

This is the order that holds up under an audit. Steps 1–4 happen once per payee; steps 5–9 happen every cycle.

1. Classify and contract. A written B2B contract that states the invoice currency, the token and network of payment, who pays the network fee, and which exchange rate applies.
2. Onboard each payee. Collect identity data, the wallet address, the token and the network. The EU Transfer of Funds Regulation, Regulation (EU) 2023/1113, requires originator and beneficiary information to travel with crypto-asset transfers regardless of amount, with additional checks where a self-hosted wallet is involved. It implements FATF Recommendation 16. Collect this once, at onboarding, not at 17:00 on payday.
3. Verify the address with a test transfer, and confirm receipt through a channel other than the one the address came in on.
4. Put wallet changes behind a second channel. A new address takes effect only after a call or a confirmation in a separate, already-verified channel.
5. Fund the balance before the banking cut-off that precedes payday.
6. Build the batch. One row per payee, amounts in fiat or in tokens, uploaded as a file or sent by API.
7. Let validation and screening run. On INXY, a batch passes format checks, address and network compatibility checks, KYT screening of recipient addresses, and balance and exchange-rate checks before it can be executed. A flag here is a held payment, not a bug. Decide in advance who resolves it and how quickly.
8. Approve and execute, with a second approver for anything above a threshold you set.
9. Reconcile each payout and send each payee a statement showing the amount, token, network, transaction hash, and the fiat value and exchange rate used. Contractors need the fiat value at receipt for their own tax records. Sending it proactively costs less than answering forty emails in April.

For the batch mechanics in more depth, see mass crypto payouts.

What breaks in production

These are the failures that show up in month three, not in the demo.

The right address on the wrong chain. Ethereum, BNB Smart Chain and Polygon share the same 0x address format, so an address is valid on all three. A payee who watches only one chain reports a "missing" payout that is in fact sitting on another. With self-custody the funds can usually be reached; with an exchange deposit address that does not support that network, recovery is at the exchange's discretion. Put the network in the contract and in the batch file, and never infer it from the address format.

The wallet-change email. Shortly before payday, an email that appears to come from a contractor asks you to update their wallet. On-chain transfers cannot be recalled. Payroll redirection fraud already happens on bank rails; on a stablecoin rail, the second-channel rule in step 4 is the only control you have.

The payday screening hold. KYT flags a recipient address because an exchange deposit address has had indirect exposure to a risky counterparty. The hold is correct, but it lands at the worst moment. Screen at onboarding, re-screen before each batch, and tell affected payees before they notice.

Rate drift between preparing and approving. A fiat-denominated batch is prepared on Thursday and approved on Monday. By then the quote has expired, the re-quote changes the total, and the approver signs off a different number from the one the preparer built. Approve on the refreshed quote, not the original.

The payee's off-ramp disappears. A local exchange pauses withdrawals, or a payee's bank starts rejecting crypto-origin deposits. You paid on-chain on time, but in practice the contractor has not been paid. Keep a fallback rail on file for every payee.

Network fees broken out by chain. A batch that pays across three networks produces three different fee lines. If your ledger books a single "contractor payroll" line, someone will chase the difference every month. Map the network fee to its own account from the first run.

When stablecoin payroll is the wrong answer

This is the section a vendor would normally leave out, so here it is plainly.

• Your team is in the euro area and has EUR bank accounts. SEPA and SEPA Instant are cheap and fast, and every accountant understands them. Adding a token adds two conversions and gains nothing.
• Your people are employees. Use an EOR or your own entity. The rail is a detail; the employment obligations are not.
• Your payees are in the UK or the US. INXY Payments does not serve those markets. Both also have strong domestic rails, which removes most of the reason to switch.
• Your payees have no clean off-ramp. If the only way to cash out is informal peer-to-peer trading, you have not removed cost and risk; you have moved them onto the person you are paying.
• You pay three people once a month. Onboarding, screening set-up and wallet verification are a fixed cost. At that scale, the bank transfer you already have may simply be cheaper to run.

Stablecoin payroll earns its place where the bank rail is weakest: contractors across Asia and LatAm with long correspondent chains, countries your bank rejects or delays, payees who want dollar-denominated pay in a volatile local currency, and contractor bases of dozens to thousands paid on a fixed cycle.

Decision framework

Pick by payee, not by rail.

If the third, sixth or last row describes you, that is the problem INXY Payments is built for. You fund in EUR or USD. Payouts settle on-chain across the networks your contractors use. Each payout passes KYT, sanctions and Travel Rule screening before it leaves, with Elliptic and Sumsub in the compliance stack. Your books stay in fiat. Pricing is a transaction fee below 1%, with no setup, monthly or hidden fees. See how it works for crypto payroll and contractor payouts for global teams, or book a demo and bring your payee list. Knowing which corridors your team is actually in is usually enough to tell whether stablecoin payroll will pay for itself.

This article describes regulatory and market conditions for general information. It is not legal, tax, or financial advice — INXY Payments is a payment infrastructure provider, not a law or accountancy firm, and decisions with regulatory consequence should be reviewed by qualified counsel in the relevant jurisdiction.

FAQ

Is it legal to pay contractors in USDC or USDT?

In many jurisdictions, paying an independent contractor in a stablecoin is permitted when both parties agree to it in the contract. How the contractor must report that income, and at what fiat value, varies by country and changes over time. Check the position for each country where you have contractors with qualified counsel, and give every payee the fiat value at receipt.

Can I pay employees in stablecoins?

Employee pay is governed by local wage, tax and social-security rules, and many countries regulate the form in which wages can be paid. Withholding obligations apply whatever the payment method. If you have employees in a country without a local entity, use an employer of record. Some EORs work with stablecoins, but the employer obligations stay with the EOR.

Do I need a local entity to pay contractors in stablecoins?

No, not for genuine independent contractors on a B2B contract. You need an entity or an EOR if the people are in fact employees, and the payment rail does not change which one they are. Classification depends on control, integration and exclusivity, not on whether the invoice is paid over SEPA or on-chain.

Should stablecoin payroll use USDT or USDC?

Use whichever token each payee can actually receive and convert locally. In most of Asia and LatAm that is USDT, commonly on TRC-20. For counterparties in the EEA it is USDC, which is authorised as an e-money token under MiCA. Many contractor programmes run both and record each payee's token and network at onboarding.

How do contractors convert stablecoins to local currency?

Through a local exchange, an OTC desk or a payment app that supports withdrawal to a local bank account. The conversion spread is paid by the contractor and is invisible to you, so ask a sample of payees what they net after conversion in each corridor. An off-ramp that is expensive for them eventually shows up as a higher rate for you.

How fast is stablecoin payroll?

The on-chain transfer typically settles within minutes and runs 24/7. The slower legs are at either end: your fiat funding, which follows banking hours and cut-offs, and the payee's conversion to local currency. Fund before the last banking day ahead of payday so the batch can run on schedule.

A payout batch does not fail loudly. It fails as fourteen rejected rows out of 3,000, a Friday afternoon, and a finance lead reconciling by hand on Saturday. Choosing a mass payout platform is a choice about which failure mode you are willing to own. This article compares the three architectures on the market — fiat mass-payout software, crypto-native payout providers, and hybrid stablecoin rails — on published pricing, corridor reach, settlement timing and what each one costs you when it goes wrong.

Competitor pricing and product capability in this article were read from each vendor's own published pricing, product and support documentation on 15 and 17 September 2026. Every platform named was checked for a published bulk-payout product, not just a payment gateway. Payment pricing changes constantly — re-check every figure before you quote it in a business case.

What a mass payout platform actually is — three architectures, not one market

The phrase "best mass payout platform" returns three different product categories that solve overlapping problems in incompatible ways. Confusing them is the most common reason a procurement process ends with the wrong tool.

Fiat mass-payout software (Tipalti, Trolley, Payoneer, Wise Business, PayPal Payouts) sits on top of correspondent banking and card networks. It automates payee onboarding, tax-form collection, approval workflow and AP reconciliation, then hands the actual value transfer to banks. Its strength is the workflow and the accounting integration. Its constraint is the rail underneath: where the bank cannot go, the software cannot go either.

Crypto-native payout providers (CoinGate, NOWPayments, Cryptomus and similar) move value on-chain. The rail is fast and geographically indifferent. The surrounding product, however, is usually built first for merchants accepting payments, with payouts added alongside — sometimes as a well-documented module, sometimes as a page you have to go looking for. Payee experience frequently assumes the recipient already holds a wallet, or is willing to open an account somewhere to receive one.

Hybrid stablecoin rails (INXY Payments, BVNK and others in this category) settle on-chain but present a fiat-denominated product: you fund in EUR or USD, the recipient receives value, and your chart of accounts never leaves fiat. INXY's own framing is wallet-free, gas-free, blockchain-free — the buyer is not being sold exposure to a cryptoasset, they are being sold a settlement rail.

The architectural question is simple and it comes before the vendor question: is your payout problem a workflow problem, a corridor problem, or both? Workflow problems — approvals, tax forms, ERP sync, multi-entity AP — are solved well by fiat software. Corridor problems — payees in markets your bank declines, five-day settlement, payouts that arrive net of three intermediary deductions — are not solved by better software on the same rail.

The eight criteria that actually decide it

Most comparison articles rank on headline fee. Headline fee is rarely the variable that decides whether a payout stack works.

The two questions in that table that vendors answer worst are reconciliation output and failure semantics. Ask them first.

Fiat mass-payout platforms: strong workflow, inherited rail

Tipalti

Tipalti is AP automation with a mass-payments module attached, and it is genuinely good at the part most crypto providers ignore entirely: supplier onboarding, tax-form collection, approval hierarchies and ERP synchronisation. Published pricing starts at $99/month for Accounts Payable and $249/month for Mass Payments (tipalti.com/pricing, read 15 September 2026). Per-invoice and per-payment transaction fees exist but are not itemised publicly; FX is described as built into the payment workflow rather than quoted as a separate spread.

Where Tipalti loses: a company paying 2,000 small-value affiliates monthly in markets its bank underwrites poorly. The subscription plus per-transaction economics are built for a supplier ledger of hundreds, not a payee ledger of thousands, and the underlying rail still has to reach the payee.

Payoneer

Payoneer's advantage is the network: where both sides hold accounts, value moves inside the network rather than across correspondent banking. Published fees include fixed bank withdrawal fees of 1.50 USD, 1.50 EUR or 1.50 GBP for local-currency withdrawals, 0.5% of the withdrawal amount above a $50,000 monthly threshold, up to 3% for non-local currency transactions, and a 29.95 USD annual fee on dormant accounts (payoneer.com/about/pricing, read 15 September 2026).

Where Payoneer loses: the "up to 3%" non-local-currency line is where the money goes, and it is borne by the payee. If your payees are price-sensitive contractors converting to local currency, the deduction they see is the number that generates support tickets — not your platform fee.

Wise Business

Wise publishes the most transparent FX pricing in the category: conversion from 0.24%, with a mid-market reference rate, free domestic payments in nine listed currencies, and named receive fees for SWIFT inbound (6.11 USD, 2.16 GBP, 2.39 EUR) plus a 50 GBP one-off charge for receiving-account details (wise.com/gb/pricing/business, read 15 September 2026).

Where Wise loses: high-risk verticals. Wise underwrites its customer book conservatively, and ad networks, iGaming affiliates and some marketplace models find the account itself is the constraint — not the pricing. A cheap rail you get offboarded from in month seven is more expensive than a slightly dearer rail you keep.

PayPal Payouts

PayPal Payouts applies a variable fee of 2%, with caps that vary by sending country and by domestic versus international payout type; currency conversion is charged additionally (developer.paypal.com/payouts/fees, read 15 September 2026). Per-payout transaction limits are published by currency — for example $60,000 for registered USD recipients and $20,000 for unregistered ones.

Where PayPal loses: anything with a real corridor problem. The capped 2% is competitive for small payouts into well-served markets and uncompetitive for large ones; recipient-side availability and account holds are the operational risk, and they are not visible in the fee table.

Crypto-native payout providers: right rail, merchant-shaped product

CoinGate

CoinGate publishes the clearest crypto payout pricing in the comparison set: 1% per transaction on the Standard plan, crypto payouts at 0.50 EUR + 0.5%, or 0.50 EUR + 1.5% where conversion is involved, free SEPA and crypto withdrawals above a 50 EUR minimum, 0.50% on SWIFT withdrawals, and a 1% exchange fee on manual conversions (coingate.com/pricing, read 15 September 2026).

Its bulk capability is Batch Payouts: a CSV upload capped at up to 300 payouts per file, available to verified business accounts only, charged as a fixed 0.50 EUR plus a percentage that depends on whether a conversion was applied, with no minimum per individual payout and an optional four-eye approval step before a batch executes (CoinGate support documentation, read 17 September 2026).

Where CoinGate loses: the 300-row cap. A 3,000-payee affiliate run becomes ten CSV files, ten approvals and ten reconciliation artefacts — which is not a pricing problem, it is an operational one, and it is invisible on the pricing page. CoinGate also ships the strongest control in the crypto-native set, the four-eye approval, so the honest reading is that it is built for controlled, moderate-volume batches rather than for scale.

NOWPayments

On acquiring, NOWPayments publishes 1% for payments without exchange and 1.5% for multi-currency, fixed-rate or "fee paid by user" payments, with network fees passed through as variable blockchain cost (nowpayments.io help centre, read 15 September 2026).

Its mass payout product is headlined "Zero-fee crypto mass payouts", scaling from 1 to 100,000 recipients by CSV upload or API, and is powered by ChangeNOW. The mechanism behind the zero is the part that matters: each recipient is given a ChangeNOW account, into which the payout lands (nowpayments.io/mass-payments, read 17 September 2026).

Where NOWPayments loses: that recipient account is a real constraint, not a detail. You are asking every payee to onboard to a third-party exchange to receive their money, which moves your payee-support burden onto someone else's KYC queue and someone else's supported-country list. For an affiliate base that already uses it, that is free scale. For a contractor base that does not, it is the highest-friction option in this comparison.

Cryptomus

Cryptomus does not surface mass payouts among the headline products on its homepage — the navigation leads with the payment gateway, cards and trading — but it publishes a dedicated Mass Payouts product page and a payout API. The page advertises batches by file upload or API, states no restriction on the number of addresses, claims "100,000+ transactions in 3 clicks", and publishes "Commissions — 0%" (cryptomus.com/mass-payout, read 17 September 2026).

Where Cryptomus loses: the same place its headline wins. A published 0% commission on a payout product means the cost lives somewhere else — network fee treatment, conversion spread, or the balance you have to hold on-platform to fund the batch. None of those are quantified on the page. A rate you cannot model is not cheaper than a rate you can; it is just unpriced until the first invoice.

Two zeros, one lesson. Both Cryptomus and NOWPayments headline their payout products at zero fee, and neither publishes what replaces it. That is not an accusation — it is the reason the "line items nobody quotes" section below exists, and the reason your evaluation should price a real batch rather than compare headline rates.

Hybrid stablecoin rails: fiat in, fiat out, on-chain in the middle

This is the category INXY Payments operates in, so read the following knowing where it comes from.

The hybrid model exists because the two categories above each solve half the problem. Fiat software gives you workflow and accounting on a rail with corridor limits. Crypto-native gives you the rail without the finance-team product. Hybrid rails fund in fiat, settle on-chain, and deliver in a form the payee can use, with the accounting staying denominated in EUR or USD.

INXY's published position is a transaction fee from 0.1% with no setup, monthly or hidden fees, and reduced rates available for large volumes, same-day global settlement with next-day fiat to bank, and no chargebacks — a structural property of the rail rather than a policy, because there is no card scheme representment process to lose. Compliance screening runs through partners including Elliptic and Sumsub, with Travel Rule and AML handling built into the flow rather than bolted on. INXY supports 20 cryptocurrencies across ERC-20, TRC-20, BEP-20, Polygon, Tron, TON, Bitcoin, Litecoin and DOGE.

Where INXY loses — and this matters more than anything above it. If your payout problem is a domestic one — 400 suppliers in a single SEPA country, paid monthly, with invoice matching and approval chains as the real work — a stablecoin rail solves a problem you do not have. SEPA Instant already settles in seconds at near-zero cost, and what you actually need is AP automation. Buy Tipalti. Similarly, if your payees are consumer-grade recipients with no appetite for anything unfamiliar and your corridors are all well-served, the migration cost outweighs the settlement gain. INXY is the right answer when the corridor is the constraint, the volume is real, and the settlement delay is costing you working capital — not when the workflow is the constraint.

The geographic constraint is not a footnote. INXY serves Europe, Asia and LatAm and does not serve the UK, the US, or sanctioned jurisdictions. If a material share of your payee base sits in those markets, this rail does not solve your problem regardless of how well it prices, and no vendor including us should sell you around that.

The comparison table

Figures as published by each vendor on 15 September 2026, with the crypto-native payout rows re-checked and expanded on 17 September 2026. "Not published" means the vendor does not disclose the figure — not that the cost or the limit is zero.

The line items nobody quotes

Five costs sit outside every pricing page in the table above, and together they usually exceed the headline fee.

Pre-funding float. If the rail requires you to pre-fund a balance before a batch executes, you are lending the provider working capital. On a monthly payout run of 1.2M EUR with a three-day funding lead, that is three days of capital cost every month, permanently. Ask what the funding-to-execution window is and treat it as a financing line, not an operational detail.

FX spread versus mid-market. A "0.5% fee" applied to a rate already marked 0.8% off mid-market is a 1.3% cost. Wise publishes against the mid-market rate explicitly; most of the others do not. Always benchmark the rate you are quoted against the mid-market rate at the same timestamp, not against the previous vendor's rate.

Network fee pass-through. On-chain payouts carry a network fee that varies with congestion. Whether the provider absorbs it, passes it through at cost, or marks it up is a real commercial term and it is rarely on the pricing page. On a 3,000-row batch, a few cents of markup per row is not a rounding error. This is usually where a "0% commission" payout product recovers its margin — both Cryptomus and NOWPayments headline their payout products at zero fee, and neither publishes the network-fee or spread treatment that sits behind it.

Failed-payout rework. The genuine cost of a failed row is not the fee — it is the finance analyst who investigates it, contacts the payee, corrects the record and re-submits. At a 2% failure rate on a 3,000-payout batch, that is 60 manual investigations per run. Ask every vendor for their observed first-attempt success rate on your corridor mix, in writing.

Payee-side deduction. The number that determines whether your affiliates complain is what lands in their account, not what leaves yours. Intermediary bank deductions on SWIFT and non-local-currency conversion charges are invisible in your reporting and highly visible in theirs.

What breaks in production

Partial batch failure with unclear semantics. The batch reports "completed," 2,946 of 3,000 rows settled, and the report does not distinguish rows that failed validation from rows that were submitted and rejected downstream. Rerunning the file double-pays the 2,946. This is why idempotency keys on payout requests are a procurement requirement, not a developer preference.

Wrong-network sends. A payee supplies an address and selects the wrong network. On stablecoin rails this is the single most common payee-side error. The mitigation is product-level — network selection derived from the payee's own confirmed profile rather than free-text entry — and it is worth more than a 0.1% fee difference.

Screening true positives mid-batch. A payout hits a sanctions or KYT match. The correct behaviour is that the payout stops, is escalated for review, and the rest of the batch proceeds. Some platforms halt the entire batch. Ask which, before you find out on a payout Friday. And to be unambiguous: the right answer is that the payout stops and is reviewed. Any provider positioning reduced screening as a feature is selling you a future enforcement problem, not a payment rail.

Month-end reconciliation drift. Settlement timestamps in the provider's timezone, FX applied at execution rather than at approval, and fees netted rather than itemised — three small mismatches that produce an unexplained variance line every single month. Demand the row-level export during evaluation and hand it to whoever closes your books before you sign.

Payee onboarding decay. Payee details go stale. Bank accounts close, addresses rotate. A platform with no re-verification prompt accumulates a growing tail of failing rows that nobody owns.

An eleven-step evaluation sequence

1. Export your last three payout runs and build the real distribution: payee count, value distribution, country mix, currency mix, and observed failure rate. Most teams discover their average payout is far smaller and their corridor list far longer than they assumed.
2. Classify the problem: workflow-constrained, corridor-constrained, or both. This eliminates two of the three architectures immediately.
3. Request a corridor decline list from each shortlisted vendor, by country and method. Not a coverage map — a decline list.
4. Price the real batch, not a sample: all-in cost including FX spread benchmarked to mid-market at the same timestamp, network fees, and any pre-funding requirement expressed as days of float.
5. Ask for the per-batch row limit and what happens at it. A cap of 300 against a 3,000-row run means ten files, ten approvals and ten reconciliation artefacts every cycle. Get the number in writing; it is rarely on the pricing page.
6. Ask for failure semantics in writing: atomic or per-row, idempotency support, retry model, and what happens to a batch when one row hits a screening match.
7. Run a sandbox batch of at least 50 rows covering your three hardest corridors, including deliberately malformed rows.
8. Hand the settlement export to your controller before the commercial conversation goes further. If it does not map to the chart of accounts, the integration cost is a hidden line item.
9. Test the payee path yourself, end to end, as a payee in your largest corridor. Time it. Count the steps. Include any account the payee is required to open — if receiving your payout means onboarding to a third-party exchange, that is part of your payout product whether you chose it or not.
10. Verify the compliance posture: KYB depth, which screening runs pre-send, Travel Rule handling, and how a true positive is escalated. Our guide to Travel Rule and crypto payouts covers what actually runs.
11. Run one real batch in parallel with your incumbent for a full cycle before migrating. Parallel running costs one month of double fees and saves one quarter of remediation.

Which one, when

If your batch is mostly USDT and the corridor is the constraint, the mechanics are set out in mass payout in USDT, and the same flow for dollar-denominated payees who require a MiCA-authorised token is in mass payout in USDC. For contractor and payroll-shaped batches specifically, crypto payroll and contractor payouts is the relevant page, and how to automate mass crypto payouts covers the automation layer.

The decision, stated plainly

Do not start from the vendor list. Start from your own last three payout runs, because the distribution in that export determines the architecture, and the architecture eliminates most of the market before you speak to anyone. If the constraint is workflow, buy AP automation and stop reading comparison articles about stablecoins. If the constraint is the corridor — payees your bank will not reach, settlement measured in days, deductions you cannot see — then the rail has to change, and the only question left is whether you want the on-chain complexity on your side of the wall or the provider's.

If it is the second, the shortest useful next step is a scoped batch against your real corridor mix rather than a demo against theirs. Book a demo with your last payout export in hand, and ask for the row-level settlement report before anything else.

This article describes regulatory and market conditions for general information. It is not legal, tax, or financial advice — INXY Payments is a payment infrastructure provider, not a law or accountancy firm, and decisions with regulatory consequence should be reviewed by qualified counsel in the relevant jurisdiction.

FAQ

What is a mass payout platform?

A mass payout platform executes many outbound payments from a single instruction — a file upload or an API call — instead of one payment at a time. The category covers three architectures: fiat AP automation software, crypto-native payout providers, and hybrid stablecoin rails that fund in fiat and settle on-chain. They solve different problems and are not interchangeable.

How much does a mass payout cost?

Published headline fees across the platforms compared here range from zero-fee headlines on some crypto payout products to a capped 2% per payout, as published by each vendor in September 2026. The headline fee is rarely the largest cost. FX spread against mid-market, network fee pass-through, pre-funding float and failed-payout rework typically add more than the quoted rate.

Are crypto mass payouts faster than bank transfers?

On-chain settlement completes in minutes rather than the multi-day window typical of correspondent banking, and it does not observe banking hours or cut-off times. The constraint moves from the rail to compliance screening and payee-side availability, which is why pre-send screening design matters more than raw block time.

What happens if one payment in a batch fails?

It depends entirely on the platform's failure semantics, and this is the question most buyers skip. Some platforms process per-row and continue; others halt the batch. Ask for the behaviour in writing, confirm that payout requests support idempotency keys, and test it with deliberately malformed rows in a sandbox before go-live.

Which stablecoin should we use for payouts?

It depends on where your payees are and what their counterparties accept. USDT has the deepest liquidity and the widest informal acceptance in Asia and LatAm; USDC is authorised as an e-money token under MiCA and is the practical choice for EEA-facing counterparties. Many payout programmes run both rather than choosing.

Can we keep our accounting in EUR if we pay out in stablecoins?

Yes, on a hybrid rail. You fund in fiat, the provider handles conversion and on-chain settlement, and the settlement report returns in your base currency. Insist on a row-level export with FX rate and fee broken out per payout — if the export does not map to your chart of accounts, you have bought a data-entry job.

Accepting USDT is a two-day integration and a six-month operational commitment. The integration is the easy part: a checkout call, a webhook endpoint, a settlement report. What takes longer is everything after go-live — underpayments, wrong-network sends, a webhook that fired three times, and a finance team asking why the settlement total does not match the order total. This guide covers the full path: sandbox to production, webhook handling that survives retries, reconciliation, chart-of-accounts mapping, and the failures that show up in week three.

Decide the model first: direct wallet, gateway, or converted settlement

This decision determines everything downstream, and reversing it later means re-doing the reconciliation.

Direct wallet acceptance. You generate an address, the customer sends USDT, you hold USDT. No provider fee — but you now own address generation, network monitoring, confirmation logic, underpayment handling, refunds, key custody, KYT and sanctions screening. For most businesses that is not a saving; it is an unstaffed payments team.

Gateway with crypto settlement. The provider handles checkout, addresses and confirmation, then settles USDT to your wallet. You keep the token, the price exposure and a cryptoasset on your balance sheet.

Gateway with fiat settlement. Same checkout flow, but the provider auto-converts at confirmation and settles EUR or USD to your bank. Your ledger never holds a cryptoasset and your exposure window is minutes rather than days.

For most merchants the third option is correct, and the reason is not technical: the first two push a treasury and compliance function into a company that did not plan to have one. Crypto payment gateway vs processor sets out how the roles differ. The rest of this guide assumes a gateway integration with fiat settlement — the flow INXY Payments runs across 20 supported cryptocurrencies with next-day bank settlement.

Pick the networks before you write code

USDT is one token on several networks, and they are not interchangeable. A customer who sends TRC-20 USDT to an ERC-20 address has lost the funds, and no amount of support can recover them.

The practitioner's rule: support the networks your payers actually use, not every network you can. Each extra network is another address type, confirmation rule, support queue and reconciliation column. Start with two. How USDT network fees compare has the cost detail.

Confirmation depth is a commercial decision, not a technical one. Crediting at one confirmation is fast and carries reorg risk; waiting for finality is safe and costs the customer minutes. For instantly delivered digital goods most merchants credit at the provider's standard depth; for anything irreversible and high-value, wait for finality. Decide it explicitly and check that your provider's default matches.

The integration sequence: sandbox to production in nine steps

1. Complete KYB before you write anything. Gateway onboarding requires company documents, UBO identification, a description of your business model and often your website in a reviewable state. It is the longest-lead item in the project and teams routinely start it last. How to verify a merchant account sets out what is collected.
2. Get sandbox credentials and read the invoice lifecycle. Every gateway models a payment as an object with states — created, pending, underpaid, confirmed, expired, failed. Map those states to your own order states on paper before you write code. Most integration bugs are state-mapping bugs.
3. Create a payment on the server side, never the client. The amount, currency, order reference and callback URL are set by your backend. A client-settable amount is an open invitation, and it is the single most common security defect in crypto checkout integrations.
4. Handle the rate lock window explicitly. The gateway quotes a USDT amount against your fiat price and holds it for a fixed window. If the customer pays after expiry, the payment arrives short or long in fiat terms. Display the countdown, and decide in advance whether an expired-but-paid invoice is auto-recredited or manually reviewed.
5. Build the webhook endpoint before the checkout page. It is the part that carries the risk, and it needs to exist before you can test anything end to end. Details in the next section.
6. Test the failure cases, not the happy path. In sandbox, deliberately produce: an underpayment, an overpayment, a payment after invoice expiry, a duplicate webhook delivery, an out-of-order webhook delivery, and a webhook your endpoint rejects with a 500. If you have not seen all six in sandbox, you will see them in production instead.
7. Wire up the settlement report and hand it to finance before go-live. Not after. If the export does not carry, per row, the order reference, the gross fiat amount, the fee, the FX rate applied and the settlement date, your month-end will not close cleanly. This is the step teams skip and regret.
8. Go live with one network and a payment cap. Cap the maximum invoice value for the first two weeks. It converts a potential six-figure incident into a three-figure one while your confirmation and reconciliation logic proves itself.
9. Reconcile manually for one full cycle. Match every settlement line to an order by hand for the first month. It is how you find the edge case in your state mapping while the volume is still small enough to fix.

Webhook handling: five rules that prevent the expensive bugs

The webhook is where a payment integration succeeds or quietly breaks. Treat it as an untrusted network endpoint that will be called more than once, out of order, and occasionally by someone who is not your provider.

1. Verify the signature before parsing anything. Compute the expected signature over the raw request body — not a re-serialised object, because re-serialisation changes byte order and the signature will not match — and compare in constant time. Reject and log failures.

2. Make the handler idempotent. Key on the provider's payment identifier, not your order ID. Record processed identifiers and return success without re-processing. Webhook delivery is at-least-once by design, so retries are normal, and a non-idempotent handler will credit the same order twice.

3. Never treat the payload amount as your source of truth. Verify server-side against the provider's API before fulfilling. A signature proves the message came from your provider; fetching the object proves the current state.

4. Respond fast, process asynchronously. Return 2xx as soon as the event is persisted, then fulfil on a queue. Inline fulfilment times out under load, the provider retries, and you are back to rule two.

5. Do not assume ordering. A confirmed event can arrive before the pending event preceding it. Drive order state from the event's own state field and a timestamp, never from arrival order.

And make sure the endpoint is reachable. IP allowlists, WAF rules and leftover staging basic-auth are a recurring go-live failure. Confirm delivery from the provider's dashboard on day one, not from your own logs.

Reconciliation and chart-of-accounts mapping

This is the part that determines whether your finance team supports the project in month three.

With fiat settlement, a USDT payment produces three distinct economic events that arrive at different moments: the customer's on-chain payment, the conversion to fiat, and the bank settlement. If your ledger treats them as one event, you will carry an unexplained variance every month.

A mapping pattern that works in practice:

The clearing account is the control. It should net to zero once every batch has settled, and a persistent non-zero balance tells you exactly where the break is — unsettled, unmatched, or mis-rated. Without it, differences disappear into revenue and nobody finds them until audit.

Four requirements to put in the provider evaluation, not discover afterwards:

• Row-level settlement export with order reference, gross amount, fee, FX rate and settlement timestamp on every line.
• A stable order reference that survives from invoice creation to bank settlement. If the reference is lost at conversion, matching becomes manual.
• Consistent timezone handling. A settlement timestamp in the provider's timezone against orders in yours produces month-end cut-off differences every single period.
• Fees itemised, not netted. A net figure hides the fee and makes cost analysis impossible.

Accounting treatment for digital assets varies by jurisdiction and by reporting framework, and it changes. The mapping above is an operational pattern, not accounting or tax advice — confirm the treatment with your own auditors before you book it.

What breaks after go-live

Underpayments. The customer sends slightly less than invoiced, usually because their wallet deducted the network fee from the amount rather than adding it. Decide the policy before it happens: auto-accept below a tolerance threshold, hold for review above it, and make the threshold a configuration value rather than a code change.

Wrong-network sends. The dominant support burden in USDT acceptance. Mitigate at the interface: show the network prominently, use network-specific QR codes, never present a bare address without its network label, and put the warning next to the address rather than at the bottom of the page.

Duplicate order creation. A customer refreshes checkout and generates a second invoice for the same order, then pays the first one. Your order is now linked to an unpaid invoice. Key invoice creation on the order ID and return the existing invoice instead of creating a new one.

Refunds are outbound payments, not reversals. There are no chargebacks on this rail — a structural property, since there is no card scheme representment process — which removes a large category of loss. It also means a refund is a new payout to an address the customer supplies, with its own screening, its own network fee and its own operational process. Design the refund flow during integration, not on the first request.

Expired-invoice payments. A customer pays an hour after the rate window closed and the fiat value no longer matches the invoice. Without a written policy this lands on a support agent with no authority to decide it.

Staging credentials that outlive staging. Sandbox keys left in a production environment variable, or a production endpoint still pointing at a dev URL. Verify both directions on go-live day.

The decision framework

Do not start with the API documentation. Start with three questions, in this order:

1. Where do your payers sit, and what network do they already use? A payer-data question, not an engineering one, and it settles which networks you support.
2. Do you want a cryptoasset on your balance sheet? If no — and for most merchants the answer is no — the model is fiat settlement, which removes most of the treasury and accounting complexity before it exists.
3. Who owns reconciliation? If the answer is “we'll work it out after launch,” involve finance now. Every integration that goes badly goes badly at month-end, not at go-live.

Get those three right and the integration is a short piece of work. Get them wrong and no amount of clean code fixes it.

Where this is not the right answer: if you sell primarily to domestic consumers in a well-banked market with working card acceptance and a low decline rate, adding USDT acceptance will produce a small share of volume and a real amount of operational overhead. Stablecoin acceptance earns its keep when cards are failing you — regional declines, chargeback ratios threatening your acquirer relationship, or cross-border settlement measured in days. If none of those describe you, the honest answer is that this is not your priority this quarter.

If they do describe you, the fastest path is a sandbox integration against your real checkout flow rather than a proof of concept. Get started for credentials, or book a demo if the reconciliation model is the part you need to settle first. For the developer-side detail, integrating a crypto payment API goes deeper on the API surface, and checkout design that converts covers the payer-facing half.

This article describes regulatory and market conditions for general information. It is not legal, tax, or financial advice — INXY Payments is a payment infrastructure provider, not a law or accountancy firm, and decisions with regulatory consequence should be reviewed by qualified counsel in the relevant jurisdiction.

FAQ

How do I accept USDT payments on my website?

Integrate a crypto payment gateway: create the payment server-side with the fiat amount and order reference, display the gateway's checkout with the correct network, verify the signed webhook when the payment confirms, and settle either in USDT or converted to fiat. Most merchants choose fiat settlement so no cryptoasset touches the balance sheet.

Which USDT network should I accept?

Support the networks your payers already use rather than all of them. TRC-20 is the common default for low-value, high-volume checkout, with ERC-20 added where counterparties require it. Each extra network adds address handling, confirmation rules, support load and a reconciliation column, so start with two.

How long does a USDT payment take to confirm?

It depends on the network and your chosen confirmation depth. On Tron, a block is solidified in about a minute once at least 19 of 27 active super representatives have built on it. On Ethereum, finality is reached across checkpoint epochs — roughly 13 minutes. Many merchants credit earlier and accept the residual risk.

What happens if a customer underpays?

The gateway marks the payment underpaid rather than confirmed. Set a tolerance threshold in advance: auto-accept small shortfalls, hold larger ones for review. Underpayment is usually caused by a wallet deducting the network fee from the sent amount rather than adding it, so it is common rather than exceptional.

Are there chargebacks on USDT payments?

No. On-chain settlement has no card scheme representment process, so the chargeback category of loss does not exist. Refunds still do — but a refund is a new outbound payment to an address the customer supplies, with its own screening and network fee, so the refund flow needs designing during integration.

How do we reconcile USDT payments in our accounting?

Route everything through a settlement clearing account. The on-chain payment, the conversion and the bank settlement are three separate events arriving at different times; the clearing account should net to zero once a batch has settled, and any residual balance points straight at the break. Require a row-level export with fee and FX rate per line.

The TRC20 vs ERC20 question is usually answered with a fee table and left there. That answer is incomplete in a way that costs money at volume: the three networks price transactions using three different mechanisms, reach settlement finality on three different timescales, and fail in three different ways when they get busy. If you are sending one transfer, pick the cheapest. If you are sending a payout batch of four hundred, the cheapest network is frequently the wrong one, and this article explains exactly when.

‍

What the three standards are

Snippet target. TRC-20, ERC-20 and BEP-20 are token standards on three separate blockchains — TRON, Ethereum and BNB Smart Chain. The same USDT exists as a different token contract on each, and the balances are not interchangeable without a bridge or an exchange. Choosing a network means choosing that chain's fee model, confirmation speed and liquidity, not a different kind of dollar.

‍

The critical consequence: a USDT balance is chain-specific. Sending BEP-20 USDT to a TRC-20 address is not a slow transfer, it is a transfer to a different network entirely, and whether the funds are recoverable depends on who controls the keys at the destination.

‍

The fee models are not comparable

This is the part fee tables flatten. Each chain charges for a different scarce resource.

Ethereum (ERC-20) — an auction for block space

Ethereum's total fee is "units of gas used * (base fee + priority fee)" (ethereum.org). The base fee is set by the protocol and adjusts with demand: it "will increase or decrease by a maximum of 12.5% per block if the target block size is above or below the target", and once the block is created "this base fee is 'burned', removing it from circulation" (ethereum.org).

‍

A standard ERC-20 transfer consumes roughly 65,000 gas, and around 90,000 from an address that has never held the token (Eco, data pulled 13 May 2026). The same transfer therefore costs approximately $0.30 at 2 gwei, $1.50 at 10 gwei, $4.50 at 30 gwei and $12 at 80 gwei (Eco, 13 May 2026).

‍

The operational point is not the average — it is the variance. A 12.5% per-block move compounds fast. Your treasury model has to survive the 80 gwei day, not the 2 gwei day.

TRON (TRC-20) — a resource you rent, not a price you pay

TRON does not run a gas auction. It meters two resources: Bandwidth, which "covers the byte size of transactions stored on-chain", and Energy, which "covers the computation the TVM performs when executing a smart contract" (TRON developer docs). Every account gets "a free 600 Bandwidth daily quota" and no free Energy at all. A USDT transfer needs roughly 345 Bandwidth, so the free quota covers the Bandwidth leg of about one transfer a day and contributes nothing to the Energy leg, which is where the money is.

‍

A USDT TRC-20 transfer consumes roughly 64,285 Energy to a recipient already holding USDT, and roughly 130,285 Energy to a recipient whose USDT balance is zero.

‍

The doubling is triggered by a zero balance, not by a new address — and this is where most articles get it wrong. The trigger is not history but the balance at the moment of the transfer: if the recipient has never received USDT or its USDT balance is currently zero, the write creates a new storage slot in the token contract rather than updating an existing one, and storage creation on the TVM costs roughly double. A contractor who sweeps their wallet to an exchange after every payment therefore lands on the expensive tier every single time, not once. In a payout batch to freelancers — who by definition empty their wallets — the 130,285-Energy tier is the default case, not the exception. Budget the batch on the high tier and treat the low tier as upside.

Three ways to pay for Energy, and what each actually costs

‍

Self-staking is a treasury position, not a fee discount. Energy from staking is allocated by "the proportion of your staked TRX relative to the total TRX staked across the entire network for that resource" (TRON developer docs). There is no fixed TRX-per-Energy rate — the amount you must lock to cover a given number of transfers moves with how much everyone else has staked, so any figure you read is a snapshot of a market, not a protocol constant. At the ratios prevailing through 2026, covering a single 65,000-Energy transfer per day has required staking on the order of 13,000 TRX. Exit is slow: "The unstaked TRX enters a 14-day pending period before it can be withdrawn" (TRON developer docs). Staked TRX does carry TRON Power at 1 TP per TRX, but the docs are blunt that "Unused TP earns you nothing — voting is what generates rewards", so any offset against the locked capital requires actively voting for Super Representatives and is not a return on the stake itself. TRONSCAN's Resource Calculator will price a given stake against current network conditions before you commit.

‍

Renting Energy is the part almost nobody writes up. A market exists of operators who stake TRX at scale and resell the resulting Energy, delegated to your address for a fixed window, priced in TRX well below the burn cost. For a business running a few hundred payouts a month this is materially the cheapest route, and unlike staking it locks up no capital.

‍

Here is what a rental vendor will not put on their pricing page. You are inserting an unregulated counterparty into the execution path of a payment. The delegation itself is benign, but your batch now depends on that operator being available at the moment it runs, you are paying them in TRX, and for a regulated payment business that dependency sits inside a process compliance will eventually ask about. Rented Energy is usually the right answer for a merchant optimising their own treasury. It is a much harder answer for a licensed provider executing client payouts at volume — which is one reason INXY abstracts the resource question away entirely rather than handing the merchant a rental dependency to manage.

‍

TRON also caps contract execution with a fee_limit, and the docs are explicit that "a sufficient account balance alone does not guarantee execution". A batch can fail on a fee limit set months earlier while the account is fully funded.

BNB Smart Chain (BEP-20) — cheap, fast, and structurally different

BEP-20 uses an Ethereum-style gas model at much lower prices. A USDT BEP-20 transfer consumes "around 50,000 to 65,000 gas" at "typical gas prices of 1 to 5 gwei in BNB", putting end-to-end fees in "the $0.10 to $0.30 range for a basic transfer at retail demand levels" (Eco, 2026).

‍

The chain itself changed materially in 2025. The Maxwell hardfork went live on mainnet on 30 June 2025, "reducing block times from 1.5 seconds to 0.75 seconds", with "Fast Finality... now achievable in ~1.875 seconds" (BNB Chain, 2025). That is the fastest published finality of the three.

‍

Comparison table

‍

Chain-share figures: BCG / Allium, Stablecoin Payments: The Truth Behind the Numbers. Cost figures carry their own capture dates above; verify against a live explorer before committing a large batch.

‍

Finality time by chain, and what "confirmed" means

"Confirmed" and "final" are different states, and conflating them is how a reconciliation goes wrong.

‍

• TRON produces a block every 3 seconds across 27 Super Representatives. A block is solidified "once at least 19 distinct active SRs have each produced a block at that height or above", which takes "about 1 minute" under normal conditions (TRON developer docs). Before solidification, a reorg is possible — the fork rule is "longest chain wins".
• Ethereum divides time "into slots (12 seconds) and epochs (32 slots)" — roughly 6.4 minutes per epoch — and finalises through checkpoint voting, which in practice means about two epochs, near 13 minutes. Once final, reverting a block requires an attacker "to commit to losing at least one-third of the total supply of staked ETH" (ethereum.org). Most exchanges credit USDT ERC-20 deposits after 12 to 32 confirmations, "putting practical settlement in the 3 to 7 minute range" (Eco, 13 May 2026).
• BNB Smart Chain reaches Fast Finality in "~1.875 seconds" post-Maxwell (BNB Chain, 2025).

‍

The number that matters to you is none of these — it is your counterparty's confirmation policy. If the receiving exchange requires 20 confirmations, TRON's one-minute solidification is irrelevant; you wait for their threshold. Ask for it in writing during integration, because it is the actual determinant of when a payout is "done" from the recipient's point of view.

‍

Network fee pass-through: who eats it

Three models exist, and which one you are on decides whether network fees hit your gross margin or your recipients' trust.

‍

1. Absorbed by the sender. You pay the network fee on top of the payout amount. Clean for the recipient, and the line lands in your cost base where finance can see it.
2. Deducted from the payout. The recipient receives the amount minus the fee. This is the single largest source of "underpayment" support tickets in crypto acceptance, because the invoice and the received amount no longer match.
3. Abstracted by the provider. A gateway sponsors gas and prices it into a blended rate. INXY runs this model — the merchant experience is wallet-free, gas-free and blockchain-free — so network volatility becomes the provider's exposure rather than a line on your month-end.

‍

There is no free option among the three. Abstraction moves the variance rather than eliminating it, and a provider carrying it will price it in somewhere. The question to ask is not "do you charge network fees" but "what happens to my rate when Ethereum gas triples for a week".

‍

Read the full network fee comparison → /blog/usdt-network-fees-compared

‍

Mempool congestion and what actually breaks

Ethereum: the stuck transaction. You broadcast at a max fee that made sense, the base fee climbs 12.5% per block, and your transaction sits unmined. Since "the max fee must exceed the sum of the base fee and the tip", a transaction whose ceiling falls below the prevailing base fee waits indefinitely. Replacing it requires a same-nonce transaction at a higher fee, and if your batch submits sequential nonces, one stuck transaction blocks every transaction behind it. This is the classic Friday-afternoon batch failure.

‍

TRON: the exhausted Energy pool. Staked Energy regenerates over time and a rental covers a fixed window. Either way, a batch that runs past its allowance silently switches to burning TRX for the remainder — so a run budgeted at 2–3 TRX per transfer finishes at 7 or 14, and nothing errors to tell you. If the account also lacks TRX, the remaining transfers simply fail. Size the allowance against the zero-balance Energy figure, not the average.

‍

BNB Smart Chain: the false sense of finality. Sub-second blocks make everything feel instantaneous, which encourages treating first inclusion as settlement. It is not; Fast Finality is a separate state roughly 1.875 seconds later. At three transfers per second in a batch loop, the gap between "submitted" and "final" is where double-counting creeps into reconciliation.

‍

All three: the wrong-network send. The most expensive failure is not a fee, it is a USDT transfer sent on the wrong chain to an address that exists on both. Address formats differ between TRON and the EVM chains, which catches most errors — but ERC-20 and BEP-20 share an address format entirely, and a BEP-20 send to an ERC-20 address is a silent, recoverable-only-if-someone-holds-the-key mistake.

‍

Choosing a network for a payout batch

The operational question the other articles skip. Run it in this order.

‍

1. Ask the recipients, before anything else. A batch is only as cheap as the network every recipient can actually receive on. One contractor who can only take ERC-20 does not force the whole batch onto Ethereum — it forces you to split the batch.
2. Segment by network, then by recipient balance. On TRON, any recipient sitting at a zero USDT balance costs roughly double the Energy — including regulars who sweep their wallet after every payment. Check balances at batch build time rather than assuming returning payees are on the cheap tier.
3. Price the batch on today's numbers, not last month's. Check the live base fee before an Ethereum batch. A 400-transfer batch at 65,000 gas each is 26 million gas; at 2 gwei that is trivial and at 80 gwei it is not.
4. Decide burn, stake or rent on TRON — and decide it deliberately. Burning is the default and the most expensive. Renting Energy is usually cheapest and locks no capital, at the price of a third party in the payment path. Self-staking wins only at sustained volume and only if you can lock the position for 14 days on exit. Model all three against your float, not against the per-transfer price.
5. Set fee ceilings and nonce strategy before you submit. Use non-sequential or parallelised nonces where the provider supports it, so one stuck transaction does not halt the batch. Set fee_limit on TRON deliberately rather than inheriting a default.
6. Run screening before broadcast, not after. KYT and sanctions checks that fire after a transfer is on-chain are a remediation exercise, not a control. On our side, screening, auto-conversion and routing all run before payout execution.
7. Reconcile on finality, not inclusion. Mark a payout settled when it reaches the chain's finality state and your counterparty's confirmation threshold — whichever is later.

‍

Send a USDT batch by API or CSV → /cryptocurrencies/mass-payout-in-usdt

‍

Common mistakes

Treating TRON's cost as zero, or paying it the expensive way by default. TRON is cheap, not free: the 600 free daily Bandwidth covers the Bandwidth leg of roughly one transfer and no Energy at all. Burning TRX is what happens when nobody decides anything, and it is the most expensive of the three routes. Deciding once — burn, stake or rent — is worth more than any other network optimisation on this page.

‍

Choosing the network before checking liquidity, and assuming the answer is permanent. A cheap transfer into a market where nobody will off-ramp that token is an expensive transfer. TRON's dominance in real-economy flows exists partly because its USDT liquidity is deepest where payouts actually land — but its share fell from about 74% in January 2025 to about 60% by the end of that year as institutional and platform-integrated flows moved toward Ethereum, BNB Smart Chain, Solana and Polygon (BCG/Allium). Review the network mix; do not set it once.

‍

Optimising the network while ignoring the off-ramp. The network fee is often the smallest line in the total cost of a payout. The conversion spread and the fiat settlement route are usually larger. Fixing the cheap line first is a common and expensive habit.

‍

This article describes technical and market conditions for general information. It is not legal, tax, or financial advice — INXY Payments is a payment infrastructure provider, not a law or accountancy firm, and decisions with regulatory consequence should be reviewed by qualified counsel in the relevant jurisdiction.

‍

Decision framework

• High-frequency payouts to contractors, affiliates or suppliers in emerging markets → TRC-20, and stop burning TRX. Rent Energy if you can accept the counterparty; self-stake if volume is sustained and the capital can sit for 14 days on exit.
• Large, low-frequency settlements to institutional counterparties → ERC-20, and price the gas variance in rather than assuming an average.
• Speed-sensitive transfers where the counterparty already runs BNB Chain → BEP-20, but reconcile on Fast Finality, not first inclusion.
• A mixed recipient list → do not pick one network. Split the batch and treat the split as normal operations rather than an exception.
• You do not want to run any of this → network selection, gas abstraction, screening and conversion belong in infrastructure, not in a finance team's spreadsheet.

‍

The decision worth re-running quarterly is which asset and which chain your recipients actually prefer — it moves. See supported currencies and networks → /cryptocurrencies, or talk to our payments team about a batch → /book-a-demo.

‍

FAQ

Is TRC20 or ERC20 cheaper for sending USDT? TRC-20 is normally cheaper. A USDT TRC-20 transfer costs roughly 6.77 TRX to an address already holding USDT if you burn rather than stake, while an ERC-20 transfer ranges from about $0.30 at 2 gwei to about $12 at 80 gwei. The gap widens sharply whenever Ethereum demand spikes, because TRON's cost is far more stable.

‍

Can I send USDT from a TRC-20 address to an ERC-20 address? No. They are separate blockchains and the address formats differ, so most wallets reject the attempt. Moving between them requires a bridge or an exchange that supports both networks. ERC-20 and BEP-20 share an address format, which makes cross-sends between those two possible and genuinely risky.

‍

Which USDT network is fastest? BNB Smart Chain, on published figures. Blocks are produced every 0.75 seconds and Fast Finality is achievable in around 1.875 seconds. TRON solidifies a block in about a minute, and Ethereum finalises in roughly 13 minutes. In practice your counterparty's required confirmation count usually matters more than the chain's own finality.

‍

Why does a USDT transfer cost twice as much to some addresses? Because the recipient's USDT balance is zero. On TRON that costs roughly 130,285 Energy against 64,285, since the contract must create a storage slot rather than update one. It applies to brand-new addresses and to regulars who empty their wallet after every payment — so for freelancer payouts the expensive tier is the normal case.

‍

How much TRX do I need to stake to cover my transfers? There is no fixed rate. TRON allocates Energy by your share of the total TRX staked network-wide, so the requirement moves as others stake more or less. At 2026 ratios, one 65,000-Energy transfer per day has needed on the order of 13,000 TRX staked, and unstaking carries a 14-day pending period. Price it with a resource calculator before committing.

‍

Should I burn, stake or rent Energy on TRON? Burning is simplest and the most expensive per transfer. Renting Energy from a resource provider is normally the cheapest and locks no capital, but puts a third party in your payment path. Self-staking suits sustained volume if you can tolerate the locked position and the 14-day exit. It is a treasury decision, not an engineering setting.

‍

What is network fee pass-through? It is who bears the blockchain fee on a transfer. Either the sender adds it on top, the recipient absorbs it through a reduced payout, or a payment provider sponsors the gas and prices it into a blended rate. The second model is the most common cause of underpayment and reconciliation disputes.

‍

Circle Q2 2026: Stablecoins Are Becoming Financial Infrastructure

Stablecoins have spent years sitting somewhere between crypto markets and traditional finance.

Circle’s Q2 2026 results suggest that line is becoming much harder to see.

USDC circulation continues to grow. Transaction volume is growing much faster. Banks and financial institutions are moving closer to public blockchain infrastructure. Circle is expanding from stablecoin issuance into payments, tokenized assets, custody, and its own blockchain infrastructure.

The bigger story is not simply that USDC had another strong quarter.

It is that stablecoins are starting to look like a real financial rail.

Here are the developments from Circle’s Q2 2026 Earnings Presentation that we believe matter most.

USDC is growing, but usage is growing much faster

USDC in circulation reached $73.3 billion at the end of Q2 2026, up 19% year over year.

That is significant growth on its own.

But transaction activity tells a more interesting story.

USDC recorded $14.8 trillion in onchain transaction volume during Q2, representing 151% year-over-year growth.

Circle also reported approximately:

• $163 billion in daily onchain transaction volume.
• $1.9 billion in daily minting and redemptions.
• $2.9 billion in daily USDC notional trading volume.

Daily minting and redemption activity increased 105% year over year.

This distinction between supply and activity is important.

A stablecoin can grow because more capital is being stored in it. But when transaction activity grows much faster than circulation, it suggests that the same digital dollars are being used more actively.

Money is not simply entering the system.

It is moving through it.

The wider market shows a similar pattern. Circle’s presentation, using CoinMarketCap and Visa Onchain Analytics data, shows stablecoin circulation growing 22% year over year, while reported transaction volumes grew 84%.

That may be one of the clearest signals that the stablecoin story is moving beyond holding and trading.

The bridge between banking and blockchain is becoming more important

Blockchain transaction speed gets much of the attention around stablecoins.

For businesses, however, a fast blockchain is only useful if money can also move efficiently into and out of it.

Circle reported $170 billion of USDC mint and redeem volume in Q2, compared with $83 billion one year earlier.

Circle’s network now includes more than 15 partner banks, 150 distribution partnerships, and 2,750 direct relationships.

The goal is straightforward.

Make it easier to move between fiat money and USDC across major markets.

This matters because the real business use case rarely ends on a blockchain.

A company may receive stablecoins but need EUR or USD for operating expenses.

A fintech may collect fiat but need stablecoins for international settlement.

A platform may need to move between both depending on the recipient, geography, or payment route.

The blockchain is one part of the journey.

The bridge between traditional money and digital money can be just as important as the rail itself.

Traditional finance is moving closer to stablecoins

One of the strongest themes in Circle’s report is the number of traditional financial institutions appearing throughout it.

The presentation highlights continued adoption involving names including BNY Mellon, Standard Chartered, Kakao, and JCB.

The Arc section goes even further.

Circle lists more than 100 private mainnet partners and shows a validator set that includes financial and infrastructure companies such as BlackRock, DTCC, Global Payments, ICE, Mastercard, MoneyGram, Standard Chartered, Sumitomo Mitsui, and Visa.

This changes the old narrative.

For years, crypto was often presented as an alternative financial system that would replace banks and traditional payment infrastructure.

What is emerging looks different.

Banks, card networks, asset managers, payment companies, and blockchain infrastructure are increasingly connecting to one another.

Stablecoins do not necessarily need to replace traditional finance.

They can become another rail inside it.

Regulation is becoming an infrastructure advantage

The report also makes regulation a central part of Circle’s strategy.

Circle reports USDC across 35 blockchain networks, more than 55 registrations and licenses, and availability across 185 countries.

The company also highlights:

• 1:1 reserve backing.
• Segregated reserve accounts.
• Monthly reserve-asset attestations by a Big Four accounting firm.
• AML and BSA controls.
• Real-time monitoring.
• OFAC screening.

Another major development came in July 2026.

Circle received final OCC approval to establish Circle National Trust under direct US federal oversight.

Circle describes this as a regulated foundation for digital asset custody and a future capability for USDC reserve management.

The strategic message is important.

Regulation is often described as friction for digital assets.

For institutional adoption, the opposite can also be true.

Banks and large businesses need clear rules, reserve transparency, compliance controls, and accountable counterparties before they can move meaningful financial activity onto new rails.

In that context, regulation becomes less of a brake and more of a bridge to adoption.

Stablecoins are becoming payment infrastructure

Perhaps the most relevant development for the payments industry is the growth of Circle Payments Network, or CPN.

CPN connects financial institutions around stablecoin-based payment flows.

Its annualized transaction volume reached $14.7 billion in Q2, growing 76% quarter over quarter. Circle reported 175 financial institutions enrolled by the end of June.

Circle is also working on the less visible parts of payment infrastructure.

The presentation highlights unified onboarding and liquidity, faster corridor activation, automatic rerouting when routes fail, and integrations with Circle Mint, StableFX, and Arc.

These details matter.

Moving a token from one wallet to another is relatively easy.

Building reliable payment infrastructure around it is harder.

Businesses need liquidity.

They need fiat settlement.

They need compliance.

They need reconciliation.

They need reliable payment routes.

They need reporting.

And they need systems that still work when something goes wrong.

That is where stablecoin payments start becoming less about crypto and more about financial operations.

USDC is becoming increasingly cross-chain

Another part of the infrastructure story is interoperability.

USDC is now supported across 35 blockchain networks.

Circle reports 756 CCTP routes across supported networks. Its Cross-Chain Transfer Protocol allows native USDC to move between chains without relying on traditional wrapped-token bridges.

Circle describes the goal as unified liquidity without fragmentation across blockchain ecosystems.

This may sound technical, but the business implication is simple.

Companies generally do not want to think about which blockchain their money is sitting on.

They want liquidity to be available where it is needed.

The more invisible this complexity becomes, the easier stablecoins become to use as ordinary financial infrastructure.

The story is expanding beyond the digital dollar

USDC remains Circle’s core product, but the Q2 presentation points toward a much broader strategy.

EURC circulation reached €382 million, compared with €172 million one year earlier.

That represents approximately 2.2x year-over-year growth.

Circle also reported $3.1 billion in USYC assets, compared with $0.3 billion a year earlier, representing growth of more than 10x. Circle describes USYC as the world’s largest tokenized money market fund.

This is an important expansion of the stablecoin thesis.

The opportunity may not stop with tokenized cash.

Cash can become digital.

Treasury assets can become digital.

Securities can become digital.

Settlement can move onto the same infrastructure.

That brings us to one of the most ambitious parts of Circle’s strategy.

Arc shows where Circle thinks financial infrastructure is heading

Circle plans to launch the Arc mainnet on September 16, according to the Q2 presentation.

Its testnet had already processed 502 million transactions across 2.8 million transacting wallets, with reported uptime of 99.99%.

Arc is not presented as another general-purpose blockchain.

Circle describes it as infrastructure designed specifically for regulated finance.

The network is designed around features such as:

• USDC-denominated gas.
• Sub-second finality.
• Configurable privacy.
• Built-in FX.
• Institutional validators.

Two partnerships show what Circle is aiming for.

DTCC integration is expected to bring tokenized real-world assets onto Arc, including selected equities, ETFs, and Treasuries. Circle also describes potential use cases around securities lending and collateral settlement.

Meanwhile, BlackRock’s BUIDL tokenized treasury fund is expected to deploy on Arc, with BlackRock also participating as a founding validator.

This suggests a much larger ambition.

Circle is not only trying to issue a successful stablecoin.

It is building an environment where money, assets, payments, liquidity, and settlement can increasingly exist on the same infrastructure.

AI agents may become another source of payment demand

One of the more experimental parts of the report is Circle’s work around AI agents.

Circle reports that 99.3% of x402 agent-payment volume settles in USDC, with more than 900 paid services already available in its agent marketplace as of July 31.

The idea is that software agents can hold spending policies, purchase services, settle payments onchain, earn money, and build reputation from completed transactions.

It is still early.

But it highlights something important about digital money.

Traditional payment systems were designed primarily around people and companies.

Software increasingly needs to transact as well.

Always-on, programmable money may therefore find use cases that do not map neatly onto today's card or banking infrastructure.

The financial results show a real business behind the narrative

Circle generated $701 million in total revenue and reserve income in Q2, up 7% year over year.

Adjusted EBITDA reached $143 million, up 8% year over year.

Other revenue grew 41% year over year, although reserve income remains the dominant part of Circle's revenue mix.

Circle continues to guide toward approximately 40% multi-year CAGR in USDC circulation.

The wider market expectations are even broader.

Third-party forecasts cited by Circle put the stablecoin market somewhere between $0.9 trillion and $4 trillion by 2030.

That range is huge.

But perhaps that is the point.

Nobody knows exactly how large the market will become.

The direction is easier to see than the final number.

What we think this means for businesses

Our main takeaway from Circle’s Q2 report is not that every company suddenly needs USDC.

It is that the distinction between “crypto infrastructure” and “financial infrastructure” is starting to disappear.

Stablecoins are becoming useful where they solve an actual financial problem.

That can mean accepting payments from customers who prefer digital assets.

It can mean paying contractors or partners internationally.

It can mean moving liquidity outside banking hours.

It can mean converting between fiat and digital currencies.

It can mean reaching markets where traditional payment rails are expensive or limited.

And increasingly, it can happen behind the scenes without the end user needing to understand blockchain at all.

This is also how we think about the market at INXY Payments.

We started with crypto processing and built products around accepting, converting, and sending digital money.

But businesses do not have a “crypto problem”.

They have a money problem.

They need to receive money, hold it, convert it, pay people, move it internationally, and keep control of the whole process.

Stablecoins are becoming one of the rails that can make those jobs easier.

The technology matters.

But as the infrastructure improves, businesses should need to think about it less.

That may be the clearest sign that stablecoins are growing up.

Explore the full Circle Q2 2026 report

We have highlighted the developments we found most relevant for payments and global businesses.

There is much more in the original 35-page Circle Q2 2026 Earnings Presentation, including detailed data on USDC circulation, liquidity, Arc, CPN, tokenized assets, AI, financial performance, and Circle’s outlook.

The full Circle Q2 2026 report is available below.

The most important shift in digital payments this year is not a new chain or a new token. It is the quiet realisation that stablecoins have crossed from speculation into infrastructure. The Paypers’ Global Stablecoins Report 2026 puts total stablecoin market capitalisation at roughly USD 317.9 billion, with projections that it could exceed USD 2 trillion as institutional participation accelerates — and some contributors put the figure closer to USD 4 trillion by 2030. At INXY, we read those numbers differently from most. The headline is not the size of the market. It is that stablecoins have become one of the first blockchain-based instruments to show clear product-market fit in payments.

That single fact reframes the question every finance team, PSP, and merchant should be asking. It is no longer “should we look at stablecoins?” It is “which payment flows should run on them, and what stablecoin payment infrastructure do we need to make that safe, compliant, and economical?” This article is our read of the report’s data — and what it means for businesses that want to accept stablecoin payments, automate payouts, and move value across borders without rebuilding the financial stack from scratch.

Stablecoins have reached product-market fit in payments

For a decade, crypto payments were a promise: faster, cheaper money movement that never quite arrived at scale. What changed is not the blockchain — it is the infrastructure wrapped around it. The report is blunt on this point, describing stablecoins as one of the first blockchain-based instruments to demonstrate clear product-market fit in payments, increasingly used for cross-border settlement, treasury operations, merchant payouts, and everyday commerce.

The adoption base is real, not theoretical. Triple-A’s data cited in the report shows cryptocurrency ownership rising from around 560 million people in 2024 to roughly 700 million in 2026 — about 8.5% of the global population. These are not all traders. A growing share are freelancers, remote workers, and businesses that earn and hold digital dollars and want to spend or settle them without friction. Demand for a usable rail already exists; the constraint has been supply of trustworthy infrastructure.

Our view is simple. The metric that matters is not the market cap of crypto. It is the number of businesses that can use stablecoins to solve a concrete money problem — a supplier that needs paying today, a payout that needs to clear over a weekend, a treasury balance stranded behind a banking cut-off. That is the lens we apply to every number below.

Enterprise adoption is at an inflection point

Awareness of stablecoins among enterprises is now nearly universal, yet active production use remains modest. That gap is exactly what an inflection point looks like. In the EY-Parthenon survey referenced in the report (n=350), a majority of current non-users said they expect to begin using stablecoins within the next six to twelve months. The conversation inside finance teams has moved from “should we look at this?” to “where should we use it first?”

The intent is concentrated, not scattered. Among corporates asked which use cases they are most interested in over the next five years, the top answers were paying suppliers cross-border (77%), accepting cross-border business payments (49%), and accepting domestic business payments (37%). In financial services specifically, 91% of respondents said stablecoins would become a top priority or receive more attention. This is a back-office, treasury-first story — the place where return on investment is clearest and operational risk can be tightly controlled.

One data point matters more than any other for how this market will be served. When corporates were asked how important it is that their existing banking or payments provider supports stablecoins, 81% said it was critical or important, and 68% said they would prefer a bank-grade issuer. In other words, most businesses do not want to become crypto companies. They want to reach stablecoin capability through providers they already trust, embedded into the ERP and treasury systems they already run. Interoperability beats novelty every time.

Cross-border is the killer use case — but only where legacy rails fail

Cross-border payments lead enterprise adoption for a practical reason: this is where the old process is genuinely broken. A traditional international transfer can take days, pass through several correspondent banks, and leave money stranded in transit. Stablecoins offer near real-time settlement, 24/7 availability, and on-chain visibility — and the economics can be decisive. Among organisations already using stablecoins, 41% report cost savings of 10% or more compared with traditional methods, with the largest gains in cross-border B2B, where correspondent fees, FX spreads, and reconciliation costs stack up.

But the honest version of this story is geographic, and we insist on telling it that way. In Europe, where SEPA Instant already moves money in seconds at near-zero cost, the incremental advantage of a stablecoin for a domestic transfer is small. The value appears on corridors where legacy infrastructure fails. The report cites OpenPayd’s point that a USD 200 remittance to Sub-Saharan Africa can cost more than 8%, against a global average above 6% — and that stablecoins can cut that by over 75%, going as low as 0.5% when paired with reliable on- and off-ramps. MetaComp describes a payment from the UAE to Singapore that takes two to five days through correspondent banking settling in roughly 20 minutes at about half the cost.

So the right question is not “will stablecoins replace banks?” It is “which payment flow should run on which rail?” Stablecoins are not a universal upgrade; they are a precise tool for corridors that are slow, expensive, or fragmented. Matching the right rail to the right flow, market by market, is the actual work — and it is the work we build infrastructure to automate.

The cost nobody talks about: on-ramp and off-ramp economics

Here is the trap that sinks naive stablecoin projects, and the report is refreshingly direct about it. The blockchain fee is only a fraction of the true cost. Moving money into a stablecoin (the on-ramp) and back into local fiat (the off-ramp) is not free. Depending on provider, corridor, and volume, conversion fees run from 0.5% to more than 2% per leg — 1% to 4% on a full round trip. For a business with thin margins, that can erase the headline saving entirely.

The lesson we draw is one we design around every day: the cheapest blockchain transaction does not automatically produce the cheapest payment. Any honest assessment of stablecoin economics must include the full on/off-ramp cost, not just the on-chain fee. This is precisely why liquidity, FX, conversion, and settlement infrastructure matter so much — and why the industry is consolidating around orchestration layers such as Circle’s Payments Network (CPN) and cross-chain protocols like CCTP that move USDC between blockchains without costly bridges. The economics only work when at least one party can hold and route stablecoins natively, and when conversion is priced in basis points rather than percentage points.

For most businesses, building that liquidity and conversion layer in-house is neither realistic nor wise. The competitive edge is not owning a wallet; it is reaching deep, well-priced liquidity through infrastructure that already has it.

The hard part is no longer the blockchain — it is everything around it

If there is one theme the report returns to again and again, it is this: the technology is ready and has been for years. What was missing was the infrastructure required to run stablecoin flows safely, at scale, through systems businesses already understand. Companies need compliance, liquidity, fiat connectivity, reconciliation, custody, and orchestration wrapped around the stablecoin rail. That is where the market gets interesting — and where the winners will be decided.

Compliance is becoming part of the product

Regulation has flipped from the biggest barrier to an adoption enabler. Frameworks such as the GENIUS Act in the US and MiCA in the EU now give issuers and providers a clearer operational footing, especially for bank-issued or bank-distributed stablecoins that meet defined reserve, compliance, and governance standards. The question is no longer whether stablecoins are “too risky.” It is whether a company’s infrastructure is good enough to use them safely.

That raises the bar on operations. KYC, AML, Travel Rule obligations, wallet screening, and transaction monitoring all still apply — and adapting them to on-chain flows is a genuine engineering challenge. The report notes that redundant, repeated KYC is a real drag on growth: across the industry, 25–35% of users abandon onboarding when asked to upload an ID and selfie, while modern compliance engines can screen over 99% of transactions within seconds. Compliance is no longer a checkbox bolted on at the end. It is part of the product, and it has to be fast enough not to kill conversion.

Orchestration and the multi-rail future

The report’s central strategic conclusion — and ours — is that stablecoins will not replace every payment rail. The likely future is multi-rail: bank transfers, instant-payment networks, and stablecoins operating side by side, each carrying the flows it serves best. Stablecoins shine where traditional rails are slow, costly, or fragmented; in highly efficient domestic markets, their edge narrows.

That makes orchestration the decisive capability. Orchestration is the end-to-end management of a payment’s journey — deciding, for each transaction, whether to use a stablecoin, which issuer and chain to select, and when to convert between fiat and digital assets, based on value, urgency, liquidity conditions, and counterparty location. As more rails become available, this routing layer is where cost, speed, and compliance are won or lost. The industry examples in the report make the point: the SG-FORGE and Swift live trial settled tokenised bonds using both traditional financial infrastructure and regulated digital currencies, and Nexus Global Payments is interlinking domestic instant-payment systems like India’s UPI and Singapore’s FAST. None of these efforts replace the old system. They make the whole system work together.

What this means for businesses evaluating stablecoin payments

This report describes, almost line for line, the problem we built INXY to solve. INXY provides the infrastructure businesses need to accept stablecoin payments, automate payouts, convert between crypto and fiat, and move money across borders — without building blockchain, liquidity, compliance, and settlement systems from scratch. We operate the layer behind the customer experience, so the complexity stays out of sight.

Concretely, that means:

• The merchant does not need to become a crypto company to accept stablecoin payments — acceptance runs through familiar checkout and settlement flows, with conversion to fiat handled behind the scenes.
• The fintech does not need to build the entire compliance stack — KYC, AML, Travel Rule, and wallet screening are part of the rail, fast enough to protect conversion rather than throttle it.
• The finance team does not need to manage a collection of wallets and chains — payouts, multi-currency treasury, and on/off-ramp conversion are orchestrated through a single integration, priced to keep the full round-trip economics intact.

If you are evaluating stablecoins, we would frame the decision the way the report’s data suggests. Start with the corridors and flows where traditional rails genuinely fail — cross-border supplier payments, international payouts, multi-currency treasury — not with the flows your domestic bank already handles well. Model the full on/off-ramp cost, not just the on-chain fee. And treat compliance and orchestration as core product requirements, not afterthoughts. The businesses that win with stablecoins are not the ones that move tokens; they are the ones that make different payment systems work together.

The winners will be the integrators, not the disruptors

The biggest shift captured in the Global Stablecoins Report 2026 is not from fiat to crypto. It is from crypto product to financial infrastructure — banks, PSPs, and processors integrating stablecoins into systems that already exist. Stablecoins do not need to destroy the old rails to matter. They need to make the whole system move value better.

That is the future we are building for at INXY. Not one payment rail, but many — with an infrastructure layer that decides, routes, converts, and settles across all of them, so businesses get the speed and cost of stablecoins with the trust and control finance teams require. The stablecoin era will not be won by whoever shouts loudest about disruption. It will be won by whoever quietly makes the rails work together.

‍