Transaction Reconciliation for fintech developers and platforms

Build an event ledger, not a balance patch

API platforms fail reconciliation when they store only the latest balance or translate every partner message into a generic debit. A reliable ledger preserves the original financial event, its lifecycle and the relationship between authorization, settlement, reversal, refund and fee.

Minimum event model

• A stable internal event ID and the partner event ID.
• Account, card token, currency, signed amount and event type.
• Occurred, received and posted timestamps.
• Status transitions without deleting the prior state.
• Links to the original authorization or funding instruction.
• Raw partner reference retained securely for investigation.

Worked lifecycle

A merchant authorizes USD 40. The card's available amount decreases while the event remains pending. The merchant settles USD 36, so the ledger posts a USD 36 settlement and releases the unused USD 4. If a USD 10 refund arrives later, it links to the settlement. Reporting must not display this as three unrelated charges, and the platform-wallet ledger must remain separate unless an explicit wallet-to-card operation occurred.

Daily control report

Compare internal events with partner events by currency and type. Flag missing partner IDs, duplicate webhook IDs, pending authorizations beyond their expected age, settlements without authorizations, refunds above settled amount and any balance movement without a ledger event. Every manual correction needs an immutable operator and reason.

Additional FAQ

Is a balance comparison enough?

No. Equal ending balances can conceal duplicated debits and missing refunds. Reconciliation must compare events and lifecycle relationships.

How should webhook replays be handled?

Store a unique partner event identifier and make posting idempotent. A replay may update delivery metadata but must not create a second financial event.

Frequently asked questions

What should be checked before the first transaction?

Confirm the displayed fees, available balance, supported use case, card status and merchant requirements. Start with a controlled amount and retain the resulting ledger entry.

Does a virtual card guarantee merchant acceptance?

No. Acceptance depends on the issuer program, merchant rules, geography, verification requirements and current risk controls.

How should teams evaluate operational quality?

Review fee disclosure, card controls, transaction detail, refund handling, support channels, API idempotency and incident procedures.