Multi-PSP Reconciliation: Unifying Multiple Payment Gateways
Aggregating settlement feeds, standardizing fee structures, and resolving exceptions across multi-processor payment architectures.
Schema Standardization Across Payment Gateways
To reconcile disparate PSPs, systems map vendor-specific fields (e.g., Stripe's txn_id vs Adyen's PSP Reference vs Braintree's Transaction ID) to a canonical internal payment event. This enables uniform matching logic regardless of which processor acquired the transaction.
Managing Asynchronous Settlement Cadences and Holdbacks
Different processors operate on differing settlement delays: T+2 rolling payouts, weekly batches, or 180-day risk reserves. Internal ledgers must track processor-specific clearing accounts to differentiate settled bank deposits from in-transit processor receivables.
Consolidated Settlement Verification via the NAYA Proof Engine
The NAYA Proof Engine parses batch settlement reports from all connected gateways, matches them against internal authorization records, and verifies that net bank deposits match expected payout figures with zero unexplained variances.
Frequently Asked Questions
Common questions about this topic
QWhat is multi-PSP reconciliation?
Multi-PSP reconciliation is the process of matching transaction records from two or more payment service providers against a single source of truth, typically internal ledgers and bank statement feeds. The objective is to verify that all transaction flows settle accurately with complete auditability, regardless of the routing gateway.
QWhy is reconciling across multiple payment processors harder than single-PSP?
Four structural factors make multi-PSP reconciliation harder: ID schema fragmentation (each PSP uses different identifiers for the same events), settlement cycle variability (each PSP settles on a different schedule), report format divergence (data is delivered via different channels), and inconsistent dispute/refund lifecycles. The complexity multiplies rather than adds when you operate two or more PSPs simultaneously.
QHow do you normalize IDs across different payment processors?
Normalization maps each PSP's proprietary transaction identifiers to a canonical internal ID before attempting any matching. For Stripe, the canonical key is typically the payment_intent_id. For Checkout.com, the payment_id. For Braintree, the transaction_id. The normalization layer must handle one-to-many relationships (one payment intent may generate multiple balance transactions) and map each PSP's event types to a common taxonomy.
QHow should you handle settlement timing differences between PSPs?
Establish processor-specific settlement timeframes and maintain unmatched records within an active reconciliation buffer until the designated window elapses. For example, Stripe transactions may settle on a T+2 schedule while international Checkout.com flows require T+4 or T+5. Applying uniform settlement windows across heterogeneous PSPs creates false exception flags.
QDoes NAYA support multi-PSP reconciliation natively?
Yes. NAYA is designed for multi-source financial environments. Rather than maintaining separate pipelines per PSP, NAYA normalizes all PSP data into a canonical transaction model at ingestion, then runs a single matching pass across all PSPs simultaneously. Stripe, Checkout.com, Braintree, and Square are all supported out of the box. Multi-PSP stacks with four or more processors are supported with no additional configuration.
QWhat is the most common cause of reconciliation breaks in multi-PSP stacks?
Schema mismatches across provider data fields represent the most common structural cause of breaks. Operationally, dispute lifecycle divergence creates frequent discrepancies: when a dispute resolution adjusts a future payout batch on one gateway while internal records track the event in real time, a cross-processor tracking layer is essential for diagnosis.
QHow do you reconcile FX transactions across PSPs?
Capture both original transaction currencies and realized settlement currencies for every payment event, logging the exact FX conversion rate applied at capture. When matching against local bank statements, reconcile using settled currency totals rather than nominal transaction figures to prevent rate drift exceptions.
Get technical insights weekly
Join 4,000+ fintech engineers receiving our best operational patterns.