A successful checkout screen is not sufficient evidence that a payment integration is ready. The server must verify the provider’s payment state, amount, currency and reference, and handle delays or duplicate messages without duplicating orders or inventory effects.
Keep order, payment and fulfilment states separate
An order can be accepted while payment is pending, paid before shipment, or partially refunded after fulfilment. Representing all of these as one success flag hides the exceptions the operations team needs to handle. Agree when inventory is reserved, when the reservation expires and when stock is released.
The customer’s return page is not the sole source of truth. A customer can close the browser after paying, or arrive back before the server notification. The order should reach the correct verified state without requiring another payment attempt. Show a clear waiting state while confirmation is pending.
Run an acceptance matrix in the provider sandbox
| Scenario | Expected outcome |
|---|---|
| Payment declined | Order is not marked paid; safe retry path is explained |
| Success notification arrives late | Existing order updates without a second order |
| Same notification arrives twice | Financial and inventory effects occur once |
| Amount or currency differs | Processing stops for investigation |
| Customer closes browser after payment | Server-side verification can recover the order state |
| Partial refund | Remaining amount and separate refund history are correct |
| Payment succeeds after stock reservation expires | Merchant’s agreed exception policy is applied |
Use the payment provider’s authorized testing environment and test instruments, not unapproved production transactions. Event names, signature verification, retry schedules and refund semantics differ between providers. The actual provider’s documentation governs implementation; a generic checklist cannot replace it.
Test recovery, not only rejection
Identify who can inspect a pending payment and re-query the provider without charging again. The support procedure should identify safe reference numbers and escalation steps. Do not log card numbers, authentication secrets or sensitive payment payloads in analytics.
Test repeated clicks and requests replayed after a poor connection. Disabling the submit button improves the interface but does not provide server-side duplicate protection. Where idempotency keys are supported, define their scope, lifetime and relationship to the intended operation. A new purchase and a retry of an existing purchase must not be confused.
Reconcile before opening checkout
Compare order records with provider records by amount, currency, reference, refund and pending state. Equal transaction counts can conceal mismatched amounts. Retain the sandbox results and tested integration version, then obtain acceptance from the person responsible for financial operations.
Document what happens when automated reconciliation cannot establish the result. Keeping a payment pending for review is safer than inventing a successful outcome. Any production verification involving real payments requires the merchant’s separate authorization.
Use custom ecommerce development to define project scope. Read the payment integration guide and reliable webhook patterns for related implementation decisions. This is general integration guidance, not a promise that every feature is available in ShopTek.
Sources and editorial status
- Stripe payment testing.
- Stripe webhooks, as provider-specific examples, not universal integration behavior.
- Original contribution: the business acceptance matrix; not a financial or security certification.
