ComGate

What happens after payment

Being paid does not mean the money is in the merchant's account. A payment is authorised, then settled, and only afterwards does the provider remit an aggregate amount — usually covering several orders and arriving with a delay. That delay routinely surprises merchants who plan stock purchases against daily takings.

It creates a practical task: matching the aggregated payout back to individual orders. Done by hand this is repeated administration that grows disproportionately with turnover. With a proper integration the provider's statement is imported and reconciled automatically.

Why the webhook beats the redirect

The intuitive design marks an order paid when the customer returns to the shop after paying. That is fragile — the customer may close the window, lose signal, or come back before the payment finishes.

So gateways also deliver the result server to server, through a webhook. The shop is then told what happened regardless of what the customer's browser does. Without it, paid orders sit in an “awaiting payment” state and somebody chases them by hand.

• Order state changes on the server confirmation, not on a browser return.
• A repeated delivery of the same message must not pay the order twice.
• Failed and cancelled payments get their own states, not the pending one.
• Refunds are written back to the order so accounting and stock agree.

Disputes and chargebacks

Card payments come with a mechanism by which a cardholder can dispute a transaction through their bank. The merchant then has to show the order was delivered. The evidence — order confirmation, proof of dispatch, customer correspondence — has to be findable, ideally attached to the order rather than sitting in one person's mailbox.

This is the real difference between a gateway wired in superficially and one wired in properly. When payment state, documents, and shipping live in one system, a dispute takes minutes. That is precisely the job of a custom e-shop that does not keep payments and orders apart.