What Happens Behind an Online Payment: The Full Flow of Ordering, Paying, Webhooks, and Reconciliation

When a user clicks "pay" on your site, a chain of actions happens within seconds: redirect, payment, callback, reconciliation, refunds, and disputes. If you only understand "the user paid", you will be lost when orders drop, charges double, or books do not match. This article breaks down the standard online payment flow.

1. Full Flow at a Glance

Take "a user pays on your site with a third-party provider (e.g., Stripe or Alipay)":

User orders → server creates a payment order → redirect/launch payment → user completes payment → provider calls back your server → server verifies the signature and updates the order → reconciliation → (if needed) refund/dispute handling

2. Step by Step

1. The user orders: the user clicks "checkout"; your server creates an order in the database with a "pending payment" status.

2. The server creates a payment session: the server calls the provider's create-payment API with amount, currency, items, callback URL, etc., and receives a payment URL or token.

3. Redirect to pay: the front end redirects to the payment page (or opens a wallet); the user enters card details or scans a QR code to pay. This step happens in the provider's environment, so your site never sees the card number.

4. Result return: after success, the provider does two things: returns the user to your "return URL", and asynchronously calls your "callback URL" (webhook).

3. Callbacks (Webhooks) and Signature Verification

This is the most error-prone and most critical step:

  • Callback: the provider notifies your server "this order was paid" via a webhook. The request it sends is signed;
  • Signature verification: your server must verify the signature with the agreed secret to confirm the callback really came from the provider, not from an attacker.

Why verification is mandatory: if an attacker forges a "payment succeeded" callback, your system may ship goods without receiving money. Verification is the first line of defense against forgery.

Key rules:

  1. Idempotency: for repeated callbacks of the same order, execute shipping/updating exactly once;
  2. Amount cross-check: the amount in the callback must match the order amount, to prevent "amount tampering" attacks;
  3. Retry on failure: return a non-2xx status when callback handling fails, so the provider retries later.

For implementation, see Webhook Integration Guide and Webhook Signature Verification.

4. Reconciliation

Reconciliation is the process of matching your books against real transactions, usually run daily:

  1. Export settlement details from the provider (status, amount, and fees per transaction);
  2. Compare against your local order database: check for "paid locally but not on the provider side" or the reverse;
  3. Find and handle discrepancies (dropped orders, amount mismatches, double charges).

Dropped orders: the user paid but the callback was lost (network issues), so the local order stays "pending". Countermeasure: run a scheduled job that actively queries the provider for order status and corrects the local status to "paid". This must be in place before going live.

Automating reconciliation: at high order volumes, turn reconciliation into a daily scheduled job that compares automatically and generates a discrepancy report, pushing only the exceptions to humans. Manual reconciliation works up to a few hundred orders a day; past a thousand, it becomes infeasible and scripts are the only realistic option.

5. Refunds

Refunds are relatively simple: the server calls the provider's refund API with the original order or transaction ID. Note:

  • Refunds have fees (some providers do not refund the percentage);
  • Refunds are not instant; they usually take a few business days;
  • Users may refund only part of the amount (partial refunds).

For refund and dispute operations, see Refund and Dispute Handling Guide.

6. Disputes (Chargebacks)

When a user tells their issuer "I never made this charge", that is a dispute (chargeback). The flow:

  1. The issuer initiates the dispute, and funds are frozen or pulled back;
  2. The gateway notifies you, usually giving a 7-21 day response window;
  3. You submit evidence (order, shipping, user confirmation records);
  4. The issuer decides: if you win the funds return; if you lose, funds are pulled and a chargeback fee may apply.

Ways to reduce disputes: clear product descriptions, explicit return policies, keep shipping evidence, and use 3DS verification to reduce "unauthorized" disputes.

7. FAQ

Q1: The user paid but the page showed failure. What now? Trust the server-side callback/reconciliation, not the front-end page the user saw. The page can show "confirming payment result".

Q2: Will repeated callbacks cause duplicate shipping? Yes, unless you implement idempotency. Use "order status check + unique constraint" to ship each order exactly once.

Q3: Reconciliation shows we overcharged a user. How to handle it? Refund the difference through the refund flow and notify the user, to avoid escalation into a dispute.