Support for Direct integration to Protocol 4.00

[lukeholder]

trafficstars

We have received an email from SagePay saying we should:

Upgrade your direct integration to Protocol 4.00

Does the latest version of this package support this?

Thanks.

[benjam-es]

Not at the moment. There are multiple discussions/pull requests being reviewed as I understand it

[thisiscap]

Wondering if there has been any movement on this?

[peteeveleigh]

Also wondering if there is movement. It's getting rather critical. I believe there are pending PRs that address the issue but they've been sitting for quite some time.

[terryupton]

I am also wondered/waiting on this too as have several clients using SagePay gateway. Any update at all? Thanks.

[dhavalbhavsar]

Hello @judgej , Is there any chance to get latest version for these package? Because our clients getting mail to upgrade Protocol 3.00 to Protocol 4.00. Or you have any work around ?

[andrewhawkes]

Is there any update on this, please?

[AColes]

Any new on when/if this will be available ? Opayo are chasing our clients to move up to Protocol 4.00

[dhavalbhavsar]

Any new on when/if this will be available ? Opayo are chasing our clients to move up to Protocol 4.00

I think we need to redevelop with Sagepay using pi API.

[benjam-es]

Take a look through #165 pull request.

I use Payment Integration method, and made it work protocol 4.00.

It is just quickly hacked together, but you may find what you need in there if you are creating your own branch.

I currently have a private satis for pulling in my own packages, and have put this branch up there to override the omnipay version.

[terryupton]

Hi @benjam-es is there any more update on this at all? The deadline is drawing closer (March 22nd 2020)

Thank you.

[benjam-es]

@terryupton we await feedback from the package maintainers @judgej and @barryvdh

Until then, feel free to play around with my branch #165, with something like the following in your development environment. I'm happy to modify, update, fix where others may find it useful until an official fix/pull request is merged.

{
    "repositories": [
        {
            "url": "https://github.com/benjam-es/omnipay-sagepay.git",
            "type": "git"
        }
    ],
    "require": {
        "omnipay/sagepay": "dev-feature/pi-protocol-4"
    }
}

It's probably a poor attempt at things, as I ended up combining my sagepay-pi branch with a protocol 4 branch, both of which were just quickly spiked together.

[eyekiller-hub]

Any update on this as we too have Craft Commerce websites using Opayo and they are putting pressure on us to update ahead of March 2022.

[eyekiller-hub]

Just checking if there is any update on this?

[barryvdh]

So is this enough? https://github.com/thephpleague/omnipay-sagepay/pull/173

Can you test the ^4.0@dev branch?

[nfourtythree]

For those people following this issue from a Craft CMS/Commerce perspective here is how you can test the changes.

In your project's composer.json, update/add the following lines

{
	...
	"require": {
		...
		"craftcms/commerce-sagepay": "dev-feature/protocol-4-compatibility as 4.0"
	},
 	"minimum-stability" : "dev",
	"prefer-stable": true
}

Due to the changes, you will also need to make sure you are on PHP 7.3 or later. This may also mean you need to change the platform PHP requirement in your composer.json as well.

Once you have done that you should be able to composer update and have the latest code changes.

Obviously, this will be temporary while we have people testing and proper update instructions will be added when all relevant packages are released.

[benjam-es]

@lukeholder @barryvdh believe this is now addressed by the recent merged pull request?

[peteeveleigh]

I've just installed this new update and I'm not convinced things are quite right. I tried various test card numbers to simulate different 3DS conditions and they ALL passed and allowed the payment - which surprised me. Then I found this SE post about testing 3DS2 workflow on SagePay/Opayo https://stackoverflow.com/questions/65329436/sagepay-3d-secure-v2-flow

That seems to indicate using different "passwords" on the SagePay/Opayo checkout screen to simulate different conditions. Indeed, I tried "CHALLENGE" and was returned to my site with an error about 3DS2 being required - which kind of seems right. However the basket was emptied.

I'm doing some more testing and will report back.

[crs-stephen]

The process for testing involves the following:

1. Ensure you are passing cardholder name & clientIP with your payment
2. Using test cards you can use CHALLENGE - to enforce a 3DSV2 sca challenge OR NOTENROLLED to default to the fallback 3DSV1 integration
3. If you are using a custom redirect - you will have to change this to include the new VPSTxId and ThreeDSecureSessionData values (with a fallback to use MD and PaReq)
4. Ensure both 3DSV2 and fallback methods work - everything else within the workflow should be standard.

I don't think any of this is documented within omnipay-sagepay for now so its been a process of trial and error for me to get to this point.

[peteeveleigh]

I was just about to update my comment.

Looks like my cart isn't being emptied but the reference to it is lost when the customer lands back on the site. I don't think it's the gateway plugin's problem.

Also, I apologise, I thought this was the CraftCMS payment gateway issues thread 🤦