Update deprecated notification handler for V4 protocol

PR #198 - see notes on that PR for more details on how to use the non-deprecated request and response.

This fixes the signature check for classes that handle the server notification validation and response that have been deprecated sine protocol V4 was released. These classes were never updated for protocol V4, and it seems have been used against protocol V3 for some time with no problems.

The new Opayo URLs are only in the protocol V4 release of this package, and people upgrading and still using the deprecated classes were finding it was breaking the notification. This fix will allow those deprecated classes to continue to be used as a quick workaround. I do recommend changing the way the notifications are received and responde to, however, in line with the README.

Many thanks to @Ferrisbane for this fix, and many apologies for not recognising what was happening for people reporting the 5006 error, since is was working for me and I could not reproduce the error - ducks.

Remove symfony/http-client dependency

Marked as stable release after production deployments under PHP 7.4 and 8.1, and additional tests. This should not impose any additional dependencies, and will work with no changes to configuration. For Sagepay Server, your users will be redirected to a new https://live.opayo.eu.elavon.com/gateway/service/ URL, but the experience will be identical, even down to the Sagepay logos ;-)

Have fun.

Use new Elavon/Opayo URLs

See issue #194
See PRs #193 #195 #196

Please use release 4.1.1 - this has some accidental dependencies linked to PHP 8.1 that are not compatible with PHP 7.4

Issue #177 fix deprecation notice

Issue #177 fix deprecation notice. Otherwise, no change to behaviour.

v4.0.0

Update composer.json

Fix for issue #139

Issue #139 identifies two fields that are not sent in the Sage Pay Form reqquest:

• SendEMail
• VendorEMail

This patch fixes that.

Note the letter case of these fields supplied to the driver are consistent with the general format used across Omnipay, lower camel case with "Email" treated as a single word. Sage Pay tends to use a mix of both upper-case and lower-case across different parts of the API. Use these fields, as described in the documentation:

• sendEmail (integer value)
• vendorEmail (email address)

Fix for issue #124

This allows isSuccessful() to be used in the notification handler (acceptNotification). That is the last contact point from the gateway to the merchant site with the result of the transaction, before the user to returned to the merchant site (using Sage Pay Server), and so this is where isSuccessful() needs to be available.

No BC breaks - an existing method is moved up a level to a trait so it is accessible in a wider number of message classes.

Fix for Issue #120

Fix for Issue #120

The transactionId will now be correctly returned after completing a Sage Pay Form authorization or purchase.

Includes some documentation clarifications.

#119 Improvements to test coverage

#118 PHP version requirement clarification

3.2.0: Merge pull request #117 from academe/issue112

• #112 Support Sage Pay Form
• #114 Delivery address is mandatory

This is the first release that supports Sage Pay Form. This differs from Sage Pay Direct and Sage Pay Server in that no back-channel is set up. Communications happen entirely at the front end, with data in both directions being encrypted. Requires OpenSSL to work.

Sage Pay requires both a billing and a shipping address every time. The new option introduced here allows the shipping address reflect the billing address, and brings this driver a little closer to other gateway drivers, that seldom MUST have both billing and shipping addresses to be set individually.

There should be no BC breaks in this release. It is a minor release due to new functionality.

Token creation fixes; capture mode flag; old-style basket fixes

In summary, there should be no BC breaks in the majority of cases, but a lot of code has been touched in this release, so test before putting into production. I'll aim to fix any problems as quickly as I can. There are a number of further releases to come, attempting to pull in additions that I see forks repeatedly implementing over the years, but not making it to a PR.

---

Issue #107 Old style basket text filter

• Extended Omnipay\SagePay\Extend\Item to support productCode parameter for integrating with Sage 50 Accounts. This does not yet integrate into the XML basket, which is something that should probably be done.
• Set separate character filter for old style basket item names, compared to XML basket item names. Some characters valid in the old style basket needed to be allowed through to support Sage 50 Accounts integration.

Issue #105 Token creation not consistent

• Token creation did not work at all for the Server gateway. Now fixed.
• Both Server and Direct support the createCard() gateway method to just capture a card token or card reference. The cardReference is available in the acceptNotify handler for the Server method.
• The cardToken or cardReference can be used for authorize() or purchase() for both Server and Direct. The Direct method may still redirect the user for 3D Secure authentication. The Server method will still redirect the user to enter their CVV.
• When using a saved token by applying it to a purchase as a cardToken, it will be discarded by the gateway after use. By applying it as a cardReference the gateway will be asked to keep the token retained for future use.

Issue #104 Introduce authorize and capture modes

• Sage Pay has two main ways of authorising a payment to be captured at a later time: DEFERRED/RELEASE and AUTHORIZE/AUTHENTICATE. There are distinct differences between the two, which the Sage Pay documentation explains best. The default mode is DEFERRED/RELEASE (leaves a shadow on the account for up to around 6 days, and can be released up to 30 days, but with no guarantee once the shadow expires).
• You can switch both authorize() and capture() to the AUTHORIZE/AUTHENTICATE mode by setting useAuthenticate to true.
• You can set useAuthenticate at the gateway or message level, so a merchant site can use one method globally, or mix and match depending on needs. The mode used to capture() must match the mode used to authorize() however.
• This does not introduce any BC breaks if you do not use the useAuthenticate parameter.
• To support this, the number of statuses returned by the gateway that are considered successful, have been extended. These include REGISTERED, AUTHORISED, and a few others.

Other changes:

• The transactionReference() will now be null if there are no transaction details supplied in the response (or server request) from the gateway. Previously it would contain a partially formatted JSON string. null is consistent with core Omnipay, but may be a BC break if a site is always expecting a string.
• The messages that require a reference to an existing transaction, have been extended to support both a single JSON reference or the individual parts. Which you use will depend on how your applications stores the transaction registration (most will use the transactionReference JSON string). This should not exhibit any BC breakages.
• Some message parameters have been promoted to the gateway level. These are parameters that generally affect the operation of the gateway (e.g. authorize/capture modes) which makes it easier to set as a global parameter when Omnipay is being integrated into a framework in a generic way.
• A general tidy-up and refactoring of the code has been done, with an extended test coverage. All constants have been moved to one interface, so they are available everywhere.
• The transactionType for repeat payments will default to "C" if not overridden. Previously the default was the same as for authorize() and purchase() - "E".