Payment Processing App Development

Payment processing covers the full lifecycle of a financial transaction after authorisation: clearing, settlement, reconciliation, dispute management, and payout. While the payment gateway handles the real-time authorisation exchange in milliseconds, the payment processor handles the batch processes that run overnight and through the week to actually move funds between banks, reconcile positions, and settle net balances.

For engineering teams building payment infrastructure, the processing layer is where complexity compounds. Settlement files arrive in different formats from different acquirers and card networks. Clearing cut-off windows vary by scheme. Reconciliation needs to match authorisation records to clearing records to settlement credits to within a penny, every day, at scale. Dispute workflows involve multiple parties across multiple timeframes with regulatory deadlines attached to each step.

Scrums.com provides dedicated engineering squads to financial institutions, payment processors, and FinTech companies building or modernising payment processing platforms. Our teams have delivered processing infrastructure for regulated payment institutions across the UK, EU, and Sub-Saharan Africa. See our national payments compliance platform case study for a real-world example.

Payment Processing Architecture

A well-designed payment processing stack separates the real-time authorisation path from the batch settlement path. The key architectural components:

Clearing Engine

After authorisation, card transactions go through clearing: the merchant's acquirer submits transaction data to the card network, which routes it to the issuing bank for the funds to be earmarked. Clearing files arrive in ISO 8583, ISO 20022, or scheme-proprietary formats (Visa BASE II, Mastercard IPM) on a schedule set by each scheme. Your clearing engine needs to parse these files, match them to authorisation records, identify mismatches, and prepare net settlement positions.

Settlement Engine

Net settlement is the process of moving funds between acquiring banks and issuing banks through the scheme's settlement bank. Gross settlement (each transaction settled individually) is used for high-value payment schemes (CHAPS, Fedwire, RTGS). Deferred net settlement (DNS) batches transactions and settles the net position at defined windows, the standard for retail card schemes. Your settlement engine needs to manage settlement accounts, track inter-bank positions, and trigger funding movements through SWIFT, SEPA CT, or RTGS rails depending on the settlement scheme.

Reconciliation Engine

Reconciliation is the control layer of your payment processor. At a minimum, you need to reconcile authorisations to clearing records, clearing records to settlement credits, and settlement credits to your internal ledger. In practice, you also need to reconcile fee invoices from card networks, acquirers, and scheme processors. Discrepancies that aren't caught in reconciliation become profit and loss items, or worse, regulatory findings. The reconciliation engine should be designed as a first-class component with exception management workflows, not as a reporting afterthought.

Dispute and Chargeback Management

Chargebacks are initiated by cardholders through their issuing bank and flow through the card network to the merchant's acquirer. The dispute lifecycle has strict timeframes at each step (typically 20 to 120 days depending on scheme and dispute reason code). Your dispute management system needs to receive dispute notifications from scheme APIs, route them to the appropriate merchant, manage evidence submission deadlines, and track financial liability at each stage. Automation of high-volume, low-complexity disputes (invalid chargebacks, already-refunded transactions) is essential at scale.

The Engineering Complexity of Reconciliation at Scale

Reconciliation is the least glamorous component of a payment processor and the one that most frequently causes serious operational problems. At low transaction volumes, manual reconciliation is workable. At 100,000 transactions per day across five acquirers, three card networks, and two settlement currencies, a manual process breaks down immediately.

