You Clicked Pay. The Screen Froze. Did Your Money Move?

The screen failed after the important action had already happened

You buy a fictional R450 ticket. The page spins, then reports a connection problem. A bank notification appears, but there is no order confirmation. Both screens can be reporting something real: a payment-related event occurred, while the website failed to show you the final outcome.

The internet does not provide one shared screen that every organisation updates simultaneously. Your browser, the merchant, a payment provider and banking systems exchange messages. A message can reach its destination even when the reply does not make it back.

That makes “I did not receive success” different from “nothing happened”. This distinction is useful far beyond payments: reservations, uploads and message delivery can all leave a client uncertain about work performed elsewhere.

Follow the reference number, not just the spinning wheel

A well-designed purchase starts with a merchant order or operation identifier. The service associates the customer's intended purchase with that reference. It can then connect payment requests, later notifications and fulfilment without treating every screen refresh as a brand-new purchase.

Card-payment flows vary, but authorisation commonly asks whether a payment may proceed and can reserve an amount. Capture and settlement concern later parts of completing the movement of funds. A pending bank entry is therefore not necessarily the same thing as a completed settled payment.

The browser may also leave the merchant to complete an authentication step, then return. The merchant must determine status from trusted server-side information, rather than accepting “paid=true” supplied by a browser. A friendly success page is presentation, not the financial source of truth.

For our ticket, imagine the provider accepts a request while the reply connection fails. The merchant may need to ask for the status of that operation or process a verified event notification. The customer should see an honest checking state while that happens.

Which state lets the shop safely issue the ticket?

A useful system models its business states explicitly. “Waiting for a reply”, “payment accepted under the relevant rules” and “ticket issued” should not all be stored as one ambiguous flag. Otherwise an uncertain connection can accidentally become a final decision.

The exact policy for moving to Paid depends on the payment method and the merchant's requirements. This table does not collapse authorisation, capture and settlement into one universal stage. Its purpose is to show why the business must decide which evidence justifies each transition.

Record important transitions with references and useful timestamps. Keep sensitive credentials out of logs. A history that says which operation produced a change is much easier to investigate than a single field repeatedly overwritten by unrelated responses.

Why can pressing Pay again create a second problem?

A new request can be interpreted as a new operation unless the system has a deliberate duplicate-protection policy. Disabling a button helps prevent accidental clicks in that interface, but does not cover a refreshed browser, a network retry or another device.

An idempotency key gives an eligible operation a stable identity. A provider that supports it can recognise a repeat under its documented rules and return the earlier result instead of performing another operation. The merchant must reuse the key for the same intended operation, and use a different one for a genuinely new purchase.

That is not an invitation to attach the same key to every payment forever. Providers define retention, parameter-matching and failure behaviour. The server implementation must follow that contract and protect the order's own state as well.

A payment can be protected against duplication while fulfilment still happens twice

Suppose the payment provider correctly recognises a repeated operation and charges once. The merchant receives two successful notifications. If its notification handler creates a ticket each time without checking the order, the customer can still receive two tickets.

Duplicate protection therefore belongs at more than one boundary. The provider's operation identity protects its own eligible operation. The merchant also needs an appropriate uniqueness rule and transactional handling for its business outcome, such as issuing one ticket for one paid order.

A practical handler first verifies the notification, identifies the event and order, and checks the allowed state transition. It records the accepted outcome so that a repeated event can be acknowledged without repeating fulfilment. The details depend on the database and service architecture.

Two handlers can also run concurrently. A separate “does a ticket exist?” check followed by an unprotected insert leaves a race. The final guarantee needs to be enforced where competing writes are coordinated, not only in a screen or an optimistic application check.

A later message can finish the story after the customer closes the tab

A webhook is a server-to-server event notification. It lets a provider report an outcome even when the browser has gone away. The receiving service must verify that the notification is genuine using the provider's documented mechanism.

Notifications can be repeated, delayed or delivered in an order the merchant did not expect. The handler should record event identities, apply valid state transitions and avoid creating a second ticket for the same successful order. “We received success twice” should not mean “send two products”.

A separate reconciliation process can compare merchant records with provider records to find unresolved differences. This is the operational work behind dependable systems: do not assume every important conversation ended perfectly merely because most of them do.

Why is a browser returning from a bank not the final proof?

A browser return helps the customer continue the journey, but browser-supplied data can be altered. A URL that says status=success is not by itself a trusted financial record. The server should use the provider's documented verification or status mechanism.

Customer authentication is another distinct step. A person completing a challenge may establish something about their authority to proceed, but the merchant still needs the relevant payment outcome. The meanings of authentication, authorisation and successful order fulfilment should not be assumed to match.

A genuine webhook also needs authentication or signature verification according to the provider's contract. Merely exposing an endpoint called payment-success would let an attacker send a convincing-looking request. Verification establishes who supplied the event; business checks establish whether the event applies to this order.

Check amount, currency and reference as appropriate, rather than accepting a success flag detached from the expected purchase. Correctly receiving a real event about another order must not accidentally mark T450 as paid.

What should the customer keep when the outcome is unclear?

Keep the order reference, the time, the amount and the exact message shown. Inspect the merchant's order history and distinguish a pending bank entry from a completed entry where the bank provides that information. Use the merchant's and bank's official support routes to clarify unresolved status.

Do not send a password, PIN, one-time code or full card details to someone offering to “check the payment”. An order reference is useful for investigation; security credentials are not a support receipt. Be cautious about unsolicited messages that appear immediately after a payment problem.

Different providers and payment methods have different reversal and settlement processes. There is no universal promise that every pending amount disappears after a fixed number of hours. Follow the specific provider's published guidance instead of relying on a countdown from an unrelated service.

What would a useful investigation actually compare?

Work through the merchant order, the provider operation and the fulfilment record. Ask whether the payment request was created, whether the provider reports the required outcome, whether that outcome was recorded locally and whether the ticket was issued. Each question narrows the missing link.

If the provider reports success but the order is still unknown, investigate notification delivery and status reconciliation. If the order is paid but the email is absent, inspect ticket creation and email delivery separately. An email arriving late is not proof that payment failed.

For developers, test a connection loss at the exact boundary after acceptance. Then deliver the same event twice, delay it and deliver related events out of order where the provider permits that scenario. These tests exercise the recovery design rather than repeatedly proving that the normal success path works.

For the customer, retain the reference and use official support to resolve uncertainty. The strongest system gives support enough evidence to answer accurately, instead of making the customer reproduce a financial operation to find out what happened last time.

A better error message admits what the system does not yet know

“Payment failed” is misleading if the service has lost the reply and has not checked status. “We are checking this order; please use reference T450” describes uncertainty more accurately, provided the service really performs that check.

Developers should test the awkward boundary: disconnect after the provider accepts the operation but before the browser receives the response. Also test repeated notifications and a customer reopening the page. Those cases reveal whether identity and recovery were designed into the process.

The reassuring feature is not a faster spinner. It is a system that can connect a later answer to the original question without asking the customer to pay twice.

Follow the connections

• Http Explained
• Rest Api Explained
• What Is Api
• Real World Software Projects