For a payment service provider (PSP), poor design in payment infrastructure has practical consequences. Margins thin out when routing and hedging are inefficient. Settlement delays create support load and strain merchant relationships. Compliance gaps put banking relationships at risk. This article sets out what a modern PSP stack has to do, which components matter most, where the regulatory position stands in 2026, and how to decide between building the stack yourself and integrating an established crypto payment gateway.
Why PSP infrastructure matters in 2026
Four pressures now shape almost every design decision a PSP makes. None of them is speculative, and each affects pricing, user experience and legal exposure.
- Liquidity fragmentation: Liquidity no longer sits in a single venue. Centralised exchanges, decentralised exchanges and over-the-counter desks all affect execution quality and the rate you can offer a merchant.
- Security threat: Private key compromise, smart contract vulnerabilities and increasingly targeted on-chain attacks mean custody design and continuous monitoring carry direct financial exposure.
- Merchant expectations: Businesses want fast settlement, predictable foreign exchange handling, and refund and dispute processes that reflect how crypto payments actually behave.
Each of these translates into measurable business risk. Suboptimal routing and hedging erode margin on every transaction. Settlement delays increase support costs and merchant churn. Compliance gaps invite fines and, more often, the loss of a banking partner, which is usually the more damaging outcome.
What is a PSP payment infrastructure?
Core functions
A PSP payment infrastructure is the end-to-end stack that accepts, processes, converts and settles payments on behalf of merchants. It covers merchant onboarding, payment acceptance, routing, custody, conversion, settlement, and reconciliation, as well as the reporting and support services merchants rely on.
- Payment acceptance: Capturing payment instructions through APIs, SDKs, hosted widgets, point-of-sale terminals and invoices.
- Routing: Deciding which blockchain network, rail or liquidity provider should fulfil a given transaction.
- Custody: Holding assets securely under segregated hot and cold controls with a defined signing process.
- Conversion: Exchanging received crypto-assets for a settlement currency at market prices via liquidity providers.
- Settlement: Delivering funds to merchants in crypto or fiat currency on an agreed cadence.
- Reconciliation: Matching on-chain events and bank statements against internal ledgers and merchant reports.
- Merchant services: Dashboards, dispute handling, tax reporting and customer support.
How it works
A payment flow begins with a merchant instruction. The API gateway accepts it and generates a payment request, which the payment switch routes to the chosen network or instrument. On-chain confirmations are then monitored, and webhooks or event streams update merchant systems as the transaction progresses. The three event types worth designing around are API webhooks, confirmation events and payout triggers.
Once a payment reaches the agreed confirmation threshold, the liquidity engine executes any conversion and triggers settlement. Reconciliation aligns on-chain activity, the internal ledger and fiat movements, then produces merchant statements. Confirmation and settlement are separate stages, and treating them as one is a common source of confusion among merchants: a transaction can be confirmed on-chain long before funds reach a bank account.
Crypto-specific differences
Crypto PSPs differ from fiat-only PSPs in ways that change system design rather than configuration. Most blockchain networks offer probabilistic rather than immediate finality, so the stack has to monitor for chain reorganisations and set a confirmation threshold per asset. Network fees add a variable-cost layer that batching, fee estimation, or a different network can reduce but not remove. Multi-asset liquidity forces the payment switch to handle price discovery across multiple assets and providers simultaneously.
There is also no equivalent of a card chargeback. On-chain payments are push transactions and are generally irreversible once confirmed, so merchant refunds are separate outbound payments and disputes are handled commercially rather than through a scheme process. That difference reshapes your accounting, your support workflows and the terms you can offer.
Key trends shaping PSPs in 2026
Liquidity fragmentation
Liquidity spans centralised venues, decentralised exchanges and over-the-counter desks, which widens price dispersion and makes execution harder to predict. Best-price routing has moved from a differentiator to a baseline requirement because the spread you absorb on conversion comes directly from merchant pricing or your own margin. A capable aggregation layer reduces slippage on larger transactions and makes the rates you quote defensible.
Security and custody innovation
Multi-party computation and threshold signature schemes are production-grade and increasingly common in institutional custody. Both reduce reliance on a single private key while supporting the signing throughput a payment business needs. Most providers combine them with hardware security modules and split signing authority across roles and systems, rather than treating any one technology as sufficient on its own.
Core components you must build
Gateway and API layer
Provide REST and WebSocket APIs, SDKs in the languages your merchants actually use, and drop-in payment widgets for web and mobile. Idempotency keys, reliable webhook retries and a working sandbox on public testnets matter more than feature breadth. They determine how long a merchant’s engineering team spends on integration, and that time is a cost borne by both sides.
Multi-rail payment switch
The payment switch has to support multiple blockchain networks, layer 2 rollups and stablecoins, with fallbacks when a preferred rail is congested or unavailable. Routing decisions should weigh execution price, network fees, expected confirmation time and current congestion. Keeping these policies configurable by merchant or region avoids hard-coding assumptions that may no longer hold within a quarter.
Liquidity and foreign exchange (FX) engine
Connecting to several liquidity providers and automated market makers, where appropriate, improves execution and reduces dependence on any single venue. Auto-hedging neutralises the open positions created between payment acceptance and settlement, while real-time exposure tracking shows what the business is actually carrying. Pre-funded pools and dynamic rebalancing are what make a same-day settlement promise deliverable rather than aspirational.
Custody and settlement
Merchants differ in their custody preferences, so supporting both custodial and non-custodial models broadens the addressable market. Operationally, size hot wallets against daily payout volume and hold reserves in cold storage under stricter controls.
Fiat settlement depends on banking partners, but the access position has improved. Since October 2025, non-bank PSPs that meet the TARGET Guideline requirements have been able to access TARGET services directly, including TIPS for instant euro settlement. That route can reduce dependence on a single sponsoring bank, though it brings its own onboarding, liquidity and operational obligations.
Compliance and regulatory checklist
Licensing and registration
Map the authorisations you need in each target market before writing code. Payment and e-money activities require separate authorisation under PSD2 and the E-Money Directive. Early legal scoping is considerably cheaper than restructuring a live product.
Run banking partner due diligence in parallel. Your ability to clear fiat flows will shape which markets you can realistically serve, and banking conversations tend to move more slowly than engineering work.
Know Your Customer (KYC), Anti-Money Laundering (AML) and sanction screening
KYC, ongoing transaction monitoring and sanctions screening are baseline requirements rather than differentiators. Build the capability to produce complete audit trails and to file suspicious activity reports without reconstructing history by hand.
Risk tiering keeps friction proportionate, so an established merchant with a clean record is not treated like a newly onboarded high-risk account.
Data protection and reporting
The General Data Protection Regulation sets the baseline for handling merchant and payer data, with UK GDPR and the Data Protection Act 2018 applying where UK operations are in scope. Define retention periods, data residency and access controls at the design stage rather than after the first audit.
DORA adds a further layer for EU financial entities, including payment institutions and CASPs. It has applied since 17 January 2025 and requires ICT risk management, major incident reporting, resilience testing and a maintained register of contractual arrangements with ICT third-party providers. Merchants will expect exportable, tax-ready reporting separately, so treat reporting as a product requirement rather than a compliance by-product.
Security and custody best practices
Key management architecture
Combine multi-signature or threshold signature schemes with hardware security modules for signing operations, and separate signing roles so that no single person or system can move funds alone. Multi-party computation is well-suited to high-frequency signing, where hardware-only approaches become a bottleneck. The objective is straightforward: remove single points of failure without throttling the payout throughput the business depends on.
Audit, insurance and testing
ISO/IEC 27001 certification and SOC 2 reporting are the assurances partners most often ask for, and both take longer to obtain than teams expect. Run regular penetration tests and audit any smart contracts in the payment path before they handle live value. Publish what your insurance covers and, just as importantly, what it excludes, so that merchants and partners understand which losses fall to them.
Continuous monitoring
Automated analytics that flag anomalous on-chain activity shorten the time between an incident starting and someone noticing. A bug bounty programme and rehearsed incident response playbooks cover the cases that monitoring misses. Detection speed is the variable that most directly limits losses from an attack pattern you have not seen before.
Technical architecture recommendations
Modular microservices
Isolate routing, settlement, compliance and accounting so each can scale and be upgraded independently. Clear service boundaries and stable API contracts reduce deployment risk and enable the replacement of a single component, such as a liquidity provider integration, without affecting the rest of the stack.
Event-driven design
Durable message queues give you ordered processing under load and a replayable record of what happened. End-to-end tracing of transaction states and confirmations lets you reconstruct any payment for an audit or a merchant dispute, which is difficult to retrofit once volume grows.
Idempotency and retry logic
Design APIs and on-chain flows to be idempotent and resilient to nonce collisions, dropped transactions and chain reorganisations. Retry policies need safe rollback paths, and unresolved states need a defined reconciliation workflow rather than a manual investigation each time.
Transaction cost optimisation
Batching, accurate fee estimation, and payout aggregation reduce on-chain costs without materially changing confirmation windows, provided the batching interval is set relative to the settlement commitments you have made. Keep operational balances in hot wallets and reserves in cold storage, and revisit the split as payout patterns change.
Operational and treasury considerations
Reserve management
Instant settlement guarantees are funded from reserves, so hold both fiat and crypto balances sized to your commitments. Define minimum liquidity buffers by currency and settlement cadence, and set them against peak payout cycles rather than average days. Reserves should also absorb temporary market dislocations without forcing you to break a settlement promise.
Hedging and FX controls
Algorithmic hedging and over-the-counter partners both have a place in managing volatility exposure, and the right mix depends on transaction size and asset mix. Monitor net exposure continuously and adjust hedge frequency to match activity rather than the calendar. Document the policy and measure it against realised profit and loss; otherwise you cannot tell whether hedging is working or simply costing money.
Reconciliation automation
Automate reconciliation across on-chain events, internal ledgers and bank statements. Manual reconciliation is where errors accumulate and where merchant disputes originate. Exportable statements and tax-ready reports let merchants feed settlement data into their own accounting systems without rekeying, reducing support tickets and errors.
Pricing models and commercial strategy
Fee and spread structures
Transparent pricing usually takes one of three forms: a fixed fee per transaction, a percentage of transaction value, or a spread applied to the executed market rate. Many providers combine them, and merchants generally accept any of the three as long as the basis is clear.
Whichever model you choose, routing cost feeds directly into merchant pricing. Executing across several automated market makers typically costs more than matching on a deep centralised venue, and the gap widens as order size grows relative to available liquidity. Surfacing routing costs in internal reporting allows you to price by corridor and merchant tier rather than averaging across the whole book.
Subscription and enterprise options
API subscriptions typically include premium features such as advanced reporting or higher rate limits, while high-volume clients usually want bespoke service-level agreements covering uptime and settlement timing. Whitelabel pricing should reflect the cost of customisation and the commitments you are making on availability and settlement, not simply transaction volume.
Unit economics to monitor
Track cost per transaction across infrastructure, network fees and liquidity so you know which corridors are genuinely profitable. Contribution margin by product, merchant tier and regional corridor is the view that tells you where to invest and where pricing needs to change. Without it, a growing transaction volume can quietly conceal a shrinking margin.
Integration and merchant experience
Developer tools and onboarding
SDKs in common languages, a functional sandbox and accurate API documentation reduce integration time more than any feature you could add to the gateway itself. Role-based access and sub-merchant management are prerequisites for marketplaces and platforms, and retrofitting them into an existing merchant model is disruptive.
Merchant dashboard and reporting
Real-time dashboards covering payments, settlements and disputes are what merchants use daily, and whitelabel branding controls matter when a PSP resells your infrastructure. Webhook event streams and exportable reconciliation reports enable merchants to integrate settlement data into their ERP systems, often the difference between a pilot and a full rollout.
Payment UX examples
Point-of-sale QR payments suit in-person retail, one-click checkout works for returning e-commerce customers, and invoices priced in fiat at the time of payment protect both parties from price fluctuations during the payment window. Each flow places different demands on routing and confirmation monitoring, so treat them as distinct products rather than variations on a single integration.
Metrics to track
Performance and volume metrics
- Transaction volume and growth rate, segmented by corridor and merchant tier.
- Settlement latency, measured from confirmation to funds available to the merchant
- Confirmation time by network, tracked against the thresholds you have set
- Merchant onboarding time, from signup to first live payment
Cost and risk metrics
- Cost per transaction, including infrastructure, network fees and liquidity costs
- Value of transactions blocked or flagged for review
- Reconciliation exceptions as a share of total transactions
- Liquidity utilisation and hedging effectiveness against realised profit and loss
Security
Network congestion response
When network fees spike and threaten confirmation times, route transactions to layer 2 rollups or alternative networks where your merchant settlement commitments permit it. Fee estimation and dynamic prioritisation let you balance cost against the confirmation window you have promised. Define in advance which merchants and transaction types can be rerouted, because that decision is difficult to make well during an incident.
Transaction laundering and circular flows
Blockchain analytics can identify circular transaction patterns, rapid asset swaps, and structuring designed to stay below reporting thresholds. Define the response before you need it: which patterns trigger a flag, which trigger a freeze, when funds are held, and how and when you report to the relevant authority. An undocumented response is difficult to defend to a supervisor or a banking partner afterwards.
Build versus partner trade-offs
- Building gives you full control over the stack, all revenue, and the freedom to develop tailored merchant products and data services on top of it.
- Building costs more upfront and commits you to continuous compliance, custody and security work that does not scale down when volume dips.
- Partnering shortens time-to-market and provides immediate access to pre-integrated liquidity and settlement rails with a smaller operational team.
- Partnering means less direct control over parts of the flow and introduces vendor risk, as well as service-level agreements you have to manage actively.
A practical 12-month rollout plan
Months 0 to 2: planning and legal scoping
- Identify target jurisdictions and map the licensing requirements for each.
- Shortlist banking partners and begin due diligence, allowing more time than the engineering plan suggests.
- Draft the risk appetite, KYC and AML policies, and the initial technical architecture.
Months 2 to 6: core build
- Implement the API gateway, payment switch and wallet management components.
- Integrate several liquidity providers and at least one fiat banking partner.
- Stand up sandbox environments and the internal dashboards you will monitor in production.
Months 6 to 12: testing and pilot
- Run testnet transactions, smart contract audits and penetration tests.
- Finalise KYC vendor integrations and tune monitoring rules against real traffic.
- Pilot with a small merchant cohort, refine routing, then onboard enterprise clients in stages.
Where Bitpace fits
Liquidity and routing
A liquidity aggregation layer is one of the more expensive parts of the stack to build well and one of the least visible to merchants. Integrating an established gateway moves that work off the roadmap entirely. Bitpace connects to multiple liquidity providers and applies execution logic across them, allowing you to maintain competitive merchant rates without having to operate the routing infrastructure yourself.
Whitelabel launch and time to market
Whitelabel payments let you launch under your own brand while processing, conversion and settlement run on infrastructure that is already live and already authorised. The usual patterns are to call Bitpace APIs directly for payment acceptance or to embed hosted checkout components where you want to minimise integration work. Lead times depend on the level of customisation you need, but they are consistently shorter than for a full build.
Developer integration paths
Bitpace APIs cover payment acceptance, conversion and automated settlement, which removes most of the routing and treasury code from your own backlog. Start in the sandbox, validate settlement and reconciliation against your ledger, then move to production in stages. The Bitpace developer documentation is the starting point for API reference and integration examples.
Next steps
Decisions to settle first
- Which markets you will serve, and which authorisations each one requires
- Which banking and liquidity partners can support those corridors
- Whether you are building the liquidity and settlement layer or integrating it
- What settlement cadence and latency you are prepared to commit to contractually
Documentation merchants will expect
Merchant-facing material shortens sales cycles and reduces support load, so treat it as part of the build rather than a marketing task that follows launch.
- An FAQ covering the regulatory and settlement questions merchants ask most often
- A step-by-step integration guide written for the merchant’s engineering team
- A compliance checklist for onboarding, so legal and KYC reviews move faster
Where to start
Begin with legal scoping and banking partner selection. Both take longer than any engineering task, and both constrain what you can offer. Define the metrics and service levels you will hold yourself to before the pilot starts, not after. Then run a limited integration with Bitpace or a comparable provider to test routing, settlement, and reporting against real merchant flows. Merchant onboarding time and settlement latency are the two numbers that will tell you soonest whether the design works.
Start accepting crypto payments with Bitpace’s crypto payment gateway.
Get paid in Bitcoin, Ethereum, Litecoin and many more established cryptos. Contact Bitpace to discuss your payment and settlement requirements.
Frequently asked questions
What is a PSP payment infrastructure?
A PSP payment infrastructure is the end-to-end stack that accepts, routes, converts and settles payments for merchants. It spans onboarding, payment acceptance, routing, custody, conversion, settlement, reconciliation and reporting. The design matters commercially because it determines your margin per transaction, your compliance position and the settlement experience merchants actually receive.
Which technical components should a PSP prioritise?
Prioritise the API gateway, the payment switch that handles routing, a liquidity aggregation and conversion engine, custody with separated hot and cold controls, and the settlement and reconciliation ledger. Monitoring and reporting should be built alongside these rather than added later. Integrating an established gateway can cover the liquidity and settlement layers if you would rather not build them.
Why does regulation matter so much for a PSP build in 2026?
The travel rule has applied to crypto-asset transfers since December 2024, and DORA has required ICT risk management and incident reporting from EU financial entities since January 2025. Audit trails, transaction monitoring and beneficial ownership checks need to be designed in from the start, because retrofitting them is slow and the practical penalty for gaps is usually the loss of a banking relationship.
How does a crypto PSP differ from a fiat PSP?
Crypto PSPs operate under probabilistic finality, so they monitor for chain reorganisations and set confirmation thresholds for each asset. Network fees introduce a variable cost that batching and network choice can reduce. Multi-asset liquidity complicates price discovery and routing. There is also no card-style chargeback: on-chain payments are generally irreversible once confirmed, so refunds are separate outbound payments and disputes are resolved commercially.
How should transaction monitoring and AML controls be designed?
Combine rule-based detection with anomaly detection, and screen against sanctions and politically exposed persons lists on an ongoing basis rather than only at onboarding. Capture provenance metadata, complete KYC checks, retain immutable audit logs, and build a triage workflow so alerts are actually worked rather than accumulating. Keep model outputs explainable because supervisors and banking partners will ask why a specific transaction was flagged or cleared.
Should you build your own PSP infrastructure or partner with a gateway?
Compare four things: time to market, compliance burden, engineering cost, and the level of margin control you need. Build if control of the full stack is central to your proposition and you already have in-house expertise in compliance, custody, and liquidity. Choose a partner if you want to launch sooner and would rather not carry liquidity, settlement and custody operations. A whitelabel arrangement with a provider such as Bitpace sits between the two, keeping your brand and merchant relationships while someone else runs the settlement infrastructure.
