Create response message factory

[judgej]

Instead of handling which message to send the response into in the application, just send it into the factory and get the appropriate response message back. It would be a kind of "auto-detect" that would return a message, which could include a collection of errors.

A general "state" or "message type" property of the response will be useful to make high-level decisions.

This could also apply to ServerResponse messages, with one possible state being "nothing of relevance here".

This would make writing the wrapper code much easier. pulling more of the sequence detection logic into this package.

[judgej]

A few things we may need:

• [x] Some way to detect an error has occurred. Raising an exception feels wrong, because then it is difficult to return the formatted error collection. A flag on the response and collection messages maybe.
• [x] Split the Transaction response in separate Payment and Repeat messages, as the differ enough to warrant this. The Repeat response message is a subset of Payment as it does not involve 3D Secure.

[judgej]

The response factory detects errors, payments, repeat payments and card identifiers so far. It can be called up like this:

$client = new Client(['http_errors' => false]); // Guzzle, suppress exceptions on HTTP errors.
$psr7_response = $client->send($payment->message());
$response_object = \Academe\SagePay\Psr7\Factory\ResponseFactory::parse($psr7_response);

and that will return the appropriate ErrorCollection or Response object. This makes me wonder whether the ErrorCollection should share an interface with the Response messages for a consistent return from this factory? Edit: oh, it already is. Sorted.

[judgej]

The checks for each response message type should be moved to the message classes. This way they can be used by an external application that may want to add its own logic and not go through the factory.

[judgej]

Added support for 3D Secure Redirect Response in Issue #37.

[judgej]

The messages need a comprehensive set of attributes that allow actions to be supported, informing the application what kind of message it has received and what to do with it. Some ideas:

• [x] isError() - indicates an error condition has been returned (e.g. timeout, auth, validation). The declining of a payment is not classed as an error.
• [x] isSuccess() - indicates whether the payment or authorisations was successful. Also whether 3D Secure result was a success.
• [x] isRedirect - indicates that a redirect is needed. This may be a 3D Secure redirect, or possibly some other redirect such as to PayPal in the future.

Different flags will be relevant to different types of message. These flags can be used as a proxy to checking what the message classname is. For example, after sending a payment, isRedierct() will tell us whether the response is a 3D Secure redirect that needs a specific action. isAuthed() will check the values of the statuses without the need to know in the application what each returned status code means.

[judgej]

The factory provide the planned functionality now.