When a customer reports a successful payment while an order remains pending, do not begin by marking it paid from a screenshot alone. First correlate the order with its provider transaction and check the source record. The payment may be incomplete, a notification delayed, an endpoint rejecting events, or the application applying them incorrectly.
Separate browser navigation from server confirmation
A customer can close the payment page before returning to your website, and connectivity can fail after the provider accepts an operation. The browser return URL should therefore not be the only confirmation mechanism. Establish how the server receives events and queries a transaction using the capabilities of the selected provider.
Validate the status, amount, currency and order reference against the intended record. Authorization and capture can be distinct stages; a successful technical response is not automatically a final financial settlement. The state model must follow the provider's documented lifecycle.
Verify an event before applying it
A webhook is a notification sent to an endpoint on your server. Validate it using the mechanism documented by the provider and protect any verification secrets. An incoming request containing a familiar order number and the word successful is not sufficient evidence.
Apply a verified event to the appropriate record only. Event identifiers and a redacted processing log help support staff understand the sequence without exposing unnecessary payment information or credentials.
Handle repeats and out-of-order delivery
A provider may repeat an event after a timeout or temporary failure. Processing it again should not trigger another shipment or grant the same credit twice. Similarly, an older event should not overwrite a newer, incompatible state simply because it arrived later.
Define the accepted state transitions, refund and cancellation handling, and situations requiring a fresh provider lookup. The website and app integration guide can help establish responsibility between your interfaces and external systems.
Reconcile orders without a clear outcome
A scheduled process can review transactions that remain unresolved beyond an agreed interval. Query the provider, then update the order or escalate it to an authorized reviewer. Do not treat every pending order as successful, and do not initiate another charge merely because the earlier confirmation is missing.
The administration screen should show the last check, transaction reference and state without exposing secrets or unnecessary payment details. Keep sandbox tests separate from real customer transactions and accounts.
Scope the repair before replacing the entire integration
Prepare the provider names, order-creation flow, affected states and anonymized examples with timestamps. Effort depends on the number of gateways, any refund or subscription flows, log quality and access to a suitable test account. A narrowly reproduced defect may need a focused fix; broader inconsistent state handling may require a larger repair.
Does reaching the thank-you page prove payment? No. Confirm the server's state against the agreed authoritative source.
Must the whole checkout be rebuilt? Not necessarily. The issue may be limited to event reception, order transitions or reconciliation. Diagnose the failing layer before extending scope.
Discuss a payment integration review using a description of the failure, not gateway keys or customer card data. Confirm the acceptance cases, estimate and delivery plan after the technical review.
A practical acceptance example
Suppose the customer sees payment success while the order remains pending. The server checks the provider's transaction and verifies notifications before updating state. Test duplicate, delayed and out-of-order events. Define reconciliation of unresolved cases and administrator permissions while separating test transactions from genuine customer payments.
Request a payment and order status integration review
