Knowledge Base Best Practices

Declined Transactions

Declined transactions are an inevitable part of payment processing, and transactions may be declined for various reasons. This article has been put together to provide additional information for developers working on the Negative Test sections of our Certification Test Script. Information for Credit / Debit and Stored Value (Gift) transactions are listed below. Additional information may be added at a later point in time, so please be sure to check back for updates.

TSYS has set up a series of tests which will simulate declined transactions that a merchant may experience in a production environment. These tests are triggered by specific dollar amounts as well as the card number used with the request, and can be found on our Certification Test Script. The purpose behind these tests is to ensure your Point of Sale application identifies and handles the responses accordingly. These tests are valid only against the Test Processor External platform. If you encounter any issues while testing, please reach out to developer@cayan.com for assistance.

Genius API

EMV Decline Online:

This test will simulate a standard bank issued decline due to insufficient funds during an online EMV transaction. When done correctly, you will receive a <Status>DECLINED</Status> response, as well as <ErrorMessage>Insufficient Funds</ErrorMessage>.

Decline Failure Test:

This test will simulate a standard bank issued decline during a swiped Credit Card transaction. Similar to the test above, when done correctly you will receive a <Status>DECLINED</Status> response, as well as <ErrorMessage>DECLINED;1012;decline </ErrorMessage>.

For the above tests, it is recommended that the POS application indicate to the cashier that the transaction had been declined, and to either attempt the transaction again, or supply another form of payment.
Referral Failure Test:

This test will simulate a scenario where the consumers card is not declined due to lack of funding, but that the merchant needs to contact their payment processors Voice Authorization line, and supply further information to obtain an approval. A <Status>REFERRAL</Status> response will be returned as well as <ErrorMessage>REFERRAL;1013 </ErrorMessage>. Should the merchant contact the Voice Authorization line and receive an approval code, a Force Capture request is still required in order for the merchant to receive funding.

Declined Duplicate Test:

Unlike the previous tests, the Declined Duplicate test is not a decline returned by the card issuer. The Declined Duplicate response can occur when a consumer attempts to make two or more identical purchases using the same card, for the same dollar amount, within the same batch. Unless specified within the request, the subsequent transaction(s) would be rejected by the gateway before reaching the processor as a means of preventing unintentional duplicates. This test will simulate such scenario, and return the appropriate response back to the POS. Provided your test environment is configured to block duplicates, the anticipated results should be <Status>DECLINED_DUPLICATE</Status> as well as <ErrorMessage>DECLINED,DUPLICATE;1110;duplicate transaction</ErrorMessage>.

When configured with a terminal based processor, settlement is typically performed at the end of the day by the POS or Payment Gateway. Additionally, merchants generally have the ability to settle manually if necessary. For host based processors, there is no option to settle manually and settlement can occur either once a day at a fixed time, or throughout the day at fixed intervals.
Gift Card Inactive (Sale) Test:

This test will simulate a scenario where the consumer is attempting to complete a transaction using a Stored Value (Gift) card which has not yet been activated. A <Status>DECLINED</Status> response will be returned as well as <ErrorMessage>Declined </ErrorMessage>.


MerchantWARE 4.5 API

Decline Failure Test:

This test will simulate a standard bank issued decline due to insufficient funds during an online EMV transaction. When done correctly, you will receive a <ApprovalStatus>DECLINED;1012;decline</ApprovalStatus> response.

It is recommended that the POS application indicate to the cashier that the transaction had been declined, and to either attempt the transaction again, or supply another form of payment.
Decline Duplicate Failure Test:

The Declined Duplicate test is not a decline returned by the card issuer. The Declined Duplicate response can occur when a consumer attempts to make two or more identical purchases using the same card, for the same dollar amount, within the same batch. Unless specified within the request, the subsequent transaction(s) would be rejected by the gateway before reaching the processor as a means of preventing unintentional duplicates. This test will simulate such scenario, and return the appropriate response back to the POS. Provided your test environment is configured to block duplicates, the anticipated results should be <ApprovalStatus>DECLINED,DUPLICATE;1110;duplicate transaction</ApprovalStatus>.

When configured with a terminal based processor, settlement is typically performed at the end of the day by the POS or Payment Gateway. Additionally, merchants generally have the ability to settle manually if necessary. For host based processors, there is no option to settle manually and settlement can occur either once a day at a fixed time, or throughout the day at fixed intervals.