

Gaspard LEZIN
Merchant of Record Stablecoin Payout: A Practical Guide
Learn how a merchant of record stablecoin payout works, what it means for global merchants, and how Suby enables USDC settlement alongside bank payouts.
A merchant of record stablecoin payout is when the seller of record settles the net proceeds to a USDC wallet instead of a bank account, and in 2025 stablecoin payments reached about $390 billion, with B2B use making up roughly $226 billion of that total. For a founder selling across borders, that means the checkout can stay familiar, while the payout destination changes to the place you want to hold funds.
You feel the pain most when the sale is already done, but the money is still stuck between processors, banks, and currencies. The customer paid, the invoice is closed, and your finance team is still waiting on a transfer that may arrive days later.
Table of Contents
What a Merchant of Record Stablecoin Payout Actually Means
A Lisbon-based SaaS founder selling to U.S. customers often wants the same thing every month, simple collection and fast access to the proceeds. The customer pays on checkout, but the founder doesn't want to wait for a cross-border wire to clear before the cash can be used. That's where a merchant of record setup matters.
In a merchant of record model, a third party is the seller of record to the buyer. It handles the commercial sale, the payment flow, and the tax and compliance complexity around that sale, then remits the merchant's net proceeds afterward. In a stablecoin payout model, those net proceeds are settled to a USDC wallet address instead of a bank account, and the merchant chooses that destination.
That distinction matters more than people expect. The merchant of record is the recipient of record for the payout, but not the seller of record on the customer's checkout. The customer sees a normal payment experience, while the business decides whether it wants settlement in fiat or in stablecoins.
Practical rule: if you're trying to understand the accounting, always separate the sale to the buyer from the settlement to the merchant. Those are related, but they're not the same thing.
For a deeper overview of the underlying merchant of record model, this internal explainer on merchant of record setup is a useful reference.
This guide walks through the payment flow, the bank versus USDC trade-off, how a setup works in practice, and the questions finance teams should ask before turning it on. It also gets into the part most articles skip, the reconciliation and tax questions that appear the moment a payout lands in a wallet instead of a bank account.
How the Flow Works from Payin to USDC Settlement
A merchant of record stablecoin payout has three parts, payin, balance, and payout. That's the cleanest way to think about it, because the confusion usually starts when people mix those steps together.
Payin
The customer pays on a hosted or embedded checkout, often by card. The merchant of record is the seller on the card transaction, so the buyer sees one commercial counterparty and one payment experience. In Suby's model, businesses can accept card or crypto payments through one API-first stack, and they can also connect Discord and Telegram for paid access use cases.
Balance
Once the payment clears, the money lands in the platform balance. Fees, refunds, and other adjustments are netted there, so finance has one place to review the commercial outcome before settlement. That's also where reconciliation begins, because the payout is tied to an underlying order, not just a wallet transfer.
For a concrete mental model, think about a 100 EUR card payment. The merchant of record receives the payment, applies the relevant fees, and then settles the remaining amount as USDC to the merchant's wallet. The on-chain transfer gives you a visible transaction hash, which is useful when you need to match the payout to the dashboard record.
Payout
The final step is the settlement rail. Instead of sending the net proceeds to a bank account, the platform converts and sends them as USDC to a compatible wallet on a supported network. In the documented Suby payout flow, merchants can choose a bank account or a USDC wallet destination, and once it's set, future payouts go there automatically.
The technical lead to watch here is not just the transfer itself, but the metadata that survives it. A useful payout stack preserves payout purpose, recipient record, approval authority, asset choice, fee treatment, timestamps, and final delivery state so finance can reconcile the onchain settlement against the sale.
For readers who want a hiring-market perspective on the infrastructure layer, Technical lead blockchain payments is a relevant role description to study, because it shows how operational and settlement logic are now becoming product work.

