Add payment method object in transaction responses

[judgej]

Implemented in API 09-06-2016 v1

The transaction response needs to be expanded for this new data.

[judgej]

There appears to be no specification for the paymentMenthod response object in the documentation, but plenty of examples are provided:

  "paymentMethod": {
        "card": {
            "cardType": "Visa",
            "lastFourDigits": "0006",
            "expiryDate": "0317"
        }
    },

This is not to be confused with the paymentMethod request object.

[judgej]

Do we need to create this object on the payment regardless of whether there is response data for the paymentMethod or not? It would help for consistency, so the application does not need to check that a payment method exists before attempting to read from it. It could default to a "null" payment method perhaps.

[judgej]

The PaymentMethod object is constructed in the Payment and Repeat message objects,

Simplified the handling of setting httpCode in a message. This is done only in the constructor or the fromData() method (these are the only two places the messages are instantiated, from a PSR-7 message or an array of data respectively).

[judgej]

To finish this off:

• [x] Decide on whether to create a PaymentMethod object always in a payment, regardless of whether payment was taken, just so $payment->getPaymentMethod()->getPaymentType() always returns a valid value.

[judgej]

Done in issue #45

There are separate request and response Card objects, now moved to Model namespaces under their respective Request or Response. The Card response class may extend an abstract payment method when the gateway extends to additional payment methods (e.g. PayPal and bank accounts) but for now is self-contained).