2

I am experiencing a very frustrating issue with SagePay Direct when a card payment initiates a 3DSecure challenge.

Customers are reporting either a hanging iFrame, or payment declined response. Whats worse is that in some instances, Sage takes the payment but the user is unaware of this and tries to buy again Looking at my logs my code is working as expected and is loading the iFrame with the returned ACSURL as the src.

After searching the web, it appears it is a known issue with a timeout occurring on the secure merchant issuer that i hand off to.

The trouble i have is that i have no control of the response(or lack of) from the issuer as its in an iFrame.

Sage have not been very helpful with this problem only going as far as to say "we have heard of customers who experience this issue"

Does anyone have any experience of this problem and know how to resolve it? I guess the bottom line is to turn off the 3DSecure checks but this seems counter productive to the new EU ruling coming into force at some point.

Worth pointing out that this is only affecting a small percentage of my customer base and a lot of transactions are processing successfully (even with the password challenge) but the customers who experience problems are rightly shouting loudly.

anyone any ideas?

Thanks

timscuk
  • 27
  • 4
  • I encountered the same problem with a client website. It started around mid April in this case. I got only made aware of the problem today and will investigate closer and let you know if I find anything that could help to solve it. – KH S May 07 '20 at 13:06
  • I never really got to the bottom of this issue. I did create a vanilla stand alone page that handled the post to the third party referrer because a suggestion from Sage was I may have images or Javascript on the page hosting the iframe that were being blocked on random occasions by the authoriser. This reduced the number of failures but did not sort all of them so in the end I had to turn off 3DS. – timscuk May 11 '20 at 08:04
  • I am waiting for version 2 of 3DS to be launched by Sage in the hope that the new process might be a bit more forgiving. in the meantime i have had ZERO numbers of this type of failures on payment since 3DS has been turned off so i can say with a high degree of confidence that the issue is with some types of 3DS authorisation requests. Very odd and not a good outcome for a solution that will soon be enforced. I appreciate any fixes you can find at some point . – timscuk May 11 '20 at 08:05
  • I found that the problem with my system was caused that the customer "got logged out" after the last response from the SagePay and that resulted in the not completing of the order. I used a modal for the iFrame. I removed the modal and added a button on the page which receives the SagePay response. The button does a Postback and all seems to be fine. My best guess is that a Server (Microsoft) Update caused the problem on my end. – KH S May 12 '20 at 09:17
  • I am waiting for v2 too. No word yet what happens with that. – KH S May 12 '20 at 09:17

2 Answers2

4

We process up to 1000-2000 transactions daily via SagePay, using the Direct protocol. They are very cheap but their service is in all honesty fairly terrible. We have a single digit quantity of transactions every day that fail in this way. We've also got another provider and don't experience the same issues.

We have a routine job that asks the SagePay Reporting API about transactions that failed, to see what the current status is (did SagePay get the transaction? was it successfully authorised? etc). This API is utterly, utterly terrible and was a nightmare to integrate with, but it's useful as at least we can refund customers without having to log into the SagePay dashboard.

One thing that we discovered (that isn't documented anywhere on the SagePay site as far as I can tell) is that you're limited to one transaction at a time, or around 20-30 transactions per minute by default. If you go over this (a temporary peak or whatever) your transactions queue up and are delayed. If it gets really busy it completely falls over, and takes a while to recover. We had to switch SagePay off entirely for a few hours due to this (we've got backups in place).

Anyway, so it turns out our transactions were all being processed on one TID (short for Terminal ID). This is akin to a physical card terminal in a shop which can only process one transaction at a time. We asked SagePay support for more and we now have 10-15.

I hope this helps you. I'd recommend implementing a fallback payment supplier in case SagePay fails. A year or two ago they had a 3 day(!!!!) outage which was fairly devastating for us. We now take this seriously!

S.Thomson
  • 240
  • 1
  • 9
  • I completely agree. It's absolutely mess. We extract snippets out of support, like "yeah wait a second before making that call, otherwise you'll get 1017" that aren't documented anywhere. There non-workable (okay barely workable) idempotency is frustrating. Opayo just copied and paste the API docs on their site, think they've bought a lemon with anyone moving to Stripe/Adyen/Braintree/Square next upgrade – Mâtt Frëëman Apr 21 '21 at 09:57
1

We've recently had an increase in what I believe may be the same thing. Basically the customer would be sent off to the 3ds page, then returned to the callback page, but for reasons I can't explain the PHP session wouldn't reestablish. The POST response to the callback page was enough to identify the order and complete it (as we'd taken payment), but the customer would then subsequently be prompted to log in again - they'd then see their basket as still having products in and place a second order (that would go through successfully).

After many hours debugging and making changes I managed to replicate this on a development server whilst using mobile emulation...

Long story short, what I have done is to add:

session_regenerate_id();

When I perform the initial vsp register CURL (this is the CURL where you get given the ACSURL). So far, this seems to be enough to ensure that the session gets reestablished when the customer returns to the callback page.

PeteAUK
  • 968
  • 6
  • 16