Most advice about digital asset payments starts with speed, fees, and the size of on-chain transaction volumes. That's the wrong starting point for a fintech CTO. A payment business fails less often because a blockchain can't move value than because the operator can't reconcile an event, safely retry a request, enforce a signing policy, or explain a balance to finance.
The practical question isn't whether a network can transfer tokens. It's whether your organisation can operate that transfer as a controlled financial process. That requires atomic settlement, network-aware confirmation rules, threshold signing, event-driven services, an append-only ledger, idempotent APIs, scoped permissions, and a deliberate bridge to fiat liquidity. The unglamorous operating layer is the product.
Table of Contents
- Why Gross Transfer Volume Overstates Payment Readiness
- Atomic Settlement and Network Finality
- Securing Custody with Threshold Signatures
- Event Streams and Ledger Reconciliation
- Bridging On-Chain Rails to Fiat Liquidity
- Overcoming the Trust and Adoption Gap
- Critical Questions for Infrastructure Buyers
Why Gross Transfer Volume Overstates Payment Readiness
Stablecoin activity measured in trillions can suggest that digital asset payments have reached mass-market scale. Gross transfer volume remains a weak proxy for merchant checkout, payroll, supplier settlement, and other economically meaningful payments. Exchange activity, internal transfers, treasury movements, and similar flows can make a network appear commercially mature before businesses have built dependable payment controls.
McKinsey estimated about $390 billion in true annual stablecoin payments in 2025, roughly 0.02% of global payments volume, while noting that this level had more than doubled versus 2024. Its estimate for B2B stablecoin payments was about $226 billion a year, or roughly 0.01% of global B2B payment volumes, against global B2B payment volumes of about $1.6 quadrillion. McKinsey's analysis of stablecoin payment volumes separates genuine payment activity from broader blockchain traffic. The payment use case is smaller than the headline volume, but it is growing.
Gross activity is not operating readiness
The underlying rail still matters. McKinsey reported that stablecoin circulation had doubled over the prior 18 months and that stablecoins were facilitating about $20 billion to $30 billion of real on-chain payment transactions per day, with overall transaction volume exceeding $27 trillion per year by 2025. Chainalysis reported $28 trillion in real economic volume in 2025 and described a 133% compound annual growth rate since 2023. Visa separately said stablecoin transaction volume exceeded $51 trillion over the prior 12 months as of 2026. These figures indicate substantial settlement and transfer infrastructure, not proof that each transfer represents a customer payment. McKinsey's account of tokenized cash and payment infrastructure provides context for reading the distinction.
A team that ships a payout flow before defining confirmation thresholds can release funds against unconfirmed deposits when a corridor experiences a reorganisation. Other failures follow the same pattern: duplicate webhook handling, unclear ownership of balances, or a retry that creates a second transfer instead of safely returning the original result.
Early payment products face uncertain demand, changing corridor requirements, different confirmation policies, and incomplete compliance processes. An API-first, modular stack lets a team launch a narrow flow, observe its operational behaviour, then add custody, cards, fiat, or agent controls as the business earns that complexity.
Practical lesson: Build for controlled uncertainty, not imaginary scale. A payment rail becomes commercially useful only when every movement can be identified, authorised, posted, reconciled, and explained.
The risk is volume illusion. It pushes teams to optimise throughput before defining event semantics, ledger states, exception ownership, and signing authority. Treat digital asset payments as financial infrastructure from the first transaction, even while demand remains unpredictable.
Atomic Settlement and Network Finality
Traditional payment operations often separate authorisation, clearing, and settlement. That separation creates windows in which a party can fail to deliver, a payment can be reversed, or two systems can disagree about whether value has actually moved. Digital asset payments can reduce that ambiguity through atomic settlement, where the transfer either reaches the network's final state or doesn't complete as intended.
The benefit isn't that a blockchain may confirm quickly. The deeper advantage is state consistency. A successful transfer produces a verifiable on-chain result, while an unsuccessful transaction doesn't create the same kind of partial settlement obligation found in workflows that depend on later netting or delivery. That changes how a product team designs payout release, treasury movement, and exception queues.
Finality is a policy input
Different networks provide different economic finality characteristics. One technical comparison places Bitcoin at roughly 6 confirmations, about 60 minutes, Ethereum at about 2 epochs, approximately 12.8 minutes, and Solana at around 12.8 seconds. Those figures should not become marketing promises. They should feed a confirmation policy that considers asset, network, transaction value, reorganisation risk, customer experience, and the cost of releasing funds too early. This network finality comparison offers the underlying reference.
A reliable payment service should distinguish at least three states:
- Observed: The system has detected a transaction or balance change, but the release policy hasn't been satisfied.
- Confirmed: The transaction meets the configured confirmation threshold for the relevant network.
- Final or releasable: The operational policy permits crediting, sweeping, or paying out.
That state model prevents a common failure. A watcher sees an incoming transfer, marks an invoice paid, and triggers a payout before the network or internal risk policy treats the deposit as sufficiently final. The blockchain may be functioning correctly while the business creates its own settlement exposure.
The BIS analysis adds a useful institutional comparison. Adjusted annual stablecoin transaction volumes are around $390 billion, while the CHIPS wholesale dollar clearing network settles about $2.2 trillion per business day. The comparison reinforces that gross stablecoin transfer activity includes more than pure consumer payment demand, and that filtering exchange or internal transfers changes the apparent scale of the market. The BIS discussion of stablecoins and monetary infrastructure is valuable for teams setting realistic capacity and risk assumptions.
For operations, atomic settlement doesn't remove every risk. It moves risk toward address accuracy, policy configuration, private-key security, network selection, asset support, and reliable state transitions. Those controls belong in the product design, not in an after-the-fact operations manual.
Securing Custody with Threshold Signatures
The primary custody enemy is a single point of authority. If one server, employee, seed phrase, or vendor-controlled signing service can move customer funds, a compromise can become a direct financial event. Institutional custody needs a design in which no individual component can unilaterally authorise a transaction.
Multi-Party Computation, or MPC, supports that model through threshold signing. The signing secret is divided into shares, and participants collaborate to produce a valid signature without reconstructing the complete private key in one place. A neutral technical explanation of how MPC wallets move beyond seed phrases describes the key property: the signature is generated from the required subset of shares rather than by assembling the full key.
How a 2-of-3 policy works
A documented 2-of-3 arrangement gives three participants a key share, with at least two required to sign. No single participant can authorise a transfer alone. Ripple's explanation of MPC and threshold signing describes this quorum model directly.
A practical production layout might assign the shares as follows:
- Infrastructure share: Held by the payment platform's signing service, protected by workload identity and strict service permissions.
- Client-controlled Co-Signer: Operated by the customer, so the customer retains meaningful authority over production approvals.
- Recovery or governance share: Held under a separately controlled process for incident response, continuity, or approved recovery procedures.
The exact placement depends on the threat model and regulatory obligations. The principle stays consistent. A compromised application server shouldn't be enough to move funds, and a vendor shouldn't be able to redefine the customer's approval policy without detection.
Co-signing must connect to policy
Threshold cryptography is only one layer. The Co-Signer should receive a structured signing request containing the asset, network, destination, amount, originating wallet, business purpose, and policy result. The client can then apply allowlists, transaction limits, role separation, travel-rule handling, sanctions screening, and manual review before returning its signature contribution.
A poor implementation treats MPC as a replacement for governance. It isn't. If every transaction is automatically approved by both parties, the quorum exists cryptographically but not operationally. The signing workflow must make approval meaningful, auditable, and reversible at the business-process level where reversal is possible.
Teams evaluating wallet architecture can use this guide to MPC wallet design as a practical reference. The key buying question is not merely whether a provider uses MPC. Ask who controls each share, how signing policies are changed, what happens during provider downtime, and whether the customer can operate the Co-Signer independently.
Event Streams and Ledger Reconciliation
A blockchain confirmation doesn't complete a payment operation. Finance needs the internal ledger to reflect what happened, risk needs the policy decision, customer support needs a usable status, and treasury needs to know whether funds are available, pending, swept, or blocked.
That requires an event-driven design. WebSocket APIs support real-time server-to-client delivery, with a message event fired when the server sends new data. This makes them suitable for deposit detection, confirmation changes, withdrawal state, and signing-policy outcomes. The WebSocket architecture documentation explains the event model that underpins these live updates.
The ledger is the operational source of truth
An append-only operating ledger should record business events without overwriting history. A payment can move from observed to confirmed, from confirmed to swept, or from pending to blocked, but each transition should retain its actor, timestamp, event identifier, network reference, policy result, and related account entries.
A useful event chain might look like this:
- Payment intent created: The system records the requested asset, network, amount, customer, and expiry.
- Deposit observed: A transaction or balance event is linked to that intent.
- Confirmation policy satisfied: The system records why the deposit became releasable.
- Funds allocated or swept: The ledger connects the customer balance to treasury movement.
- Withdrawal approved and broadcast: The signing decision and transaction identifier are retained.
- Exception resolved: Operations records the resolution rather than deleting the original discrepancy.
This structure gives finance a durable audit trail and gives engineering a way to rebuild projections without changing historical facts. Teams that need a broader accounting reference can review guidance on how to avoid costly reconciliation errors.
Idempotency prevents duplicate money movement
Retries are normal. RPC providers time out, WebSocket connections drop, workers restart, and clients repeat requests when they don't receive a response. Without idempotency, a retry can create a duplicate invoice, duplicate payout instruction, duplicate card funding event, or duplicate ledger posting.
Idempotency means that repeating the same request produces the same outcome. This technical guide to idempotent wallet operations covers why that property matters in financial infrastructure. Store an idempotency key with the resulting resource and enforce uniqueness at the data layer. Don't rely on the caller to behave correctly.
For teams connecting on-chain deposits to fiat conversion, this fiat-to-crypto API overview is relevant because the same event, ledger, and retry discipline must survive the boundary between blockchain and banking systems. The operational rule is simple: events may be delivered more than once, but financial side effects must be applied once.
Bridging On-Chain Rails to Fiat Liquidity
Pure on-chain settlement works well for users who already hold the right asset, use a supported network, and understand wallet operations. Most consumer and business products don't have that luxury. Users fund accounts from banks, spend through cards, receive fiat withdrawals, and expect the application to absorb the complexity of networks and liquidity conversion.
A hybrid model therefore needs clear boundaries. The wallet handles asset ownership and on-chain movement. The settlement layer broadcasts and authorises transfers. The liquidity layer converts between digital assets and fiat. The card or bank layer delivers the user's spending or withdrawal outcome.
Pure rails versus a hybrid product
| Operating model | Strength | Cost or limitation |
|---|---|---|
| On-chain only | Direct settlement, transparent transaction history, and fewer external payment dependencies | Users must manage wallets, assets, networks, and liquidity themselves |
| Fiat-first | Familiar funding and withdrawal experience for mainstream customers | More banking dependencies, slower coordination, and less direct blockchain access |
| Hybrid | Combines wallet balances with bank funding, withdrawals, and card spending | Requires stronger reconciliation, pricing, compliance, and liquidity controls |
A unified API can reduce integration risk by combining embedded wallets, network broadcast, ledger events, card issuing, and fiat movement in one operational flow. That doesn't eliminate provider risk or regulatory responsibility. It does reduce the number of independent state machines your team must reconcile.
Card linkage deserves particular attention. If a wallet balance can fund a virtual or physical Mastercard, the system must define when the balance is reserved, when conversion occurs, what happens if liquidity is unavailable, and how refunds or chargebacks affect the ledger. Apple Pay and Google Pay add another customer-facing layer, but they don't remove the need for precise internal accounting.
For teams assessing the payment layer, this guide to stablecoin payment infrastructure provides a useful way to think about wallet, settlement, and fiat components together. BroLabel offers embedded wallets, BROsettlement, BROwallet, BROcard, ledger services, WebSocket events, and fiat integrations as modular infrastructure for products that need to combine those functions.
The practical design choice is rarely “blockchain or banks.” It's which parts of the experience should remain visible to the customer and which should be abstracted behind controlled infrastructure.
Overcoming the Trust and Adoption Gap
Technical capability doesn't automatically create user confidence. Customers may understand that stablecoins can move quickly and across borders, yet still hesitate when they don't know who protects them from fraud, what happens after a mistaken transfer, or whether their balance has meaningful safeguards.
Visa's survey found U.S. consumer interest in stablecoins rose from 36% to 56% when respondents were shown bank-level fraud protection and deposit insurance. The report on Visa's stablecoin adoption findings suggests that trust framing and user protections can matter more to conversion than advertising lower transaction costs alone.
Protection must be visible in the product
A product team should answer practical questions before promoting a new payment rail:
- Fraud controls: What screening occurs before a withdrawal reaches the signing queue?
- Approval clarity: Can a customer see why a transfer is pending or blocked?
- Recovery boundaries: Which errors can operations correct, and which blockchain transfers are irreversible?
- Balance language: Does the interface distinguish available, pending, reserved, and settled value?
- Regulatory ownership: Which entity handles screening, fiat custody, reporting, and customer complaints?
The market data also points to a separation between payment utility and speculation. Chainalysis reported cross-border stablecoin value rising 77.5% to $220.3 billion in the 12 months ending June 2026, while broader crypto market capitalisation fell 37% to $2.1 trillion. The cited adoption coverage frames that divergence as evidence that payment activity can develop independently from general crypto market sentiment.
Yet stablecoins remain only about 1% of global payment flows, unchanged from 2023 and 2024, according to independent industry research cited in the same coverage. OpenFX reported that 86% of firms say their infrastructure is ready, while almost none have deployed stablecoins at scale. BVP reported that real-world stablecoin payment volume doubled in 2025 to $400 billion, with about 60% estimated to be B2B payments. The immediate opportunity is therefore operational settlement between businesses, not an assumption that every consumer will switch checkout methods at once.
Critical Questions for Infrastructure Buyers
A founder may begin with a simple request, such as accepting stablecoin deposits or enabling wallet-funded cards. A CTO sees a longer chain of dependencies. Finance asks how balances reconcile. Compliance asks who approves withdrawals. Operations asks what happens when an event arrives twice. The vendor must answer all of those questions before production, not after the first incident.
Start with the failure paths
Ask the provider to demonstrate the complete lifecycle in a sandbox:
- Create a payment intent with an explicit asset, network, amount, expiry, and idempotency key.
- Observe and confirm a deposit through WebSocket events, including duplicate delivery and reconnect behaviour.
- Apply a policy decision before funds become available for withdrawal or sweeping.
- Request a signature through the configured threshold workflow and Co-Signer.
- Broadcast, reconcile, and report the resulting transaction across the operating ledger.
A sandbox that only demonstrates the happy path isn't sufficient. Test rejected destinations, unsupported assets, delayed confirmation, provider timeouts, duplicate callbacks, partial internal failures, and policy changes during an open transaction.
Questions for the contract and control review
| Buyer concern | Evidence to request |
|---|---|
| Key management | MPC or hardware-wallet architecture, share ownership, recovery process, and Co-Signer responsibilities |
| Access control | Role-based permissions, scoped API keys, IP allowlisting, replay protection, and approval separation |
| Ledger integrity | Append-only records, event identifiers, export formats, and reconciliation workflows |
| Network operations | Supported chains, confirmation configuration, broadcast behaviour, and reorganisation handling |
| Commercial fit | Fee-engine calibration, sandbox-to-production process, and pricing that accommodates uncertain early volume |
| Incident response | Status visibility, escalation paths, audit access, and documented recovery procedures |
Buying rule: Don't accept “institutional grade” as a product feature. Ask the provider to show the control, the event, the ledger entry, and the operator action that follows.
The provider should also explain how the stack matures with the business. Embedded wallets may begin with individual users, then expand to per-agent, per-player, treasury, or merchant models. AI Agent Wallets need their own role boundaries, audit trails, and transaction policies. An iGaming operator may require per-player USDT deposit addresses and separate observed and confirmed events before an operator policy permits payout signing. Those are different operating patterns, even when they share the same blockchain rail.
A practical evaluation ends with a controlled pilot, not a slide deck. Define the assets, networks, approval policy, ledger states, fiat endpoints, support responsibilities, and reconciliation evidence required for go-live. Then make the vendor prove each one in a failure scenario.
BroLabel provides API-first infrastructure for digital asset payments, including embedded MPC wallets, BROsettlement, operating ledger and reconciliation support, WebSocket events, card issuing, and fiat integrations. Use the sandbox to validate event handling, signing policies, and ledger behaviour before moving into production, then visit BroLabel to evaluate the stack for your payment workflow.
