In a Laravel e-commerce application, the customer's cart lived in the session. Clearing that cart from PayTR's payment callback was the wrong boundary: the callback came from the payment provider's server, not from the customer's browser.
I separated the responsibilities of the two requests. The server notification determines the order's payment state. A page opened by the customer's browser can manage that customer's session. Being part of one checkout flow does not give the requests access to the same session.
A notification is separate from a browser redirect
PayTR sends the application a server notification containing the order reference, payment result and verification data. Independently, the browser is directed to a success or failure address. The requests have different senders, and neither should assume that the other has already completed.
The callback does not carry the customer's session cookie. Removing a cart from the session attached to that request cannot remove the cart the customer sees. Similarly, leaving a success marker in the callback's session does not make it available to the browser's next request.
Clearing the cart where the session is available
I recorded the order reference in the customer's session during checkout. When the browser opens the order page, the page compares its reference with that saved value. A match clears the cart and removes the temporary marker.
The comparison also needs a consistent representation. A reference generated as an integer arrives from a URL as text; a strict equality check will not match until the types agree. This check decides which cart operation belongs to the returning customer. It does not establish that the order has been paid.
Verification precedes the payment transition
Reviewing the callback also meant checking the order of its validation. A request saying that payment succeeded is not sufficient authority to approve an order. The application first needs to verify that the notification carries the expected authentication data.
A failed verification must leave the order unchanged. A repeated notification for an already resolved payment should receive the appropriate acknowledgement without running the state transition or its side effects again. This keeps verification, order state and browser convenience as distinct concerns.
Testing the actual request boundary
A test that only opens the checkout page does not exercise these properties. The useful cases include a callback without the browser session, an invalid verification value and the same notification arriving again after a successful update.
Separating those cases makes the test match the real integration. The important input is not only the body of a request, but who sends it and which state it can legitimately access. The server notification can establish payment state while the returning browser deals with the cart.