Provider settlement
- Batch
- SET-018
- Included operation
- OP-021
- Net payout
- €98
Financial software for payments, balances and reconciliation.
We build application and integration components for financial products: payment workflows, provider connections, product ledgers and reconciliation tools. An engagement can deliver a new component or improve an existing platform. We connect the customer-facing action to processing, balances and settlement, with explicit responsibilities for failures, corrections and operation.
Connect the product to the movement of money
A payment interface, processing service and product ledger have different jobs. Connect them around the product’s money flows and the provider’s actual capabilities. The organisation’s qualified teams establish product and legal obligations; our software work implements the agreed rules, interfaces and operating tools.
Handle the payment beyond its request
Request receipt, provider acknowledgement, confirmation and settlement are different states. An accepted request may still be processing, and a confirmed payment may reach the bank in a later settlement batch. Keep provider references connected to the same operation through refunds, reversals and failures.
Amounts need a defined currency and precision. Pending commitments and posted balances serve different purposes; agree which states affect the amount a customer may use, rather than deriving availability from the latest screen status.
Balances come from balanced entries
A double-entry product ledger records the financial effect across accounts, with equal total debits and credits for each currency. The entries in a posting commit together, so a partial write cannot update one side of the balance alone.
The ledger explains obligations and movements; provider responses explain external processing. Connect both without assuming that a balanced posting proves cash has settled. Account structures, fees and recognition rules follow the financial product.
One payment, two balanced entries
Illustrative example. Sample records. OP-021 · JRN-021 · EUR
| Account | Debit | Credit |
|---|---|---|
| Provider clearingAsset: amount due from the provider | €100 | — |
| Customer funds payableLiability: amount owed to the customer | — | €100 |
| Balanced posting | €100 | €100 |
Both entries commit together. Settlement and fees create their own balanced entries. This simplified product-ledger model is illustrative; the account structure and recognition rules follow the product and its finance requirements.
Safe retries and dependable records
Idempotency: repeat the request, keep one operation
Idempotency lets a retry refer to the same intended operation instead of creating a second payment. Retain the operation identity and outcome, check that the request still matches, and coordinate concurrent attempts. Provider key scopes and retention periods are part of the contract.
Request retries and repeated notifications need related but separate handling. A webhook acknowledgement or broker delivery guarantee alone does not prevent a duplicate ledger posting or another external payment.
Correct posted entries without rewriting them
Keep posted financial entries immutable: correct them with a linked reversal or new adjustment instead of replacing their amounts. The original posting and the correction together explain the current balance.
Operational states and metadata can still change under defined rules. Immutability of financial entries does not mean retaining every piece of personal or diagnostic data forever; access and retention remain deliberate decisions.
Reconcile payments, settlements and cash
Match the internal operation to the provider’s settlement detail and the bank receipt. Gross payments, refunds, disputes and fees can explain why the net payout differs from the original payment amount.
Use agreed identifiers, currencies, dates and settlement cut-offs. Keep matched, unmatched and unresolved records distinct, with reasons and responsible owners. Expected settlement timing is different from a missing or incorrect entry; a correction must preserve that distinction.
Explain the payout, then match the bank receipt
Illustrative example. Sample records. EUR · same settlement batch and cut-off
- Gross payment
- €100
- Provider fee
- €2
- Expected payout
- €98
Bank receipt
- Statement entry
- BANK-007
- Matched settlement
- SET-018
- Received
- €98
Matched in this sample. The same currency, batch reference and net amount connect the receipt to the payment.
Simplified sample: one payment, a provider fee borne by the operator, and no refunds or currency conversion. Real batches can include refunds, disputes and other adjustments; unexplained differences stay in review.
Resolve exceptions with the right authority
Provider evidence
Verify the sender and interpret notifications against the provider contract. Repeated or delayed events must not create another financial effect or reverse newer state simply because they arrived last. Use provider lookup and settlement evidence where available.
Pending and unresolved work
A lost response can leave a payment uncertain. Resolve it through provider lookup, later evidence or authorised review before creating another operation. Pending work needs an owner and a next check; an arbitrary timeout cannot establish financial success or failure.
Assess, release and operate
Start with one money flow: its provider interfaces, ledger effects, settlement evidence and failure paths. Validate balanced postings, concurrent retries, duplicate notifications, interrupted responses and authorised corrections alongside ordinary completion.
Release and handover include state definitions, interface contracts, provider assumptions, recovery guidance and owners for unresolved records. Scope follows the product and its dependencies, whether the work is a new component or a change to an established platform.