omnipay-sagepay
omnipay-sagepay copied to clipboard
thephpleague
PSD2/3DSecure2/Sagepay v4 support
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 .
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
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.
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
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.
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.
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).
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!
Is there an estimated date when this enhancement will be developed and available ?
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.
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
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.
@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.
Just top update, the published Sage Pay specs are still from 2014/2015. That's pretty appalling TBH, considering how close to the go-live date for 3DSv2 we are. I'm guessing there is nothing that can be done at this stage.
@pbh-stu could you point me at the Sage Pay docs that detail the V4 protocol for Sage Pay Server? All I can find are ancient docs.
Here you go:
https://www.sagepay.co.uk/support/38/psd2-under-direct-integration https://www.sagepay.co.uk/library/document/directintegrationandprotocol4guidelinespdf
Ahh sorry that's direct (but gives you an idea) ! I will ring SagePay this morning and get the links for server. I'm actually working to hack the omnipay sagepay (Server) code to work with V4 today, if i get it to work i'll post the minimum required changs to make it work.
Thanks Stuart
A few people have said that Server is not affected after ringing Sage Pay themselves. Obviously confirm for yourself, but that's what I'm working to at the moment.
Thanks for the Direct doc (which still seems to be in draft - what are they playing at?) If I understand correctly, it is only table A1 that has changed?
Sagepay and their docs are just not good at all. I'm currently using Sagepay Direct via dwmsw/sagepay but depending what has to be changed I'm thinking of switching to omnipay.
https://www.sagepay.co.uk/support/16/3d-secure-v2-what-do-customers-need-to-do says:
Server integration – There will be no mandatory changes to your current integration. We will undertake some proactive steps in the coming weeks to ensure you are ready.
I've seen very little in the way of "proactive steps" from Sagepay, on any matter, for a very long time!
I've just been on the phone to SagePay, they said they had planned to roll out an update for forms, server and direct (test env) this morning but had to abort, they plan to try again Friday 16th Aug 2019 at 7am
I've been playing with Server v4 this evening , i can complete orders fine with no changes (other than protocol version number) but it only ever shows 3DSv1 not v2. SagePay said this should be sorted tomorrow. I'll be calling them back tomorrow if not.
Hope that helps Stuart
Having just tested server integration it's clear that sagepay have updated their systems overnight.
If you enter CHALLENGE in the cardholder name (not in code but above where you enter card number) when placing a test order (with 3ds enabled) you will now see a nice error message !
I just rang Sagepay and a very grumpy Charlotte insisted this was normal and we do not have to test 3DSV2 (server) and they will take care of it. I said this was lame as I need to prove our systems work as well as show stakeholders and sales staff the process for training.
Things to note:
You must at present enter STATUS201DS as the cardholder name (above the card number) to get a 3DS V1 challenge else it will just complete with no challenge.
The protocol version does NOT need to be changed to 4.0
I suspect sagepay are cutting corners with SERVER as they are not going to receive the additional fields such as when the customer registered (which is in the spec). I suspect this means more customers will be challenged than with a DIRECT integration where all additional fields are passed along to sagepay.
Hope that helps others struggling with this.
Bollom line, no changes required for 3DSv2 support with SERVER but i suspect that will change once more people realise that sagepay have cut corners.
Not all heroes wear capes :-) Thank you for doing this thorough research and writing it up. It will be a bit help. And - Charlotte - cheer up, it's Friday!
Still nothing from Sage Pay but promises. Documentation is dated back to 2015 for direct, 2017 for Pi, and yet there are warnings that we will need to change the integrations, and that all has to be live and working next month. An utter shambles. Never known anything like it.
Looks like we've got some buffer time - https://www.fca.org.uk/news/press-releases/fca-agrees-plan-phased-implementation-strong-customer-authentication
SagePay how now fixed the 3DS v2 system on test (SERVER)
If you enter CHALLENGE as the card holder name in the IFRAME you'll see the below challenge, enter STATUS201DS to see the old 3DS V1 challenge.
3DSv2 Lives !
This whole thing has still left me a bit confused (hopefully I'm not the only one!). I'm currently using the direct integration (without iframe) - is anything/much changing with that or is that a better/easier option?
@BigManatee Yes it is confusing, because Sage Pay always fail to speak with a unified voice. This means you have to pick up snatches of detail from here and there, and make assumptions about how some things work just by trial and error.
--- end rant ---
Sage Pay Direct involves your site handling the card details forms and sending the users off to the 3DS bank, so this will very much affect you. You will also need to be fully PCI acreditted, which I'm sure you are, but is worth mentioning. The PCI accreditation is the main reason I would recommend Sage Pay Direct to anyone but teh very largest of organisations.
Sage Pay Server hands all the form filling and processing for you offsite. That's what I would recommend, and - for now at least - won't need any immediate changes.
@judgej Thanks for the recommendation, I'll definitely take that into consideration and more than likely switch to this repo and SagePay Server.
My understanding right now is from the 14th of September companies will stop taking non 3DS payments and then will stop taking 3Dsv1 (I don't take any non 3ds payments) at the end of 2020 so I shouldn't have to do anything straight away. Sagepay are always a dream to deal with.
Yes, I believe that is correct. Sage Pay are great on the phone - responsive, informative, helpful. I just don't know why we have to keep calling them. Nothing I have ever asked them on the phone is anything that could not have been publicly documented, so I end up blogging and writing up repo issues with the details I gather in the hope it will be useful to others.
Sorry. O did say rant over ;-)
I have a feeling some cards are starting to fail because the direct integration isn't updated yet. In particular Monzo cards keep failing for us.
Anybody have any idea what is going on with SagePay or rather Opayo? Nothing seems to be updated on their website for direct integration docs, but says that all integrations are PSD2 ready.
https://www.opayo.co.uk/developers
@mattybaer how is this manifesting, can you see anything in MSP I.E red 3D Secure icons ect. I have a monzo card and we use direct so i'll do a test on my systems. If cards are starting to be dropped this is a problem as my checkout does not have any kind of 3d secure enabled at present. We have a new checkout experience ready to go live but don't want to force customers to use 3ds yet as we will lose sales.
Edit: I can confirm my test £12:84 monno payment did go through on direct with no 3DS Enabled in MSP