Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Direct integration to Protocol 4.00 #168

Open
lukeholder opened this issue Sep 21, 2021 · 19 comments
Open

Support for Direct integration to Protocol 4.00 #168

lukeholder opened this issue Sep 21, 2021 · 19 comments

Comments

@lukeholder
Copy link

lukeholder commented Sep 21, 2021

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
Copy link
Contributor

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

@thisiscap
Copy link

Wondering if there has been any movement on this?

@peteeveleigh
Copy link

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
Copy link

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

@dhavalbhavsar
Copy link

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
Copy link

Is there any update on this, please?

@AColes
Copy link

AColes commented Dec 21, 2021

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

@dhavalbhavsar
Copy link

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
Copy link
Contributor

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
Copy link

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

Thank you.

@benjam-es
Copy link
Contributor

benjam-es commented Jan 19, 2022

@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
Copy link

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
Copy link

Just checking if there is any update on this?

@barryvdh
Copy link
Member

So is this enough? #173

Can you test the ^4.0@dev branch?

@nfourtythree
Copy link
Contributor

nfourtythree commented Feb 11, 2022

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
Copy link
Contributor

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

@peteeveleigh
Copy link

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
Copy link

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
Copy link

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 🤦

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests