Getting a stablecoin payment initiative approved internally has become more straightforward for financial institutions. Getting to production still depends on specialized engineering knowledge.
Payment volume on Solana grew 755% year over year, according to Messari’s State of Solana: Payments, with data as of February 2026. That is close to three times the year-over-year median across global fintechs and peer layer-1 networks, per McKinsey’s February 2026 analysis with Artemis. The institutions behind that growth are massive.
Visa settles stablecoin volume at a $3.5 billion annualized rate, with its initial US banking participants, Cross River Bank and Lead Bank, settling on Solana. Mastercard added Solana as one of eight chains on its stablecoin settlement network in June 2026. PayPal’s PYUSD is live on Solana alongside more than a dozen other networks, and Fiserv is building FIUSD to reach its network of over 10,000 financial institution clients over Solana.
The gap we see most often now sits between approval and live implementation.
Where institutional payment volume sits today
Onchain payment activity at institutional scale concentrates in four categories:
- Corporate treasury covers intercompany settlement and operating liquidity held in stablecoins rather than prefunded across banking relationships in every market.
- Payouts covers contractor, seller, and creator disbursement settling in seconds at production volume.
- Cross-border payments covers digital money transfers that reduce reliance on correspondent banking, with conversion to local currency at the edge.
- Remittances covers consumer transfers settled with less capital prefunded across each corridor.
The implementation problem is similar across all four. Custody and transaction-authorization models have to align with existing security and compliance policy. Screening and transaction monitoring have to extend to wallets and onchain activity. Providers have to clear procurement, legal, security, and regulatory diligence. Onchain transactions have to reach internal ledgers and reconciliation processes in an audit-ready form. The workable plan integrates faster rails with the institutional controls already in place rather than replacing them.
Note: Card settlement, embedded finance for neobank products, and agentic payment flows run on the same infrastructure at an earlier stage of adoption.
A production payment is more than an onchain transaction
Consider a common fiat-to-fiat flow. Funds enter through an on-ramp, move into custody as a stablecoin, settle between wallets through Solana’s token program, and exit through an off-ramp on the recipient’s side. Screening for KYC and sanctions gates the fiat boundary in both directions, before any funds move. Settlement on Solana is one component inside that stack.
Transactions on Solana settle in seconds. Total end-to-end timing depends on banking rails, provider processing, compliance review, liquidity, and payout availability, which is why a payment can settle correctly onchain and still create problems elsewhere. Compliance may not receive the information it needs. Treasury may not have liquidity in the right corridor. Finance may be unable to match the transaction to the right entity, account, and cost center. Each of those becomes a production problem if it is not designed for in advance.
The seven decisions that shape a payment architecture
A production payment system on Solana comes down to seven decisions, each with a question the team has to settle internally before implementation begins.
- Stablecoin and token. Which token and issuer, and what is your exposure if either changes? Redemption terms, supported jurisdictions, available liquidity, token controls, and counterparties all shift with the choice.
- Custody and authorization. Who can authorize fund movement, under what conditions, and how is that enforced and evidenced? Most systems use tiered controls: limited balances in hot operational wallets for routine programmatic payments, warm buffers with stronger approval requirements, and cold or custodied reserves.
- Privacy and disclosure. What has to stay confidential, from whom, and what must remain disclosable to regulators and auditors?
- Fiat rails. Which corridors, at what capacity, with which banking partner on the fiat side? A provider that works well in one market may have limited regulatory permissions, banking coverage, or payout reliability in another.
- Liquidity. Above what size does a conversion require a quote, and who executes? Smaller conversions can run through quoted provider pricing or exchange liquidity, while larger amounts usually require an OTC desk or market maker.
- Compliance. Can screening, monitoring, and Travel Rule obligations run inside the payment flow, and does each decision produce the evidence required for regulatory reporting and audit?
- Integration. Can finance reconcile and close in month one without manual work? Transaction status, blockchain identifiers, fees, FX rates, counterparties, and failed or returned payments all have to feed the internal ledger.
These are not independent boxes. Token selection constrains liquidity. Liquidity constrains the fiat architecture. Custody determines what authorization is possible. Privacy shapes what compliance and auditors can see, which is why the guide recommends confirming what each audience can see before finalizing token selection or custody.
Three approaches to privacy, and what each one costs you
Solana settles publicly by default, and institutional payment flows often do not. Three approaches give institutions flexibility over what stays hidden and where settlement happens.
Confidential token transfers use encrypted balances and payment amounts while keeping transactions and counterparties visible on mainnet, as in Confidential Token Extensions. Private mainnet transactions conceal sender and receiver information, asset type, and amounts using zero-knowledge proofs while settling directly on Solana, as in Helius Privacy. Private execution environments process activity inside a permissioned channel the institution controls, with mainnet connected for deposits, withdrawals, and liquidity, as in Solana Private Channels.
The right model depends on what must stay confidential, who should access the data, and whether mainnet composability is required. Many institutional deployments also require on-demand disclosure to regulators and auditors, which is a separate requirement from confidentiality and is easy to discover late.
What the network gives you, and where the planning work sits
Median fees on Solana run around $0.0013, held steady by local fee markets even during high activity. Fee savings depend on total value transferred and corridor-specific economics rather than transaction count, so a single high-value corridor can show clear return at modest volume.
Solana processes $2 trillion in quarterly stablecoin transfer volume, per payments.org, which means size can move without moving the market. The same ecosystem supports stablecoins in euro, sterling, and yen with DEX liquidity to convert between them without leaving the chain. Liquidity thins quickly outside USDC and other major pairs, so a corridor running through a local-currency stablecoin needs the DEX spread priced before the rail is priced, to confirm the FX savings are real.
Transactions reach optimistic confirmation in roughly 0.6 seconds, with full finality completing in about 13 seconds today and the Alpenglow consensus upgrade expected to reduce that to under 150 milliseconds. For most institutions currently running on card rails or correspondent banking, throughput is not the binding constraint, and the advantage compounds at scale.
The guide covers four more capabilities in the same format, including network reliability, yield on idle balances through instruments like BlackRock’s BUIDL, the partner ecosystem across custody and ramps, and Solana Developer Platform. SDP provides a unified dashboard and API for issuance and payments with integrated options across custody, compliance, RPC infrastructure, fiat ramps, and privacy. It remains in active development with production access available by request, which makes it worth engaging early when you are setting implementation timelines.
How much of the stack to operate yourself
Every payments implementation on Solana sits somewhere on a spectrum from a fully managed payments API to a customer-operated platform.
A managed payments API is typically the fastest path to production, with one provider supplying and operating most of the stack. It minimizes initial engineering effort and gives up control over routing, product behavior, and long-term unit economics, with a per-transaction fee that grows with volume and reprices on the provider’s terms. A hosted configurable platform provides common infrastructure while letting the institution choose the components that carry its risk, so custody or compliance can be swapped independently without a broader migration. SDP is the Solana Foundation’s entry in this category. A customer-operated platform gives full control over architecture, infrastructure, and provider relationships, with a larger investment upfront and costs that improve as volume grows.
Three questions usually settle it:
- At what volume does a provider’s per-transaction fee exceed the cost of running the equivalent capability yourself?
- Which parts of the stack carry enough of your risk that you need to control them directly?
- Can your security and regulatory requirements be met inside a hosted model?
The five patterns that stall stablecoin payment implementations
Technical feasibility is only one source of implementation risk. Deployments more often stall when architecture, compliance, operations, and ownership decisions get made in the wrong sequence. Five patterns come up repeatedly.
- Compliance shows up too late. Teams start building months before compliance reviews the plan, often after custody and the transaction flow are locked in, and the initiative grinds into rework. Bring compliance, treasury, and legal into the room while the architecture is still being decided.
- The pilot tests for functionality, not business value. Proving the technology works is not the same as demonstrating business impact, and an initiative that stops at the former becomes a marketing exercise. Test the actual corridor economics, operational load, and customer behavior.
- The system works, but the business can’t use it. The payment flow can be live while finance still cannot close the month with it. Scope the ERP, treasury reporting, and compliance reporting integrations alongside the payment build.
- Custody is chosen based on features. Custody gets evaluated on how fast a provider can sign a transaction, when the question that matters is who can approve a payment and how you prove it afterward. Start from accountability, before evaluating any technology.
- Teams are making these decisions for the first time. Implementation decisions are hard to undo, and they are usually made by whoever is already in the room rather than by whoever has made them before.
From approval to production
If your organization has an approved stablecoin payment initiative and is working out the path to production, the guide includes a two-phase readiness assessment covering business readiness and architecture and implementation readiness, with scoring and a recommended next step for each result. It was written for payments providers, cross-border fintechs, banking platforms, commercial banks, and payment infrastructure companies.
We also run a complimentary Solana Payments scoping session. We will review your readiness assessment, discuss your use case and target corridors, identify architectural gaps and implementation risks, and recommend a deployment approach for your requirements. For teams that want the architecture resolved before engineering begins, we run a four to five week fixed-scope Solana Payments Sprint that turns business requirements into a production architecture with an implementation roadmap.