Small fix on some failure error messages

The Seamless complete and notification messages returned the wrong message in the event of a failed authorization. They all returned "invalid or missing transactionId" when that was not the issue, hiding the real error message supplied by the gateway.

Just a simple boolean check flipped to fix this, with not functional changes otherwise.

`completePurchase()` additional security features

See Issue #12 for further details.

Summary of the changes, possibly breaking to some merchant sites:

• The completePurchase() and completeAuthorize() methods now require the original transactionId to be set. If the transaction being returned with the user does not have a transactionId matching the transactionId expected, then isSuccessful() will return false regardless of status of the transaction behind it.
• The completePurchase() method returns a Request message. To inspect the transaction result details, you must send() this request to get a Response message. Previously the Request and Response were shared and all transaction results could be inspected in both. The README documentation has been updated to show how this works.

In summary completePurchase() now works like this:

$completeRequest = $gateway->completePurhcase([
    'secret' -> $signingSecret,
    'transactionId' = $originalTransactionId,
]);

$completeResponse = $completeRequest->send();

$success = $completeResponse->isSuccessful();

If your merchant site does not include [at least] the 'transactionId' or does not send() the request to get a response, then it must do from version 3.1.0 onwards.

First 3.x release

Release for Omnipay 3.x

Documentation update and minor code formatting

2.2.1

README put through spell checker.

Custom fields and repeat payments

Issue #5 Support custom fields (pass in as an array).

Issue #7 Support repeat authorisation/payments.

This release has some major refactoring, more extensive tests, and should now cover all the functionality of this gateway. I would like to see it tried in a production environment before tagging this release as non-draft.

Fix to successful payment status when PENDING

The driver was returning that a transaction was successful when it was PENDING. Although it has not failed, the transaction has also not yet completed. The isSuccessful() method should only return true when the transaction is successfully completed.

A PENDING transaction is one that will get a final status sent through later, so the merchant site needs to be ready to receive it as a back-end notification.

Released on a point release as it could have a knock-on effect on existing logic. It is tracked under issue #9

Raising version number for Omnipay core consistency

Big jump in the version number to match the Omnipay Core version (2.x) that this package is built for. No functional changes, just a change to make version inspection a little more intuitive.

Support both 639-1 and RFC 5646 language codes

There is also some Checkout Seamless stuff in this release. Have a play with it, or ignore it; Checkout Seamless is not complete yet.

More parameters at the gateway level.

More gateway-specific parameters can now be set at the gateway and message levels. They do need to be documented though.

To avoid duplications of code. traits have been used to do this. This means a minimum PHP version of 5.4, which also has allowed the short-cut array [] notation to be used. With 5.3 being several years unsupported, this is more than reasonable.

Gateway-specific URL settings available at gateway level

Other gateway-specific options may be copied to the gateway level as testing progresses.

These settings that are shared between the gateway and messages should probably be implemented as a trait to avoid duplicate code and organise the classes a little better. We'll try that on a future release.