Communication of errors to end users

Technical error codes or other details of why a request could not be completed, must not be disclosed to an end user directly, as this might increase the risk of fraudulent activity.

Especially when it comes to credit card fraud, fraudsters often target websites that give a different response to different types of declination (e.g., where one response is returned for the amount exceeding the available credit and another where a card is flagged as stolen).

Thus in the interest of data protection and to prevent malicious activity, we recommend having a single response towards the end user for all types of declined transactions:

Currently your request cannot be processed, error code xxx. Please retry using a different payment option and if the issue persists contact our support team by email ({0}) or by phone ({1})

Doing so increases the difficulty of malicious activity especially the probing of automatically generated card numbers.

From the end user's perspective this means that after the first payment failure, they should be prompted to retry having validated their entered payment option details. They should also be advised that if the payment option continues to fail, that they should contact their bank (or other financial institution) to ascertain the exact reason(s) of declination or to try an alternative payment option.

In the cases when a service request needs to be submitted, please include the following technical identifiers:

• the 4-digit numeric responseCode (error)
• "requestId" (returned in the api response)
• "partnerReference" (request & response)
• "uniqueReference" (if such is applicable)
• the timestamp of when the error occurred
• the user's account number (if applicable)