5

Opayo returns from our payment request asking us to contact https://www.rsa3dsauth.co.uk/3ds2/cReqWebBased?issuer=barclays" for 3D Secure auth, so we send this:

<form id="c-form" method="POST" action="https://www.rsa3dsauth.co.uk/3ds2/cReqWebBased?issuer=barclays">
  <input type="hidden" name="creq" value="*removed for data protection*" />
  <input type="hidden" name="threeDSSessionData" value="tQtpVHCcCVGEhPNDaeCtMK9I%2fREJERnarovmuZPsM4M6xy6gks9rOYix36waoxOn1wukcobCFbfd2jpmVDVDwZjrd3MzJtmpyFDEAu5R9azVveH6kBEXc5F2ETnFijQfEj5l6EzmH7EnMzbTlFHgbkDGR%2fH9CtURo0K2VSUKHN4%3d" />
  <script>
    document.addEventListener("DOMContentLoaded", function()
    {
      var b = document.getElementById("c-form");
      b && b.submit();
    });
  </script>
</form>

And we get back

POST https://xxxxx.xxxxxxx.xxx/api/payment/3dsecurechallenge?eid=ctl00_cphMain_Payment_SagePay_ThreeD 
cres=*removed for data protection*&threeDSSessionData=

Note there is nothing following &threeDSSessionData=, where it should be returning our string back to us.

The documentation says: enter image description here

Anyone else having this issue?

MadSkunk
  • 3,309
  • 2
  • 32
  • 49
Dawn
  • 51
  • 2
  • We get the same issues as well. Supposedly it's the 3DS provider dropping the data during transit making it impossible to continue the transaction. Opayo have little to no clout with the 3DS providers and months have passed with similar issues but no resolution. – haxtbh Jun 25 '21 at 17:13
  • Figured this out and it's due to the misleading documentation. Base64 and URL encoded is not what they want, it's base64url encoded which is a different encoding. This is what's required as part of the EMV 3DS 2.0 spec. https://base64.guru/standards/base64url – haxtbh Aug 06 '21 at 09:00

3 Answers3

2

Just to add some more context - we had the same issue but only with rsasecure.co.uk at the start of June. Other banks worked correctly. We have an open case with Opayo about this but there has not been a lot of communication.

We turned off 3DS while this issue is occurring but have been advised to try again today (23.07.21) as it may have been an issue at the banks side.

Kyle
  • 88
  • 5
  • More often than not, if I'm looking into a problem, rsasecure is nearly always the 3d authenticator in use – PeteAUK Jul 26 '21 at 07:33
1

threeDSSessionData seems to be URL encoded in the input tag. Have you tried this without the URL encoding? I believe it should only be base64 encoded.

Scottie
  • 99
  • 2
  • 1
    Yes we tried that. The documentation says Base64 then URLEncode it, but its part of a form so will get URLEncoded anyway so we removed that so it wan't double encoding but it didn't make any difference. – Dawn Jun 25 '21 at 13:07
0

I've now received a response from Opayo. I also think they may have changed something because I'm positive I tried this previously and it didn't work...

threeDSSessionData is the base64 encoded of VPSTxId (including the curled braces). It is not base64url encoded - talking about url encoding is a massive red herring because the browser auto submit handles this without us having to do anything.


Here's an example that worked for me.

I curl post the card details to vpsdirect-register.vsp (or whatever flavour you're using). This must include a ThreeDSNotificationURL value that contains the URL of the your callback page.

The following response was received.

Status=3DAUTH
StatusDetail=StatusDetail=2021 : Please redirect your customer to the ACSURL, passing CReq.
VPSTxId={1F3F8015-FFEB-E897-0643-58841AD5DB03}
ACSURL=https://test.sagepay.com/3ds-simulator/html_challenge
CReq=ewogICJtZXNzY...iA6ICIwNSIKfQ

I base64 encode the VPSTxId value into a threeDSSessionData value and get the customers browser to autosubmit the following form

<form action="https://test.sagepay.com/3ds-simulator/html_challenge" method="post" id="autopostform">
<input type="hidden" name="threeDSSessionData" value="ezFGM0Y4MDE1LUZGRUItRTg5Ny0wNjQzLTU4ODQxQUQ1REIwM30=">
<input type="text" name="creq" value="ewogICJtZXNzY...iA6ICIwNSIKfQ">
</form>

Customer will then do the necessary gubbins and the callback URL will have something similar to the following posted to it

cres=ewogICJtZXNzYWd...OiAiWSIKfQ
threeDSSessionData=ezFGM0Y4MDE1LUZGRUItRTg5Ny0wNjQzLTU4ODQxQUQ1REIwM30=

Both of these values are base64 encoded (the cres actually contains the acsTransID that was in the original response). We now need to base64 decode the threeDSSessionData back into a VPSTxId which we then need to curl post along with the (still encoded) cres value.

VPSTxId={1F3F8015-FFEB-E897-0643-58841AD5DB03}
CRes=ewogICJtZXNzYWd...OiAiWSIKfQ

Hopefully that'll give us a successful response and the transaction should go through.

In short it's a complete pita. In reality the encoding element should be dealt with via Opayo's API rather than us needing to code this up.


Edit: Original Reply

Yes! We flicked over to v4 with 3DSv2 last week and have had a couple of dozen customers reporting that they try to pay, and basically just returned back to the checkout. Looking at one now for barclays, but have had others too - including one where they 3dauth and don't get returned to our checkout at all...

PeteAUK
  • 968
  • 6
  • 16
  • I have escalated this up to SagePay/Opayo to investigate – PeteAUK Jun 21 '21 at 12:45
  • I have given Opayo transcripts of the calls against a customers account but its been two weeks and no reply and its takes them 30 min to answer a call. I'm not sure what to do next. Offer customers a different gateway but there are a lot of them. Anyone any suggestions. – Dawn Jul 05 '21 at 13:25
  • I've just got some comments back on some things to try. In short I think they have a bug their end, but need to work through their suggestions before I can actually prove this. The speed of their customer support is pretty awful - we put through thousands of orders a month and get this and I get the impression they just don't have enough staff. – PeteAUK Jul 07 '21 at 07:00
  • @PeteAUK Did you ever resolve this? Does the `threeDSSessionData` or `VPSTxId` actually need to be base64 encoded? Their documentation is so bad. Contradicts itself. I just cannot get a 3DS v2 transaction to go through. – BadHorsie Mar 10 '22 at 19:41
  • Apologies about the almost year long delay in replying... `VPSTxId` needs to have the curled braces removed. `threeDSSessionData` is base64_encoded but requires trailing `=` sign padding to be removed. – PeteAUK Feb 23 '23 at 12:31