Split error messages into code and message

[judgej]

The Response::getMessage() method returns the raw error message at present. Most of the time this message is going to be useless (or dangerous) to put in front of an end user, so some type of translation is needed.

Luckily most messages come prepended with a code, for example:

"3110 : The BillingFirstnames value is Too long."

Putting aside the off capitalisation, the message references internal field names. I've had users utterly stumped when these messages appear. So, we can take the "3110" prefix and translate that into something more useful. To do it properly, a site will need to translate in the order of 30-40 of these messages that will commonly appear if any validation that SagePay performs differs from the validation performed on the site. It is not as easy as you think to keep them in sync - SagePay is strictly ISO8859-1 so a user entering UTF-8 characters could get through a ml_string() length check on your front end and back end, and still be too many bytes long when it reaches SagePay.

Anyway, to help with this, it makes sense to split the message in this driver, so the above would give us:

getMessage() == "The BillingFirstnames value is Too long."
getMessageCode() == "3110"

Perhaps to help people migrate, we could include:

getMessageRaw == "3110 : The BillingFirstnames value is Too long."

I'll create a PR at some point for this, but just logging it as I've encountered this omision (many other drivers have a getMessageCode() method) and to hear what people think.

[judgej]

Not sure whether this error number should be getCode() or getReasonCode() - I think this whole area of codes, messages, statuses, reasons, needs to be cleared up, because I can see them all being interpreted in different ways by different gateways. I think this is due to the documentation not locking down the meaning of these phrases early enough.

[judgej]

This is kind of a wider issue. We have:

• Error codes for the application to action on.
• Error messages for logging only (never for the end user).
• Error messages that may be presented to the end user unchanged.
• Error messages translated from the codes, possibly with substitution parameters, that could be common across multiple gateway drivers. These would mainly be validation issues, card rejection reasons etc.

There are also gateways that can return multiple messages, for example if multiple address fields are invalid in a single transaction submission. Message bags of errors are going to increasingly be a thing.

[judgej]

I'm going to close this, as I think its time has passed, and there is little interested in it.