Testing payment declines and AVS

When a transaction attempt is declined by the issuing bank, the Helcim API will return a response 0 with HTTP status 500 and an error message indicating the reason for the decline.

We suggest a general catch all function for the majority of potential decline reasons, with a recommendation to the user of trying a different card or payment method. Many transaction declines can only reasonably be resolved by the end user connecting with their issuing bank for more information.

Showing more granular decline reasoning is only recommended where a change in user behaviour may result in a different transaction outcome if attempted a second time, such as invalid CVV.

Testing payment declines

Card transaction declines can be simulated in a test environment through the Payment API endpoints if enabled for full card numbers. This is done by sending a CVV2 value of 200 or higher. The table below shows some of the decline codes that you can generate.

🚧
If not enabled for full card numbers, the Helcim Payment API endpoints require a cardToken be passed in the body params, which does not require a CVV number to be passed with it. In this instance transaction declines should be tested through HelcimPay.js.

CVV Input	Response	Error Message
200	0	"Transaction Declined: DECLINE CVV2 - Do not honor due to CVV2 mismatch\failure"
201	0	"Transaction Declined: PICK UP CARD - Pick up card"
202	0	"Transaction Declined: AMOUNT ERROR - Tran Amount Error"
203	0	"Transaction Declined: AMT OVER SVC LMT - Amount is more than established service limit"
204	0	"Transaction Declined: APPL TYPE ERROR - Call support for help with this error"
205	0	"Transaction Declined: CANNOT CONVERT - Check is ok, but cannot convert. Do Not Honor"
206	0	"Transaction Declined: DECLINED T4 - Do Not Honor. Failed negative check, unpaid items"
207	0	"Transaction Declined: DECLINED-HELP 9999 - System Error"
208	0	"Transaction Declined: DUP CHECK NBR - Duplicate Check Number"
209	0	"Transaction Declined: DECLINED - Do Not Honor"
210	0	"Transaction Declined: EXPIRED CARD - Expired Card"
212	0	"Transaction Declined: INVALID CARD - Invalid Card"
213	0	"Transaction Declined: INVALID CAVV - Invalid Cardholder Authentication Verification Value"
214	0	"Transaction Declined: INVALID TERM ID - Invalid Terminal ID"
222	0	"Transaction Declined: NETWORK ERROR - General System Error"
223	0	"Transaction Declined: PLEASE RETRY - Please Retry/Reenter Transaction"
225	0	"Transaction Declined: REQ. EXCEEDS BAL. - Req. exceeds balance"
227	0	"Transaction Declined: SERV NOT ALLOWED - Invalid request"
229	0	"Transaction Declined: CALL AUTH. CENTER - Refer to Issuer"

Testing payment declines in HelcimPay.js

When testing in HelcimPay the checkout session will also return a decline error message rendered within HelcimPay, and returned in the responseMessage, based on the CVV passed in the payment modal.

Example decline notification within HelcimPay.js

Testing Address Verification Service (AVS) responses

Card networks provide an address verification service (AVS) as part of card authorizations. The service checks if the address of a credit card is the same as the address and postal / zip code entered into the Helcim API.

The AVS response will not impact the approval or decline of a transaction, but can help as an indicator on whether you should proceed with the transaction or complete additional verifications with your customer before proceeding.

Although the street address can sometimes be tricky to match, the postal/zip code is usually a more accurate indicator. AVS is mostly supported by banks throughout Canada, the United States, and the United Kingdom. Most card issuers outside of those countries do not participate in the address verification service.

You can test various responses by sending a specific CVV.

CVV Input	Response	Message	AVS Response	CVV Response	Description
100	1	APPROVAL	X	M
101	1	APPROVAL	X	P
102	1	APPROVAL	X	S	Service not supported by issuer
103	1	APPROVAL	X	U
104	1	APPROVAL	X	N