Checkout.com Reconciliation: Multi-Currency Settlement Automation

Checkout.com is built for enterprise-grade payment volume — high-throughput card acquiring, global settlement, and multi-currency operations. That power creates reconciliation complexity: multiple settlement cycles, currency conversion at variable FX rates, and a reporting model that requires joining several distinct data exports to build a complete picture.

What Makes Checkout.com Reconciliation Difficult

Settlement Cycle Variability

Checkout.com settles on different schedules by currency and region. EUR settlements may arrive T+1; USD settlements T+2; GBP daily or weekly depending on merchant agreement. Reconciling across settlement cycles requires tracking each currency's timeline separately, not treating settlement as a uniform event.

Multi-Currency FX at Conversion

When a customer pays in EUR and your settlement currency is USD, Checkout.com applies an FX rate at conversion time. That rate is not always the mid-market rate — it includes Checkout.com's FX markup. Reconciling the gross transaction amount, the converted amount, the FX rate, and the resulting settlement requires capturing all four data points per transaction.

Reporting Requires Multiple Data Sources

Checkout.com's reconciliation data lives across several endpoints and file exports: the Payments API (transaction detail), the Financial Actions API (balance movements), and SFTP settlement reports (payout breakdowns). Effective reconciliation requires joining all three — which most internal systems aren't built to do automatically.

Dispute and Chargeback Lifecycle

Checkout.com disputes move through a multi-stage lifecycle: dispute opened → evidence submitted → resolved in merchant's favor (funds returned) or issuer's favor (funds lost). Each stage creates a balance movement. A dispute opened in January may be resolved in March, creating a balance_action in a completely different settlement period from the original charge.

Multi-Merchant Account Management

Enterprise merchants often run multiple Checkout.com merchant IDs — by region, by product line, or by entity. Reconciliation requires tracking which MID processed which transaction, with independent settlement states per MID, while maintaining aggregate visibility across the portfolio.

The Checkout.com Data Model

Full reconciliation requires these Checkout.com data sources:

• Financial Actions API — balance movements including charges, refunds, disputes, fees, and settlements. The authoritative source for what affects your balance.
• Payments API — individual payment attempts with approval/decline status, payment method, and 3DS result.
• Settlement SFTP Reports — payout-level summaries with fee breakdowns, FX rates applied, and net payout amounts per currency.
• Disputes API — dispute records with stage, evidence deadlines, and resolution outcomes.

The reconciliation challenge: Financial Actions use a different reference ID than Payments API records. Joining them requires the payment_id ↔ action_id mapping, which Checkout.com doesn't surface directly — it must be maintained by the reconciliation layer.

Common Checkout.com Reconciliation Failure Modes

• FX variance accumulation — rounding differences at FX conversion compound across thousands of multi-currency transactions. Not a bug; a known property of currency conversion at scale. Must be tracked at the transaction level to reconcile cleanly.
• Missing financial action records — the Payments API and Financial Actions API are not always in sync. A payment may appear in Payments API before its corresponding action is available. Polling-only reconciliation misses these.
• Treating settlement reports as complete — SFTP settlement reports aggregate transactions into payout totals. They're a summary, not a transaction-level record. Relying on them alone makes it impossible to reconcile individual charges to their payout contribution.
• Dispute lifecycle gap — teams that log disputes when opened but not through resolution create a permanent gap between the dispute balance_action and its reversal or write-off.

How NAYA Automates Checkout.com Reconciliation

NAYA connects to Checkout.com's full API surface — not just the settlement reports — to build a complete, continuously updated reconciliation view:

Continuous Financial Actions Sync

NAYA polls the Financial Actions API on a configurable cadence, capturing every balance movement as it occurs. This eliminates the lag inherent in batch settlement report downloads.

ID Resolution Layer

NAYA maintains the payment_id ↔ action_id ↔ settlement reference mapping automatically. When a settlement arrives, NAYA can trace it back to the originating payment without manual cross-referencing.

FX Rate Capture and Variance Tracking

For every multi-currency transaction, NAYA captures the FX rate applied by Checkout.com, the gross transaction amount in the customer's currency, the converted amount in settlement currency, and the net amount after Checkout.com's markup. FX variance is tracked as a distinct reconciliation dimension — not lumped into unexplained differences.

Settlement Deconstruction

When a Checkout.com settlement hits your bank, NAYA deconstructs it to individual transactions using both the Financial Actions API and the settlement report. The net payout matches the bank deposit to the cent. Discrepancies surface as named exceptions, not as unexplained variances.

Multi-Currency Checkout.com Operations

For merchants operating across multiple settlement currencies, NAYA provides:

• Independent reconciliation state per settlement currency
• FX gain/loss tracking at the transaction level, aggregated per period
• Currency-level cash position updated as settlements arrive
• Consolidated cross-currency reporting for finance operations