For a broader technical framing of settlement infrastructure, the internal article on settlement processor design is worth reading alongside this flow.
Stablecoin Payout vs Bank Payout for Cross-Border Merchants
The choice between bank payout and USDC payout is mostly a trade-off between familiarity and flexibility. Bank rails are easier to explain to accountants, but stablecoins can remove some of the friction that shows up in international settlement.
Speed, cost, and treasury use
A bank payout usually fits existing accounting workflows well. Finance teams already know how to match it against invoices and bank statements, and it suits businesses that want the money parked in a traditional operating account. The downside is that cross-border wires can slow things down and introduce correspondent bank costs and FX spread when currencies have to be converted.
A USDC payout behaves differently. The value settles on-chain, usually much faster than a traditional cross-border transfer, and the merchant can hold dollar-equivalent value without needing a U.S. bank account. That can be useful if the business wants to keep some treasury in stablecoins for crypto-denominated expenses, or if it plans to off-ramp only part of the balance later.
Operational friction and risk
The trade-off is that wallet management becomes part of finance operations. Someone has to control the receiving wallet, verify the chain, keep track of gas and fees, and decide what to do if the business converts immediately versus holding the asset. There's also a small but real depeg risk, which is why treasury policy matters even when the settlement asset is designed to track the dollar.
If your accountant can't explain the payout in one sentence, you probably need a better reconciliation trail before you switch rails.
Suby's cross-border payments overview is a helpful reference point for merchants comparing settlement paths, especially when the business sells internationally and wants to choose the payout destination more deliberately. For that angle, see cross-border payment options.
Dimension | Stablecoin (USDC) Payout | Bank Payout |
|---|---|---|
Settlement timing | Usually faster on-chain once the payout is executed | Depends on banking rails and corridor |
Treasury treatment | Can stay in USDC or be off-ramped later | Lands directly in fiat |
Operational setup | Wallet, chain, and address management | Bank account details and bank compliance |
Accounting feel | Requires digital asset or crypto-aware bookkeeping policy | Familiar cash accounting workflow |
FX exposure | Can reduce the need for immediate conversion | FX often happens at the bank or payout stage |
Setting Up a USDC Payout with Suby Step by Step
A practical setup starts with making sure the account is ready for merchant of record use. The platform needs business verification first, because it has to stand behind the sale and the payout workflow. Suby's documentation also shows that merchants can set the payout destination in dashboard settings, including a bank account or a USDC wallet.
The cleanest way to think about the setup is to treat it like a treasury configuration, not just a payment toggle. If the business wants stablecoin settlement, it should confirm the wallet address, the supported network, and the payout destination before it starts collecting money.

