Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


These support forums are now closed for new topics and comments.
Please head on over to http://eureka.ucommerce.net/ for support.

  • John Walker 43 posts 66 karma points
    Oct 25, 2011 @ 10:22
    John Walker
    0

    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

  • Søren Spelling Lund 1797 posts 2786 karma points
    Nov 09, 2011 @ 15:01
    Søren Spelling Lund
    0

    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.

  • John Walker 43 posts 66 karma points
    Nov 09, 2011 @ 15:06
    John Walker
    0

    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

  • Søren Spelling Lund 1797 posts 2786 karma points
    Nov 10, 2011 @ 12:21
    Søren Spelling Lund
    0

    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.

  • John Walker 43 posts 66 karma points
    Nov 10, 2011 @ 12:40
    John Walker
    0

    Great stuff thanks for pushing through with this.

     

    John

  • Søren Spelling Lund 1797 posts 2786 karma points
    Nov 29, 2011 @ 16:23
    Søren Spelling Lund
    0

    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.

     

  • Søren Spelling Lund 1797 posts 2786 karma points
    Dec 12, 2011 @ 11:10
    Søren Spelling Lund
    0

    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 :)

Please Sign in or register to post replies

Write your reply to:

Draft