The global payment processing solutions market was valued at $74.24 billion in 2025 and is projected to reach $86.09 billion in 2026 and $281.45 billion by 2034, at a CAGR of 15.96%. The broader fintech market — within which payments is the largest segment — reached $394.88 billion in 2025 and is projected to grow to $1.76 trillion by 2034. Cloud-based payment infrastructure now accounts for over 61% of the market. Mobile wallets are growing at a 22.65% CAGR.
The engineering context for 2026: two regulatory deadlines have reshaped the payments technical landscape in the past 12 months. Cross-border financial institution-to-institution payments switched to ISO 20022 exclusively from November 2025. PCI DSS 4.0’s future-dated controls became mandatory on March 31, 2025 — the legacy 3.2.1 standard retired March 31, 2024. Teams building payment processing software now operate in a materially different compliance and technical environment than they did two years ago.
The Payments Architecture Stack
Payment processing software spans multiple layers, each with distinct technical requirements and compliance obligations.
1. Payment Acceptance Layer
The entry point for payment data — the merchant-facing or consumer-facing interface where payment credentials are captured.
For card-present payments: POS terminals communicate with payment processors via ISO 8583 (the card payment message format) or its successor messaging standards. The terminal handles card data capture; the processor handles authorisation routing. EMV (Europay, Mastercard, Visa) chip card processing is the standard, with contactless (NFC/Apple Pay/Google Pay) as the dominant growth channel.
For card-not-present payments (e-commerce): the critical design principle is reducing PCI scope through tokenisation and hosted payment fields. Rather than building a checkout form that captures raw card numbers on your servers, use a hosted payment page or JavaScript payment widget from the payment processor (Stripe.js, Braintree’s hosted fields, Adyen’s web components). The card number is captured directly in a sandboxed iframe served by the processor; your servers never see the raw PAN. This approach moves most of your infrastructure outside PCI DSS scope — a significant compliance simplification.
For alternative payment methods: BNPL (buy now pay later), digital wallets, bank transfers via Open Banking APIs, and real-time payment rails each have their own integration patterns. A modern payment acceptance layer uses a payment orchestration platform to abstract the integration complexity — route to the optimal payment method and processor based on geography, transaction type, and cost.
2. Payment Processing Core
The authorisation, clearing, and settlement layer — the engine that actually moves money.
Authorisation flow: a payment authorisation request travels from the merchant to the acquirer (the merchant’s bank), through the card network (Visa, Mastercard, Amex), to the issuer (the cardholder’s bank) for approval, and back. This round trip must complete in under 2 seconds for acceptable user experience. The network uses ISO 8583 message format for card transactions; ISO 20022 MX message format for bank transfers and cross-border payments.
Real-time payments in the US: FedNow (launched 2023) and the RTP network (The Clearing House) provide instant bank-to-bank payment rails with settlement in seconds, 24/7/365. FedNow messages use ISO 20022 format natively. The integration: your application sends a payment instruction via the ISO 20022 pacs.008 message format to a participating financial institution’s API; the institution routes through FedNow; the recipient receives funds in seconds. FedNow and RTP both include built-in fraud management features that institutions should integrate directly.
Cross-border payments: SWIFT’s cross-border network migrated to ISO 20022 exclusively for FI-to-FI cross-border payments from November 22, 2025. Teams building cross-border payment systems must support ISO 20022 MX message formatting. Institutions that implemented a sidecar architecture — translating legacy MT messages to ISO 20022 at the perimeter — are achieving 98%+ straight-through processing rates ahead of the November 2026 full mandate.
3. Fraud Detection and Risk Layer
Every payment event must be scored for fraud risk before authorisation. A production fraud detection system:
Real-time scoring: the fraud score must be returned within 200–300ms — fast enough to be incorporated into the authorisation decision without user-perceptible delay. The scoring model uses as features: transaction amount, merchant category, cardholder location vs. device location, velocity (how many transactions from this card in the last hour), device fingerprint, and behavioural biometrics.
Network graph analysis: fraud rings — organised groups of fraudsters operating coordinated schemes — are detected by graph analysis of relationships between accounts, merchants, devices, and IP addresses. Graph databases (Neo4j, Amazon Neptune) map these relationships; anomalous cluster structures (many cards transacting at the same small merchant in a short window; new accounts with identical device fingerprints) surface fraud ring activity that transaction-level models miss.
3D Secure 2 (3DS2): the card network protocol for cardholder authentication in e-commerce transactions. 3DS2 performs a risk assessment using shared data (device fingerprint, transaction history, IP address) and challenges the cardholder with biometric authentication only when the risk score exceeds a threshold. Low-risk transactions flow through frictionlessly; high-risk transactions trigger step-up authentication. 3DS2 shifts fraud liability from the merchant to the issuer for authenticated transactions — a significant commercial consideration for high-value merchants.
4. Compliance and Settlement Layer
PCI DSS 4.0: the current Payment Card Industry Data Security Standard. All future-dated requirements became mandatory on March 31, 2025. Key requirements relevant to software architecture: requirement 6.4.3 mandates that all payment page scripts are managed, authorised, and integrity-verified (addressing Magecart JavaScript skimmer attacks on checkout pages); requirement 11.6.1 requires change and tamper-detection mechanisms for HTTP headers and script content on payment pages. These requirements demand active monitoring of payment page JavaScript at runtime.
Tokenisation: raw card PANs should never be stored by the merchant application. Payment processor tokens — stable references to a card that can be used for recurring charges without storing the PAN — are the standard approach. Network tokens (issued by Visa/Mastercard directly) provide additional benefits: they are updated automatically when a card is reissued, reducing decline rates on recurring billing.
Reconciliation and settlement: payment data must reconcile across three sources: the authorisation records (what was approved), the clearing records (what was submitted for settlement), and the actual settlement funds received. Discrepancies — transaction amounts, timing differences, refunds — must be detected and resolved automatically. A production reconciliation system matches records daily and flags exceptions for operations team review.
ISO 20022: What Engineering Teams Need to Know
ISO 20022 is the international financial messaging standard that defines message formats for payments, securities, and trade finance using XML-based MX messages. It replaces the older SWIFT MT message format, which is now sunset for cross-border FI-to-FI payments.
Why it matters for software teams: ISO 20022 carries dramatically more structured data than legacy MT messages. Where an MT103 cross-border payment message has limited, semi-structured fields, the equivalent ISO 20022 pacs.008 message includes structured LEI identifiers, purpose codes, full remittance information, and structured creditor/debtor information. This richer data enables:
- Better fraud detection: structured sender/receiver data improves network graph analysis
- Automated compliance: structured purpose codes enable automated sanctions screening and regulatory reporting
- Better user experience: structured remittance data can surface meaningful transaction descriptions rather than opaque reference codes
Migration architecture: teams migrating existing systems to ISO 20022 have two options. A full rewrite of message generation and parsing to native ISO 20022 (preferred for greenfield and major system rebuilds) or a sidecar translation layer that converts between legacy MT and ISO 20022 MX at the system boundary (pragmatic for existing systems with long migration timelines). The sidecar approach achieves compliance without requiring a full system rewrite, but introduces translation overhead and the risk of data loss when the richer ISO 20022 fields have no MT equivalent.
AI in Payment Processing
AI fraud detection: ML models trained on historical transaction data detect fraud patterns that rule-based systems miss. Key model types: gradient boosting (XGBoost, LightGBM) for transaction-level scoring with high performance and explainability; graph neural networks for network-level fraud ring detection; sequence models (LSTM, Transformer) for detecting anomalous transaction sequences from a single account over time. Production fraud models require continuous retraining as fraud patterns evolve — monthly or weekly model updates are typical.
AI reconciliation: LLMs and structured extraction models automate the reconciliation of unstructured bank statement data against internal transaction records. Invoice matching — reconciling incoming payments against outstanding invoices — is an AI use case that reduces accounts receivable processing time by 60-80% in production deployments.
AI customer support: payment disputes, chargeback queries, and failed payment troubleshooting are high-volume, rule-bound customer service interactions well suited to LLM-based resolution. A payment platform’s AI support agent that can resolve 70% of dispute inquiries without human escalation meaningfully reduces operational cost at scale.
How we approach this at Insoftex
The real-time event-driven infrastructure and compliance architecture that payment processing requires are patterns we have built in regulated fintech contexts. The most consistent finding from our fintech engagements: PCI DSS scope reduction through tokenisation is not a post-architecture optimisation — it is an architectural input that determines where card data flows and which systems carry compliance obligations. On our lending risk platform, the event sourcing design that produced the immutable audit trail for PCI DSS Level 1 compliance was specified before the data model was designed, not added as a compliance layer after the system was built. Retrofitting immutable event logging into an architecture that was designed with mutable records requires a schema change that is significantly more expensive than designing for it initially.
The fraud detection AI layer is where we most consistently find the gap between pilot performance and production reliability. Gradient boosting models for transaction-level scoring perform well in controlled test sets and degrade in production when the transaction distribution shifts — seasonally, with new merchant categories, or as fraud patterns evolve. Monthly or weekly model updates are not optional for production fraud systems; they are the operational cost of maintaining detection accuracy. We scope the retraining pipeline and monitoring infrastructure as explicit deliverables in payment fraud engagements, because fraud teams that discover model degradation by observing rising fraud rates rather than monitoring model performance metrics are three to six months behind where they need to be.
For ISO 20022 migration specifically, the complexity is in the semantic mapping, not the message format conversion. ISO 20022’s richer data model carries information — legal entity identifiers, structured remittance data, purpose codes — that older MT messages did not have. Systems that consume this data need to be updated to handle the new fields or they discard the richer data and lose the value of the migration. We scope the downstream data consumption changes as part of the migration architecture review, not as a follow-up project after the message format conversion is complete.
Building payment processing software? Our fintech engineering team works on authorisation systems, real-time payment rails, fraud detection, and reconciliation infrastructure. Start with a Product Pilot for architecture design, ISO 20022 strategy, PCI DSS compliance, and fraud AI approach in three weeks.
Frequently Asked Questions
What is ISO 20022 and why is it mandatory for payment systems in 2026?
ISO 20022 is the international standard for financial messaging — it defines the data model and XML-based message formats for payments, securities settlements, and trade finance. It replaces the older SWIFT MT message format that has governed cross-border interbank payments since the 1970s. ISO 20022 became mandatory for cross-border FI-to-FI payments on SWIFT from November 22, 2025. The November 2026 deadline marks the final cutover — after which MT messages will no longer be supported for cross-border payments. The business case for ISO 20022 is the richness of its structured data. An MT103 cross-border payment message has limited structured fields for sender, receiver, and remittance information. The equivalent ISO 20022 pacs.008 message includes full legal entity identifiers (LEIs), structured postal addresses, purpose codes, and detailed structured remittance data. This richness enables automated sanctions screening (structured names reduce false positives), automated regulatory reporting, improved fraud detection, and better end-to-end transparency for payment status tracking. For software teams: if you are building any system that originates, processes, or receives cross-border interbank payments — correspondent banking systems, treasury management platforms, FX settlement systems — ISO 20022 MX message support is not optional. Domestic payment systems have varying timelines: FedNow launched natively with ISO 20022; UK CHAPS has migrated; other domestic systems have scheduled migration windows through 2026-2027.
What is PCI DSS 4.0 and how does it change software architecture requirements?
PCI DSS 4.0 is the current version of the Payment Card Industry Data Security Standard — the security framework that governs any organisation that stores, processes, or transmits payment card data. PCI DSS 4.0 was published in March 2022; the previous version (3.2.1) was retired on March 31, 2024; and the 'future-dated' requirements in version 4.0 became mandatory on March 31, 2025. The architectural changes that matter most for software teams: Requirement 6.4.3 mandates that all payment page scripts loaded or executed in the consumer's browser are explicitly authorised (an inventory of all scripts and their purpose must be maintained), have their integrity verified (using Subresource Integrity hashes or equivalent), and are confirmed as necessary. This directly addresses Magecart attacks — where attackers inject JavaScript skimmers into payment pages to capture card data. Requirement 11.6.1 requires change and tamper-detection mechanisms for payment page HTTP headers and script content, with alerts when unauthorised changes are detected. Requirement 8.6.1 requires that all interactive logins to system components use multi-factor authentication — applying MFA to all administrator and developer access to payment infrastructure. For e-commerce teams: the practical response to 6.4.3 and 11.6.1 is implementing a Content Security Policy (CSP) that allowlists authorised scripts, monitoring for CSP violations, and adding script integrity validation to your deployment pipeline. Third-party payment widgets and analytics scripts loaded on payment pages must be explicitly inventoried and authorised.
How should payment processing software handle chargebacks and disputes?
Chargebacks occur when a cardholder disputes a transaction with their issuing bank, and the issuer reverses the transaction — debiting the merchant's account and initiating a dispute resolution process governed by card network rules. Chargeback rates above 1% (of transaction volume) trigger card network intervention and potentially merchant account termination. Managing chargebacks requires both software architecture and operational process. On the software side: a chargeback management system receives dispute notifications from the payment processor via webhook or API, automatically retrieves the relevant order and transaction evidence (purchase confirmation, delivery proof, customer communication history, IP/device fingerprint at purchase time), packages the evidence per card network requirements (Visa's Compelling Evidence 3.0 framework; Mastercard's Dispute Resolution process), and submits the response within the response window (typically 20–30 days). Automation is critical at scale — manual chargeback response is operationally expensive and error-prone. On the fraud prevention side: 3DS2 authentication shifts liability from merchant to issuer for authenticated transactions; velocity checks and velocity rules reduce friendly fraud (cardholders disputing legitimate charges); and clear merchant descriptor names (what appears on the cardholder's statement) reduce 'unrecognised transaction' disputes. Architecturally: every transaction event (authorisation, capture, refund, dispute notification) should be stored in an immutable event log that can reconstruct the full transaction history for dispute evidence, even if the transactional database has been updated by subsequent events.
What is the difference between a payment gateway, payment processor, and acquirer?
These three terms describe distinct roles in the payment processing chain, often confused because some providers operate in multiple roles simultaneously. A payment gateway is the software layer that accepts payment data from a merchant application, validates and formats it, and transmits it to the payment processor. It handles the technical interface between the merchant and the payments network — API connectivity, message formatting, encryption, and routing. Stripe, Braintree, and Adyen's APIs operate as payment gateways (among other functions). A payment processor handles the authorisation transaction — it receives the payment request from the gateway, routes it through the card network to the issuing bank for approval or decline, and returns the authorisation response. It handles the message translation, network connectivity, and settlement processing. A payment acquirer (acquiring bank) is the financial institution that holds the merchant's account and bears the financial risk of the merchant's transactions. The acquirer settles funds to the merchant after clearing. Most merchants work with an acquiring bank indirectly — their payment processor handles the acquirer relationship, and funds settle to the merchant's bank account. In practice: Stripe acts as gateway, processor, and acquirer (through its banking partners) for most merchants. Large merchants or platforms processing high volumes often work with a separate acquirer and a separate processor to optimise interchange rates and routing. Payment orchestration platforms sit above the gateway layer, routing transactions across multiple gateways and processors based on cost, performance, and redundancy — the architecture pattern for large platforms processing tens of millions of transactions per month.