Support product code in old-style basket

Details on Issue #107

The filters for the old-style basket product name have been fixed to allow a wider range of allowed characters. This include square brackets [] which have a special meaning to upstream Sage products to help account reconciliation.

The extended Item has an extended interface to include productCode, which is automatically inserted into the basket line name, in square brackets, as a convenience.

The productCode is not inserted into the XML basket at this time, and it probably should be. However, Sage/Sage Pay does not support the same upstream product reconciliation at this time, so it is less helpful.

There should be no BC breaks, but the change to the extended Item interface makes it prudent to make this a minor release.

Support language parameter

The language property can be set at the gateway or message level, and is available for both Direct and Server API variants. When visiting an offsite payment form, the displayed language is the one selected (from a small selection - see the Sage Pay documentation). It should also affect the language used in any return error messages, though that has not been tested.

The language can be supplied as an alpha-2 ISO string, for example GB or FR, and is case-insensitive. It can also be supplied as a locale string for convenience, for example en-GB and fr-BE (these will result in English and French languages respectively).

See Issue #102

This has not been ported to the 2.x branch.

Support for Omnipay 3.0

Support for Omnipay 3.0

PRs #96 #97 #99 Additional feature support

All changes are non-BC break additional feature support for the Omnipay 2.x branch.

PR #99 Remove branch-alias
PR #97 Gift Aid support
PR #96 Extended Item with VAT

Note: this is not being picked up by packagist. I've not got packagist access to debug why.

Duplicate Release 2.5.0

Trying to kick-start packagist that seems to have got stuck syncing. Please see release 2.5.0 for all changes.

Various refactoring and little fixes

Summary of changes:

• Shift requirements of omnipay/common to minimum 2.4 #93
• Shift PHP minimum requirement to 5.4
• Add more constants to the abstract request defining API values.
  These are partly for reference by the application, and partly for use within
  the driver in place of naked strings defined in various places.
• Support profile parameter for iframe use at gateway level #4
• Support surchargeXml field #91
• Refactor the request data building into a collection of smaller units
  (token data, authorization data, card data, etc.)
• Added ResponseFieldsTrait to share fields between the AbstractResponse and the
  ServerNotifyResponse messages. This reduces the amount of code duplication.
• Similarly, added ServerNotifyTrait for shared mnethods between the ServerNotifyRequest
  and the AbstractResponse.
• Fix the ServerNotifyResponse so it does not refer to custom methods in its
  Request object. This was a pain to test, as the mock requests only complied to
  the strict AbstractRequest interface.
• Support saved card token creation while a card payment is being made.
  This complements the explicit card token creation methods. #90
• Added tests hopefully covering all these changes.
• Add many missing docblocks.
• General code formatting cleanup.

Add surcharge XML support

This provides access to the raw SurchargeXML field in transaction requests.

There is no validation on this data, and you must construct the XML string in your application. If a surcharge API ever gets added to Omnipay, then that could feed into this field, but for now without a standard or convention for defining and setting surcharges, we'll just expose the raw field for those that need it.

Support for card management, repeat billing and card holder name

A number of changes rolled up into one release. Adds new functionality and does not remove any old features.

• Issue #81
  Support card holder name override, allowing a name different to the billing name.
• Issue #75
  Support tokenised card billing management with createCard(), updateCard() and deleteCard().
• Issue #73
  Make sure vendor name is lower case.
• Issue #58
  Support repeat payments, based on a previous payment.

2017-09-06: Note that an upcoming release will bring the token and cardReference methods more into line with Omnipay standards. The documentation will change substantially and additional methods introduced, but it will be back-ward compatible to this release.

Fixes to XML basket

Fixes include:

• Support for multiple discounts and better support for no discounts.
• Filtering of the basket item names (for valid characters and overall length).

There is a unicode dark shadow hanging over the validation, I feel, but I think unicode is something to tackle across the board in OmniPay anyway. For the record, Sage Pay will now accept UTF-8, and will make a good attempt at converting it to its internal ISO-8859-1 characterset. This is a new thing for Sage Pay (quietly introduced 2015) so it takes some of the characterset encoding issues out of our hands.

Source: PR #53

Support XML Basket

The optional XML Basket is supported through the Omnipay\Common\Item and Omnipay\Common\ItemBag classes. Negative prices are put into the basket as fixed discount items.

The basket was not supported at all previously, so the minor version has been raised, as sites using the ItemBag generically against all its drivers will now find they are sending the basket contents to SagePay.

Note that the OmniPay Item does not support tax, so prices are assumed to be gross and tax is set to zero. The OmniPay Item also does not support a separate shipping/delivery item, so that will not be used.

Note also that the basket totals (sum of gross amounts minus sum of discounts) MUST add up to the amount sent in the transaction, otherwise the transaction will fail. The Sage Pay test API does not enforce that rule at present, but the live API does.

Issue #44
PR #50
PR #51