Thanks, that’s what I thought. It’s just something I was not sure about while I was trying to artificially test the urls being passed about to avoid using the live gateway.
The real crux is this..
-
When the payment is ok,
customer hits “Continue” in the gateway,
this passes the payment transaction id to a file in the shop passing the payment transaction id,
that redirects to the checkout_process,
the payment transaction id is checked against the db record of the transaction,
and the order is recorded via the payment module processes correctly.
All OK.
-
If the payment fails in the gateway,
the customer is presented with "Continue" which takes him (unexpectedly, for most people) back to the payment options screen in the shop, via the usual payment module processes, and is shown an error message.
Despite the error message saying “don’t go back”, if at this point,
he presses the browser back button to go back to the gateway,
and then "continue" again (yes people actually do this),
he goes forward to the shop, gets order success and it is recorded as a discount coupon.
I think that this is happening because the shop doesn't know which payment module to use at this point/ the session information is not now available.
I am working with another version of this module (for osc) that has code that retrieves the session id (stored during process_button) associated with that payment transaction id and then calls checkout_process with that id appended:
Eg:
https://www.shop.com/index.php?main_page=checkout_process&zenid=5iiljnjd08ejbajhqp3k29XXX
But it doesn’t stop the false payment/order being recorded (assuming I am doing it right…!).
How should this really be handled “correctly” (in general terms….)?
I've spent an embarrassing amount of time figuring out how (almost) all of this works, all very educational of course, but I'm stuck at this point.