Payment reconciliation and registers: a practical model

1. Data that must be connected

The minimum chain includes the order in the merchant system, the payment attempt at the provider, a confirmed result and the relevant settlement-register row. Each entity needs a stable identifier. This separates retries from new payments and avoids matching solely by amount and timestamp.

A practical record contains the order ID, provider payment ID, amount and currency, payment method, creation and completion time, final status, fees, refunds and settlement reference. Personal and payment data should be retained only as required under the applicable controls.

• create a unique merchant-side order_id;
• store provider_payment_id from the API response;
• use one agreed time zone in reports;
• keep original events immutable.

2. Daily reconciliation cycle

First, the merchant system builds a list of payment events received through the API and webhooks. It is matched to the provider register by identifiers, amount and final status. Fees, refunds, reversals and settlement entries are then checked separately.

Automation should surface exceptions rather than hide them. Common groups include a provider payment without an order, an order marked paid without a final event, an amount mismatch, an incomplete refund or a record allocated to the wrong reporting period.

• auto-match exact records;
• send exceptions to a dedicated queue;
• assign ownership for financial mismatches;
• close the period only after documented resolution.

3. Statuses, fees and refunds

Operational reporting and accounting entries serve different purposes. The operational view explains the payment journey, while the financial register explains money movement: gross amount, deductions, refunds and net settlement. Terms and timing depend on the contractual and banking setup.

A refund should always reference the original payment. For partial refunds, keep each transaction and the remaining refundable balance. This prevents over-refunding and supports customer-service investigations.

• do not blend sales and refunds into one opaque total;
• record the reason and author of manual adjustments;
• align register interpretation with contractual terms;
• maintain an auditable change history.

4. Implementation approach

Start with a data map: where the order is created, who assigns identifiers, which source controls the final status and who confirms settlement. Then define the register format and handling rules for every exception type.

WHITECAPITAL provides statuses, webhooks and operational data within an approved merchant setup. Exact reporting formats, method availability and settlement cycles are determined during onboarding and confirmed in the relevant documents.

• define a source of truth for every field;
• test duplicate webhooks and missed events;
• run a trial reconciliation before launch;
• monitor the rate of manual exceptions.

Questions and answers