Return/Display Actual Reason Code messages? Customer gets no insight to reason for decline.

[cwbit]

Is there a way (within Omnipay directives) to have Message\AIMResponse give meaningful error messages based on the return codes?

The reason this is coming us is that for some reason all of their error messages (errorText) just says The transaction has been declined but there's an additional errorCode that gives a clue as to why. The challenge is that all the customer sees when code uses $response->getMessage() is the decline, not the why. For example, here is their list of most common codes and what it means

https://support.authorize.net/authkb/index?page=content&id=A50

• 2 General decline by card issuing bank or by Merchant Service Provider
• 3 Referral to card issuing bank for verbal approval
• 4 Card reported lost or stolen; pick up card if physically available
• 27 Address Verification Service (AVS) mismatch; declined by account settings
• 44 Card Code decline by payment processor
• 45 AVS and Card Code mismatch; declined by account settings
• 65 Card Code mismatch; declined by account settings
• 250 Fraud Detection Suite (FDS) blocked IP address
• 251 FDS filter triggered--filter set to decline
• 254 FDS held for review; transaction declined after manual review

My thought would be to modify and replace/extend the getMessage function such that if a known error code is returned, display a readable message, otherwise, just show the errorText (and possibly the errorCode.

Or does this just have to be custom-coded to get the reasonCode and map it locally outside of Omnipay? (which would mean we'd have to add an additional response translation layer between all omnipay gateways and our code, instead of being able to hot swap em).
Not sure what the design directives would state here.

[judgej]

The getMessage() method should return the message supplied by the gateway. However, those messages are for logging and are generally not suitable for putting in front of a user. This is partly because some messages can be technical and confusing, and partly for security because you don't want to give away too many details of issues happening in the back end.

There is scope, I believe, in being able to map the internal error codes to more useful user-oriented error messages though. Maybe this can start off as a separate project to see how it can work, then evaluate how it could work in a generic way from there. For example, we may identify a dozen common messages that apply to all gateways, and could map them to "standard" core Omnipay result codes. Gateway drivers could supply mapping data as metadata. All of this would ideally be translatable too (remembering that some gateways will deliver all their messages in different languages anyway, depending on what language has been set in the API request).

So experiment and see what you come up with :-)

[eileenmcnaughton]

I think there was a discussion elsewhere (although I can't find it now) about offering an additional method getUserMessage which would return user-appropriate messages (where one was derivable).