I have managed to setup the integration with SagePay really easily following the steps in the http://www.publicvoid.dk/SetupUCommerceToIncludeSagePayAsAPaymentMethod.aspx post. I also added the optional steps for updating orders in the back-end, marking an order complete works absolutely great a marks the transaction authorised in sagepay put when I attempt to cancel a New Order I receive:
"The TxAuthNo you supplied does not look valid. TxAuthNo should contain the VPSAuthCode for the original transaction and should be a long integer number." response from SagePay dong a Google on the error doesn't bring up a great deal but someone mentions that it could be to do with trying to cancel an order which is only Authenticated?
Has anyone else come across this issue or am I doing something incorrectly? Any help would be much appreciated.
I dug into this and found that SagePay is not returning the TxAuthNo during the initial registration of the transaction. I performed the test against the simulator. I'm working with SagePay to figure out what's going on.
Can you verify that the issue is the same in the live environment? Unfortunately we don't have access to a live account for testing purposes.
Interestingly the TxAuthNo is returned when the transaction is acquired and subsequent refund works like a charm.
I have not been able to test on a live account, like your self I don't actually have access to one. Yeah I noticed that also the TxAuthNo is fine once payment acquired. Reading on some forums looks like the cancel of an authorised payment is different to cancelling a acquired stauts.
It is indeed different. Two separate APIs are required for voiding registered payments (authorized payments in uCommerce parlance) and cancelling transactions (acquired payments).
I took a look at the changelog for the SagePay module and nothing has changed on our end since we originally published it. Testing did include cancelling authorized payments.
Still working with Sage on this. You can follow along on their forum if you're interested. From my perspective it looks like it boils down to the simulator behaving differently from the actual gateway, but we'll see.
Sage finally got back to me with an answer. Looks like my assumption about the simulator was correct; it indeed behaves differently from the test/live environment when you authorise new transactions. You should receive a TxAuthNo in the reponse, but it's not there. Sage will update the simulator as as consequence.
uCommerce back-end and SagePay integration
Hi,
I have managed to setup the integration with SagePay really easily following the steps in the http://www.publicvoid.dk/SetupUCommerceToIncludeSagePayAsAPaymentMethod.aspx post. I also added the optional steps for updating orders in the back-end, marking an order complete works absolutely great a marks the transaction authorised in sagepay put when I attempt to cancel a New Order I receive:
"The TxAuthNo you supplied does not look valid. TxAuthNo should contain the VPSAuthCode for the original transaction and should be a long integer number." response from SagePay dong a Google on the error doesn't bring up a great deal but someone mentions that it could be to do with trying to cancel an order which is only Authenticated?
Has anyone else come across this issue or am I doing something incorrectly? Any help would be much appreciated.
John
Hi John,
I dug into this and found that SagePay is not returning the TxAuthNo during the initial registration of the transaction. I performed the test against the simulator. I'm working with SagePay to figure out what's going on.
Can you verify that the issue is the same in the live environment? Unfortunately we don't have access to a live account for testing purposes.
Interestingly the TxAuthNo is returned when the transaction is acquired and subsequent refund works like a charm.
Hi Soren,
I have not been able to test on a live account, like your self I don't actually have access to one. Yeah I noticed that also the TxAuthNo is fine once payment acquired. Reading on some forums looks like the cancel of an authorised payment is different to cancelling a acquired stauts.
John
It is indeed different. Two separate APIs are required for voiding registered payments (authorized payments in uCommerce parlance) and cancelling transactions (acquired payments).
I took a look at the changelog for the SagePay module and nothing has changed on our end since we originally published it. Testing did include cancelling authorized payments.
I'm still waiting on a reply from SagePay.
Great stuff thanks for pushing through with this.
John
Hi John,
Still working with Sage on this. You can follow along on their forum if you're interested. From my perspective it looks like it boils down to the simulator behaving differently from the actual gateway, but we'll see.
Hi John,
Sage finally got back to me with an answer. Looks like my assumption about the simulator was correct; it indeed behaves differently from the test/live environment when you authorise new transactions. You should receive a TxAuthNo in the reponse, but it's not there. Sage will update the simulator as as consequence.
Thanks for reporting the issue :)
is working on a reply...