Quickpay plugin

There is a returning problem with the Quickpay plugin. If a user makes a mistake in the payment window, then the user cannot try again, before the basket is deleted - you get the error: "Order is ia allready in use" from Quickpay. Quickpay tells me that this can be fixed by using payment links instead of a payment window: learn.quickpay.net/tech-talk/payments/link/https://learn.quickpay.net/tech-talk/payments/link/

Could this be implemented in the plugin. We have had several frustrated customers who coould not get the payment to work, because of an abandoned basket after a failed payment attempt.

I/Quickpay would be willing to pay for this development.

I've already implemented support for incrementing the order id on cancellation, but I'm guessing this is some sort of error state and not a cancel? Are they being sent back to CBSubs basket when this happens or are they still at Quickpay when it fails? Can you describe a step by step of what's happening for them so I can try to replicate it and review adding some sort of fix for this. As it certainly should be possible for me to handle an additional increment state for the order id.

As for the payment link you'd be asking me to completely rewrite the gateway into a completely different API. That would require significant financial support to fund the development for that as it's essentially an entirely new gateway. We are however reviewing 3rd party solutions (e.g. something like Omnipay or Payum library) to help us speed up this process and reduce the cost for future CBSubs releases so we hope to bring a lot more gateways to CBSubs in the future. For now though I believe this is fixable with our current gateway implementation.

Hmmm... actually I am not quite shure what happens for the failing users.. could it be because they are impatient and presses the single payment button twice, before it loads the Quickpay window - i've seen some persons do that.

I'm not sure. You'd need to ask them I suppose. I'd need to know specifically where it's failing for those users so I can test and fix that case. Cancellations are already covered (e.g. click back cancel link or failed payment redirects to cancel link).

Ok, was able to create a few situations where this could happens. The below for example.

1. Click to pay at quickpay, uses browser back navigation, refreshes basket, then clicks to pay at quickpay again
2. Click to pay at quickpay, closes the browser, comes back to site later, goes to pay at quickpay again

Both of those can trigger this issue. There maybe a few more, but my fix covers those as well. I've implemented the below for next release of CBSubs.

forge.joomlapolis.com/issues/8938

In short when the basket is rendered and the Quickpay Form parameters are being prepared I first check if the order id exists at Quickpay. If it does I use our existing cancellations incrementing code to increment the order id so it's now unique and no longer in use. This should resolve all existing order id issues from then onward.

That is simply perfect and brilliant ! Thank you.