SCA and PSD2

This will only affect the Direct payment method. If you are using Server or Form this should have no implications for your site.
Details about the direct integration can be found at https://www.sagepay.co.uk/library/document/directintegrationandprotocol4...
A couple of points that may be relevant:

The current 3D Secure implementation [3DSv1] will continue to be supported until end of 2020 (at which time 3DSv2 becomes mandatory worldwide).

- This may give us more time. Needs making sure

From Monday, 1 July 2019, your developer can test the changes on the Sage Pay Test Server.

I am changing the issue Priority to Major as this can have severe consequences. I think the next step is to figure out what is the timeline if we have until the end of 2020 it is not so pressing.

Just to add to my previous comment. Looks to me that even if 3Dv1 is supported and the code still works after 19th September 2019 you will not be meeting the EU Directive.

Good to be looking at this now, thx for flagging it. I think I will switch to server option to avoid any potential issues or complications.

Just a quick note the new EU Payment Services Directive (PSD2) comes into effect on 14 September 2019 not the 19th as declared above.

You can quickly check if this is going to affect you by going to /admin/commerce/config/sagepay and checking the settings under SAGE PAY INTEGRATION OPTIONS.

if you have Server (Including InFrame) or Form (Completely outsourcing your online payments to Sage Pay) ticked then your payment is handled by Sage Pay so they will automatically apply updates as and when they are required.

If you have Direct (The full white-label payment solution) then this will probably be a problem for you as your payment will be handled within your website. If you find you have this option ticked a quicker resolution could be to change it to the server option as suggested by kevster

Thanks, @slipstreamer I have updated the issue description with the correct date.
I have also updated the priority to critical as my understanding is that anyone using the Direct payment method may not have a working payment system in less than 2 weeks.

Hi Guy and anyone else following this issue,

Here is an initial pass at implementing the V4.00 API for SagePay Dirext (rolled against the dev release). SagePay had problems with their Test environment for a while, but they seem to be up and running now and sending back the expected responses to test data. I don't know whether they have gone live with the API changes yet.