The setup flow
Complete account verification. The merchant of record needs the business details that let it act as seller of record and handle the commercial flow.
Create the product or subscription. In a SaaS setup, that could be a monthly plan, a one-time invoice, or a gated community access pass.
Add the payout destination. Suby's documentation shows that merchants can choose a USDC wallet instead of, or alongside, a bank destination.
Check the wallet before going live. A test transaction is the safest way to confirm wallet control and address accuracy.
Review the dashboard after the first settlement. The merchant should see the payout status in the dashboard and the on-chain transfer in the wallet history.
Suby's own docs say its crypto payout flow can accept cards, wallets, bank, and local methods in 190+ countries, consolidate sales into one balance, and then let the merchant pick a chain and wallet for USDC payout. It also documents payout timing controls, including on-demand or automatic withdrawal.
For a product-led implementation perspective, payment integration for SaaS founders is a good complement, because it frames payments as part of the product stack rather than a separate finance tool.
Suby's payout documentation also says card payments are charged at 4% + $0.40 per transaction, and payout to bank or USDC adds +1%, with card fees deducted at payout time rather than transaction time. That means pricing depends on the payin method and the payout path, so the exact economics need to be checked on the pricing page before launch.
Three Real Scenarios Where Stablecoin Payouts Make Sense
A USDC settlement option isn't useful everywhere. It makes the most sense when the business already feels the pain of cross-border payout delay, awkward banking access, or constant FX change.
A SaaS founder billing abroad
A B2B SaaS company in Europe invoices a client in Latin America. The client pays by card through a merchant of record checkout, and the founder chooses a USDC wallet as the payout destination. The result is simple, the sale gets collected through card rails, and the founder receives dollar-equivalent settlement without waiting for a correspondent bank transfer to finish.
A creator community with global members
A creator runs a paid Discord community for fans in Nigeria, Turkey, and the Philippines. Local card acceptance is uneven, but the creator still wants one checkout and one settlement path. With merchant of record handling the payment flow and USDC settlement going to a self-custody wallet, the creator gets paid faster and can manage community cash flow without juggling multiple bank corridors.
An e-commerce brand managing treasury
An e-commerce merchant sells globally and wants more control over daily FX exposure. Card payins still make sense for customers, but the business doesn't want every payout forced into local fiat right away. It can settle in USDC for treasury flexibility, then choose a monthly bank payout later for operating expenses if that fits the finance plan.
The common thread is not ideology, it's control. The business still accepts the methods its customers prefer, but it decides where the money lands and when it wants to convert.
Compliance, Tax, and Accounting for Stablecoin Settlements
The hardest questions start after the payout lands. A finance team has to know who the payout recipient of record is, how the transfer should be booked, and what the tax implications are when the destination is a wallet instead of a bank account.
What finance teams need to track
The enterprise control point is compliance as much as transfer. A stablecoin payout stack should run KYC or KYB, sanctions screening, and transaction monitoring at payout time, then retain payout purpose, recipient record, approval authority, network choice, fee treatment, timestamps, and final delivery state. That record is what lets finance reconcile the commercial obligation to the onchain settlement.
For tax treatment, the right answer depends on jurisdiction, so no one should assume a single rule fits every market. In many places, business receipts are recognized at fair market value on receipt, and later gains or losses can arise when the asset is disposed of, but that always needs local professional review. The practical issue is that a wallet receipt can trigger questions about valuation and reporting that don't appear in a standard bank payout.
Accounting also gets more granular. The books may need to show gross sales, merchant of record fees, network fees, and the stablecoin leg as either cash-like balance or a digital asset, depending on policy. That means the team needs a consistent view of wallet ownership evidence and timestamped conversion rates, not just a screenshot of a completed transfer.
A useful outside reference for the tax side is Allied Tax Advisors crypto guide, which can help teams think through valuation and disposal concepts before they hard-code a policy.
Area | Bank Payout | Stablecoin Payout | Merchant Action |
|---|---|---|---|
Recipient record | Bank account holder | Wallet owner | Keep proof of control and ownership |
Settlement evidence | Bank statement and transfer reference | On-chain hash and dashboard record | Store both records together |
Tax documentation | Standard fiat payment support | May need asset valuation support | Capture timestamped pricing and jurisdiction |
Reconciliation | Matches to bank feed | Matches to wallet activity plus platform data | Map each payout to order and customer |
Policy risk | Familiar but still jurisdiction-specific | More complex because of digital asset treatment | Get local tax and legal review |
Decision Checklist Before You Switch to Stablecoin Payouts
Before turning on USDC settlement, a founder should treat the switch like a treasury decision, not a cosmetic payment update. The question is whether the whole flow, customer sale, compliance, payout, and bookkeeping, works better with a wallet destination than with a bank destination.
Run the decision in order
Confirm the merchant of record model. Make sure you know who contracts with the customer, who handles refunds and chargebacks, and who remains the seller of record.
Verify the payout rules. Check supported pay-in methods, currencies, geographies, payout currencies, chains, minimums, fees, and payout timing in the official docs.
Test wallet readiness. Use a secure wallet, confirm the network, and make sure address validation is working before any real settlement goes live.
Map the accounting. Decide how sales, fees, refunds, chargebacks, and network costs will be posted in the ledger.
Prepare operations. Set roles, approval steps, sanctions checks, and a fallback plan if a payout fails or a wallet is unavailable.

What to verify before launch
The most important habit is not to infer features from marketing copy. Record the exact documentation link, the effective date, and the payout behavior you tested. Then run a small transaction and reconcile it end to end, including taxes, fees, refunds, and any blockchain costs.
If the economics only look good before FX, network fees, compliance work, and support overhead, the switch probably isn't ready. If every payout can be matched to an order, a customer, a jurisdiction, and a wallet transaction, then the model is probably operationally sound.
Suby's product already covers card and crypto acceptance, wallet-based settlement, and native Discord and Telegram integrations for paid access use cases. If you're evaluating whether that fits your stack, start with the docs and compare the payout path against your current treasury workflow.
If you're weighing bank settlement against USDC payout for your own business, take a close look at Suby. It lets businesses accept card or crypto payments, route settlement to a bank account or stablecoins, and connect paid access flows like Discord and Telegram from the same product.