Testing In-Person Transactions
Learn how to simulate and handle different payment and decline scenarios to ensure your integration manages payments smoothly.
Helcim knows that not every payment goes through on the first try, so we make it easy to test how your software handles these moments. You can simulate different reasons for a declined payment by using specific transaction amounts processed on your compatible Helcim devices on your developer test account.
How to simulate declines
When a transaction is declined by an issuing bank, the Payment Hardware API returns the result through a webhook event. You can test these decline responses and webhooks on your developer test account, by sending a transaction request where the total amount ends in a specific decimal value.
For example, if you send a request for $10.51, the payment hardware will simulate an "Incorrect PIN" response and a card transaction webhook event would be triggered. This allows you to see exactly how your software reacts to different declines without needing a real credit card.
Testing with in-person Fee SaverWhen testing payment declines, we recommend disabling in-person Fee Saver, as this feature can alter the final amount of the transaction processed on the device. This can result in an unintended approval or decline response being tested as a result.
Recommended decline handling
We suggest keeping things simple and helpful for your users. For most declines, a general message asking the customer to try a different card or payment method is the best approach.
Many devices will show specific reasons that only the cardholder can resolve with their bank. You should only show detailed error messages if the user can fix the issue right away, such as re-entering an incorrect PIN.
Decline codes for testing
Use the following decimal amounts to trigger specific responses on your compatible Helcim payment hardware.
| Transaction amount ending in | Payment response |
|---|---|
| .00 - .50 | APPROVAL |
| .51 | "Transaction Declined: PICK UP CARD - Pick up card" |
| .52 | "Transaction Declined: INCORRECT PIN" |
| .53 | "Transaction Declined: AMOUNT ERROR - Tran Amount Error" |
| .54 | "Transaction Declined: EXPIRED CARD - Expired Card" |
| .55 | "Transaction Declined: DECLINED - Do Not Honor" |
| .56 | "Transaction Declined: CALL AUTH. CENTER - Refer to Issuer" |
| .57 | "Transaction Declined: SERV NOT ALLOWED - Invalid request" |
| .58 | "Transaction Declined: AMT OVER SVC LMT - Amount is more than established service limit" |
| .59 | "Transaction Declined: INVALID CARD - Invalid Card" |
| .60 | "Transaction Declined: INVALID CAVV - Invalid Cardholder Authentication Verification Value" |
| .61 | "Transaction Declined: INVALID TERM ID - Invalid Terminal ID" |
| .62 | "Transaction Declined: NETWORK ERROR - General System Error" |
| .63 | "Transaction Declined: PLEASE RETRY - Please Retry/Reenter Transaction" |
| .64 | "Transaction Declined: REQ. EXCEEDS BAL. - Req. exceeds balance" |
| .65 - .99 | "Transaction Declined: GENERIC DECLINE" |
Handling webhooks for declines
When you use the Payment Hardware API, the Helcim system sends a notification to your server called a webhook. This is a way for one app to send real-time data to another whenever a transaction status changes. Even if a payment is declined on your devices, Helcim will send a webhook so your records stay up to date and you know to try again.
By testing these specific amounts, you can confirm that your system correctly records the decline and allows the customer to try the payment again.
Updated about 2 hours ago