This patch adds a config setting to the admin setting page which allows the API version to be selected, although it should handle any in-flight downgrade to V3.00 which SagePay might impose (as per their documentation: https://www.sagepay.co.uk/support/38/psd2-under-direct-integration).

Regards,

- Paul

Re-rolled patch with correct paths.

@paulbeaney thanks for the patch!

I've set the protocol to version 4 but when I get to the 3D secure page and enter the password, the iframe disappears and nothing happens.

Looking in the console log I see there's a POST request that fails:
https://test.sagepay.com/mpitools/null

I'm guessing /null isn't right but I can't see where this URL is generated - I believe it's by Sagepay so I think something may be missing when the form gets submitted.

Any ideas?

It's strange, now I can't submit the payment form and get the following error in the logs:
The ClientIPAddress is missing.

I've added the client ip address to the parameters and now I'm getting:
The ThreeDSNotificationURL field is required.

Is there somewhere this should be configured?

Hi joekers,

I think I might need to re-roll the patch as I seem to recall I had to revisit the code and make some changes. I have to confess I have given up going much further with V4 of the API for now as SagePay aren't particularly in a hurry now that the official deadline (in the UK at least) has been pushed way back, and the Test environment has been very flaky for a few months.
I'll try and re-roll the patch early next week for you if that can help.

Regards,
- Paul

Thanks for the quick reply Paul - a fresh patch would be great if you get chance.

I've noticed there's less urgency now that the UK deadline has been pushed back. I have a client who accepts EU payments and they have already started seeing declined payments due to the extra authentication checks not being in place.

The Test environment being flaky could be the reason I'm seeing different errors with the POST request failing - what kind of issues were you having with it?

Hi joekers,

Sorry for the delay - we have other customisations in the module which needed weeding out before I could roll a new, clean patch against DEV. See how you get on with this one. FWIW, I haven't used this code recently so I can't guarantee that SagePay haven't changed anything since last time!

Regards,

- Paul

Thanks a lot Paul - really appreciate the new patch!

I'll give it a try and update the patch if Sagepay have made any changes.

Cheers

Hi there

I tried implementing the patch, but I'm getting the error message: Call to undefined function commerce_sagepay_protocol() in commerce_sagepay_settings_form()

Does anyone have any idea about how to fix it?

Thanks in advance
Keiron

@paulbeaney - Thank you for creating the patch. I wasn't able to apply the patch so have taken all your references and created a new patch that looks to work nicely for me from version commerce_sagepay 7.x-1.x. I hope this can help someone else as well.

It requires the administrator to set the new API version 4.0 in the SagePay Settings under DirectPayments. I think in the long term this could be removed and the API version could be removed because all payments should now be using version 4.0. Please do test it and feedback.

I do hope some of this finds its way back to the module because, without it, Sage/Opayo will prevent payments from being taken without this by 14 March 2022.

Thanks,

Matt

This patch is updated to remove condition has_js which was being temperamental and cleared up some repetitive code.

Thanks for this @mbatterton! I'm going to give this a try

Please find attached the updated patch, this is based upon version 7.x-1.x that includes all the features from the dev branch as well.
This will add the js file that may need moving to commerce_sagepay/js/. for it to work.

It requires the administrator to set the new API version 4.0 in the SagePay Settings.
Don't use select use test data when testing - this still needs a bit of work.

Key points included:
VendorTxId - must not include curly brackets for protocol 4.0.
CReq - must be presented lowercase when passed to 3d secure.

@mbatterton I'm getting some errors when trying to apply this patch to the current dev tarball:

$ patch -p1 < ../commerce_sagepay-3064258-22-3ds2_non-complance.patch 
patching file commerce_sagepay.info
Reversed (or previously applied) patch detected!  Assume -R? [n]  
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file commerce_sagepay.info.rej
patching file commerce_sagepay.module
patching file includes/commerce_sagepay.admin.inc
patching file includes/commerce_sagepay_abort.inc
patching file includes/commerce_sagepay_cancel.inc
patching file includes/commerce_sagepay_common.inc
patching file includes/commerce_sagepay_constants.inc
patching file includes/commerce_sagepay_direct.inc
patching file includes/commerce_sagepay_server.inc
patching file modules/commerce_sagepay_paypal/commerce_sagepay_paypal.info
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file modules/commerce_sagepay_paypal/commerce_sagepay_paypal.info.rej
patching file modules/commerce_sagepay_paypal/commerce_sagepay_paypal.module
patching file modules/commerce_sagepay_paypal/includes/commerce_sagepay_paypal.inc
patching file modules/sagepay_3d_secure/sagepay_3d_secure.info
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file modules/sagepay_3d_secure/sagepay_3d_secure.info.rej
patching file modules/sagepay_3d_secure/sagepay_3d_secure.module
patching file modules/sagepay_token/sagepay_token.info
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file modules/sagepay_token/sagepay_token.info.rej
patching file modules/sagepay_token/sagepay_token.module

I notice it is a git diff, is that an issue? Or am I targeting the wrong source? Or am I just showing my nonexistent patch knowhow? (Yes!)

A steer would be appreciated - thanks.

EDIT TO ADD:
As I see that the problematic files above are just the .info files, I went ahead and applied the patched dir to my test server.

Context: I am using Form, but MySagePay has been warning me that I still need to be using Protocol v4 or transactions will stop working October 15th.

On attempting an order in test mode, the checkout/payment step crashes and the dblog shows:

Error: Call to undefined function sagepay_3d_secure_window() in _commerce_sagepay_encrypted_order() (line 661 of [SNIP]/sites/all/modules/commerce_sagepay/includes/commerce_sagepay_common.inc).

Does the 3D Secure submodule need to be enabled even for Form?

Leaving aside the issue in my last comment, the conclusion I'm reaching wrt Form support is that:

1. From what I read here, Protocol v4 support doesn't mandate any additional fields (just tweaks max lengths of some existing fields).
2. All SagePay/Opayo requires from Form users (who are not using new functionality) is that our payloads start identifying as Protocol v4.

So it looks like all we need to do is bump the version number in includes/commerce_sagepay_constants.inc
define('SAGEPAY_PROTOCOL', '4.0');

Would welcome any confirmation on this. I'll pursue it with Opayo support but I'm not sure how reliable their responses will be.

@headbank - thanks for your comment. I'm also using the form integration. Did your solution work - "define('SAGEPAY_PROTOCOL', '4.0');" ? Thank you for looking at this.

@macman911 Yes that change seems to have been adequate for Form. I queried this with Opayo support and they said our transactions were now meeting requirements. (At least now I have it in writing in case they're wrong.)

Note: an Opayo newsletter sent 29 September mentions that 3DSv1 would be turned off in the Test server "in September" - not sure how verifiable it is that they have actually done so, but if so that should help in assuring self that the update has been effective.

Hope the above does not seem unduly cynical towards Opayo; just want to be clear in this forum that I am giving you their assurances, not my own. All I can say for myself is the edit didn't break it, and we are currently processing successfully.

We'll know for sure next weekend in any case ;)

EDIT TO ADD: Now we are past the watershed, can confirm that transactions with Form are still working fine with just the version-bump fix.