Fix protocol 4.00 VPSSignature check

[Ferrisbane]

Hi,

A bit of an urgent request as Elavon/Opayo are forcing their URL updates in a few days on the 31st of March.

Upgrading this omnipay sagepay package from version 3 to version 4 has resulted in errors on both sandbox and production environments. Which results is unable to take payments at all.

Only version 4 of this package has the new URLs which will break version 3 of this package once Opayo disables the old SagePay URLs.
Expect a lot of people on version 3 with broken installs!

I've found and fixed the protocol 4.00 errors in this merge request.

The issue I was having was, after creating a new transaction and being redirected to Opayo hosted forms, completing the payment Opayo will send data back to us. The data is verified in the package via the VPSSignature. However the current package does not check for the new protocol version 4.00 fields and is always returning an InvalidResponseException.

The cause is Opayo protocol version 4.00 has added new fields to check in the VPSSignature when using the Server Gateway.
(I'm unsure if other integrations such as their Form Integration is affected).

The Opayo documentation is here:
https://developer.elavon.com/products/opayo-server/v1/notification-of-transaction-result
Their docs might error, they require you to https://developer.elavon.com select your country and then click the link.

Please can you check this urgently and merge in before 31st of March otherwise many integrations will break.

[judgej]

Thank you for this, including the test. I'll try to get it in tonight - I have a few hours now.

So I understand, this change adds additional fields sent by Opayo in the notification POST to the signature check. There is nothing additional that the application needs to do, for this change to work as a drop-in replacement? So nothing is needed in the documention?

[judgej]

Okay, digging back through distant memories, I realised this class you are changing has been deprecated for some time. That doesn't mean people are not using it, so this fix is still fine to go.

To receive the notification from Opayo, use this on the server gateway object:

$notifyRequest = $gateway->acceptNotification();

This will give you an instance of \Omnipay\SagePay\Message\ServerNotifyRequest.

Using that object - after giving it the original security key, looked up in your database from the transactionId that Opayo sends:

$transactionId = $notifyRequest->getTransactionId();
// Look up the `securityKey` in your open transaction list, then:
$notifyRequest->setSecurityKey($securityKey);

Now you can check if the signature is valid:

$notifyRequest->isValid(); // boolean

And you can response to Opayo:

$notifyRequest->invalid($nextUrl, 'Signature not valid - goodbye');
$notifyRequest->error($nextUrl, 'This transaction does not exist on the system');
$notifyRequest->confirm($nextUrl);

There are more details about capturing the data sent in the README, along with notes on what to do if yout get the same notification more than once (and you will). There is also an option to switch off the exit that the response does, in case that interferes with you framework by not allowing it to shut down cleanly.

This has had the V4 elements on for about five years, so has been working for some time. But people still using the older classes that work up to V3 will appreciate your fix.

[dathwa]

Hi All.
TL;DR: deadline extended to 31 May 2024

Our client got an email a few days ago. See below. Unfortnuately, no links in the email pointing to a page anywhere on Elavon web-site confirming this.
Anyone else aware of this?

Hi there,
  
We’ve been in touch a few times, to tell you we’re changing the URLs you use for your transactions and reporting. This is part of last year’s brand changes, with the Opayo gateway becoming a payment product under the Elavon brand.

We’d planned to stop supporting these old URLs from 31 March. Some customers have yet to take action though, so we’re going to extend this deadline to 31 May 2024. This is to make sure all customers have switched to the new URLs - and that we can continue to support them. 

We'll contact our customers directly to let them know about this extension. We've already advised them to contact you if they're using your technology or shopping cart and need to discuss these updates.

[Ferrisbane]

Thank you so much @judgej. I appreciate the quick merge.

Moved to production and payments are being taken fine now.
I had no clue that its using old classes. I'll have to look into upgrading to the new methods.

@dathwa thank you for that update. None of our clients have had that email (or told us).
I did speak to Opayo support yesterday as a client's sandbox was erroring and not allowing test orders in. They did not mention on that call the extended deadline.
We are listed as technical contacts on their sagepay account, however the support rep told me that we need to be a primary contact to get these emails. Surely they should be sending these emails out to technical contacts so people are in the loop.