The engineering challenges in reconciliation that are frequently underestimated include: matching logic that handles partial authorisations (the authorised amount doesn't match the cleared amount), partial reversals (a portion of an authorisation was reversed but not all), and split settlements (a single clearing file covers multiple settlement periods). These edge cases are rare as a percentage of transactions but common in absolute number at scale, and they need systematic handling, not manual investigation queues.

Our mobile app development work includes reconciliation engine builds for payment processors who inherited broken matching logic, covered in our FinTech platform stabilisation case study. Our legacy modernisation approach covers how to replace reconciliation engines in live production environments without disrupting settlement operations.

Payment Processing Platform Types We Build

Different processing business models have fundamentally different technical requirements. Scrums.com engineering teams have delivered across five platform categories:

Card Acquirer Processing Platform

End-to-end acquiring processor: authorisation gateway, clearing file exchange with Visa/Mastercard/Amex, net settlement management, and merchant funding. ISO 8583 and ISO 20022 message processing, scheme file formats (BASE II, IPM), and settlement through SWIFT gii or local RTGS. PCI-DSS DSP (Direct Service Provider) assessment scope. Relevant to our payments compliance platform delivery.

ISO and PayFac Platform

Payment processing infrastructure for Independent Sales Organizations (ISOs) and Payment Facilitators (PayFacs) that sponsor sub-merchants under a master merchant agreement. Sub-merchant onboarding KYB workflows, transaction monitoring for AML compliance, split settlement to sub-merchant funding accounts, and chargeback liability management across the sub-merchant portfolio. Visa and Mastercard PayFac registration requirements are significant technical and compliance obligations.

Subscription and Recurring Billing Processor

Billing engine for SaaS, subscription, and membership businesses. Configurable billing intervals, proration logic for mid-cycle plan changes, dunning management with retry scheduling, and involuntary churn recovery (failed payment recovery). Revenue recognition in compliance with IFRS 15/ASC 606 for recognised vs. deferred revenue. Integration with GL systems (NetSuite, SAP) for automated journal entry generation.

Cross-Border Payment Processor

Multi-currency clearing and settlement across FX pairs. Correspondent banking relationships for USD, EUR, GBP, and emerging market currency settlement. SWIFT gpi tracking for cross-border payment status. Compliance with FATF travel rule requirements for crypto/virtual asset transactions. ISO 20022 native messaging for interbank settlement. Explore our FinTech engineering capabilities for cross-border builds.

Embedded Finance Payment Stack

Payment processing embedded within a non-financial platform (marketplace, HR software, ERP). White-label processing APIs consumed by the host platform, with regulatory responsibility held by a licensed payment institution. Banking-as-a-Service (BaaS) architecture where the processing platform provides regulated payment infrastructure and the platform provides the UX and merchant relationships. See our dedicated engineering team model for how we staff these builds.

Technology Stack for Payment Processing Development

Payment processing demands technology choices prioritising durability, correctness, and auditability. The stacks our teams deploy:

Processing Core and Message Handling

Java (Spring Boot) and Kotlin for the processing core: the financial services library ecosystem (jPOS for ISO 8583, prowide-core for ISO 20022, SWIFT SDK for gii/gpi) is most mature in the JVM ecosystem. Event sourcing patterns (Axon Framework, Eventuate) provide immutable audit trails essential for regulatory examination and reconciliation root cause analysis. Apache Kafka for processing pipelines: clearing file ingestion, reconciliation job orchestration, and dispute notification routing.

Databases

PostgreSQL for OLTP transaction and ledger data: MVCC concurrency, row-level locking, and partitioning by date range handle large transaction tables well. TimescaleDB or ClickHouse for time-series analytics (settlement position tracking, reconciliation trend analysis). Separate read replicas for reporting workloads so analytical queries don't contend with processing OLTP. Oracle remains common in established acquirers with long-standing regulatory acceptance of the platform.

Batch Processing and Scheduling

Spring Batch for structured batch job execution with restart/retry semantics, step-level transaction management, and job execution history. Quartz or Kubernetes CronJobs for scheduling clearing file retrieval, reconciliation runs, and settlement instruction generation. Dead-letter queue handling (via Kafka or RabbitMQ) for failed batch steps that need investigation before retry.

Infrastructure and Observability

AWS or Azure in multi-AZ configuration. Processing jobs run on dedicated compute to avoid resource contention with online API workloads. Grafana dashboards for settlement position tracking, reconciliation exception counts, and chargeback queue depth. Alerting on reconciliation exception rate increases is as important as API error rate alerting: a reconciliation exception spike often precedes a settlement problem by 24 hours. Our FinTech reliability case study covers observability practices in this context.

Compliance and Regulatory Considerations

PCI-DSS

Payment processors that handle cardholder data require a full PCI-DSS QSA assessment. The specific controls required depend on whether you store PANs (full SAQ D), handle encrypted card data in transit (SAQ D with P2PE scope reduction), or have already isolated card data to a network-tokenised flow (reduced scope). Annual assessment plus quarterly vulnerability scanning and penetration testing are ongoing obligations. See our PCI-DSS software delivery guide for the engineering decisions that affect scope.

Scheme Compliance

Card network membership (Visa, Mastercard) requires compliance with operating regulations that govern everything from chargeback timeframes to data retention to fraud reporting thresholds. Exceeding scheme fraud thresholds triggers the Visa Fraud Monitoring Program (VFMP) or Mastercard Excessive Chargeback Program (ECP) with escalating fines and potential loss of acquiring privileges. Scheme compliance monitoring needs to be a live operational dashboard, not a quarterly review.

Payments Regulation

Payment processors operating in the UK and EU require authorisation as a Payment Institution (PI) or E-Money Institution (EMI) under PSD2/PSRs 2017. The FCA and EBA have specific requirements for operational resilience, safeguarding of customer funds, and incident reporting that translate directly into engineering obligations. Safeguarding (the requirement to hold client money in segregated accounts) needs to be built into the settlement account architecture from day one. Connect with our FinTech engineering team for regulatory architecture guidance.