Payment reconciliation: why “the customer paid” is not enough for a reliable system
Reliable payment systems separate checkout, provider confirmation and reconciliation so a missed redirect or webhook does not leave the business with the wrong state.
Separate intent from settlement
Creating a payment request means the customer intends to pay. A browser redirect means the browser reached a page. Neither is the same as confirmed settlement. Store a payment record with a unique reference before sending the customer to a provider or initiating a mobile payment request.
Verify provider events
Validate webhook signatures using the provider’s documented method and preserve the provider event identifier so duplicate deliveries can be handled safely. The handler should be idempotent: processing the same successful event twice must not create two receipts or two orders.
Do not depend on one signal
Webhooks can be delayed and browsers can close before a return URL loads. Critical payment systems need a verification or reconciliation path that queries the provider using the transaction reference and repairs records that missed the real-time event.
Match the amount and currency
A successful provider status is only useful if the transaction belongs to the expected merchant, reference, amount and currency. Verify the fields that matter before changing an order or invoice to paid.
Make reconciliation visible
Operations teams need a view of pending, successful, failed and mismatched transactions. Store provider references and timestamps so finance can explain the state without searching raw logs.
Turn the idea into a clear implementation plan.
Use TWE to structure requirements first. If you later want implementation, Valron can pick up the same brief.