PSD2/3DSecure2/Sagepay v4 support

[jontjs]

Sagepay are beginning to publish information on the PSD2/3DSecure2 aspects of their V4 VPSProtocol: https://www.sagepay.co.uk/support/38/psd2-under-direct-integration .

At the time of writing they haven't linked to a new version of the full integration document at https://www.sagepay.co.uk/support/find-an-integration-document/direct-integration-documents, perhaps because v4 doesn't hit their Test environment until July 1st 2019, and their Live environment until "later in July") , but the docs are available at https://www.sagepay.co.uk/library/document/directintegrationandprotocol4guidelinespdf .

[judgej]

Thank you for the heads' up. We'll jump on this (feel free to help in any way). I'll also follow up the "Sagepay Pi" v1 protocol https://test.sagepay.com/documentation/#3-d-secure API too, with an Omnipay implementation here https://packagist.org/packages/academe/sagepay

[judgej]

Scanning the docs, the V4 protocol has quite a few changes. The docs are in the usual long-hand form that makes it difficult to find what the changes are without going through every line manually, but I guess that needs to be done. A checklist of individual changes can be put together to work through.

There is a calendar of deadlines. 3DS is mandatory from September 2019. V1 will be supported until teh end of 2020, so having the ability to request V1 only would be good if useful to help client sites move over.

[tylunari]

I've been reading into this too, they mention having v1 as a fallback in case v2 fails for any reason but I'm not sure if that fallback will still exist after 2020.
Also from what I've briefly looked at, on page 82/90 from their guidelines they mention that CReq will replace PAReq

[judgej]

I don't believe the fallback will exist after 2020 (I could be wrong though).

The fallback in the meantime is for banks that don't support v2, so I expect there will be a lot of fallbacks to v1 happening at the start, and they will reduce to zero later as more banks release their v2 support. After 2020 ALL banks must support it, so there is no reason for a fallback.

[judgej]

I will need to look at this in the next few weeks, but if anyone has any input or branches or code, please post here so we can coordinate effort.

[jontjs]

I've had a slightly-deeper look at the V4 protocol docs and, on the face of it, the changes are in one sense fairly small, but in another sense rather tricky...

New fields we need to send at various steps of the 3DS process:

• BrowserJavascriptEnabled
• if BrowserJavascriptEnabled, also:
  • BrowserJavaEnabled
  • BrowserColorDepth
  • BrowserScreenHeight
  • BrowserScreenWidth
  • BrowserTZ (timezone)
• BrowserAcceptHeader (HTTP accept headers as browser sent us)
• BrowserLanguage
• BrowserUserAgent
• ThreeDSNotificationURL - this sounds a lot like the TermUrl we currently send...
• ChallengeWindowSize - 1 to 5, corresponding to "250x400", "390x400", "500x600", "600x400", & "Full screen"
• CReq - "This replaces the PAReq", which we currently send
• CRes - the bank sends this as "cres", we pass it on to Sagepay as "CRes" (note the case difference)
• VPSTxId - replaces "MD" which we are currently sent and then pass on

I mean "fairly small" in the sense that most are just additional scalar fields. But "rather tricky" in that I'm not sure how a server-side PHP library can be expected to know whether JS is enabled (or the others that depend on it).

[judgej]

I would think the server would have two entry points for payments, one using JS and one that does not require JS. The browser can redirect the user to whichever endpoint is appropriate to start the payment process.

Great list - very helpful!

[lukrak]

Is there an estimated date when this enhancement will be developed and available ?

[judgej]

No estimated time yet.

Talking to someone who has checked with Sage Pay, they say if you are using Sage Pay Server, there should be no changes needed. Sage Pay Direct there will be, though that one is much less commonly used.

I fully expect Sage Pay Form to be in the same field - because all processing happens off-site, the 3DS handling is all done offsite too.

However, this all needs testing.

[pbh-stu]

I have just spoken to SagePay who gave me this link which relates to direct integration (which i currently use) https://www.sagepay.co.uk/support/38/psd2-under-direct-integration

However I am planning to switch to server (iframe) based integration to reduce our PCI compliance burden. From what i've read above server integration means sagepay hosted pages and no changes required my end (i hope).

Thanks

[judgej]

Thanks @pbh-stu If you do find any changes needed for Sage Pay Server, but sure to let us know. From my own research, Sage Pay have not updated documents or SDKs in years, so it's all a bit of a mystery what they expect people to do.

[pbh-stu]

@judgej

I've just installed a laravel project and tested with

"laravel/framework": "4.2.*",
"league/omnipay": "3.0.2",
"omnipay/sagepay": "3.0"

I can confirm that omnipay sagepay/server does not support sagepay protocol version 4 (required for 3DS 2.0 ) as it's hard coded for version 3 in the omnipay/Message/AbstractRequest.php file and even if that was not the case, version 4.0 requires 5 or so extra fields to be sent and an extra callback handler but nothing too major!

So my hope of server/iframe method just working was a naive dream! I wonder if one of the forks have addressed it yet.