Some transactions are getting declined with code -66 ('Soft Decline'). What can be the reason?


In the realm of online payments, merchants occasionally encounter the phenomenon of "Soft Declines," especially in the context of 3-D Secure 2 (3DS2) transactions. This situation can arise when certain conditions are not met, such as in the case of Credential on File (CoF) transactions. To understand why Soft Declines occur in this scenario, it's important to consider the background of 3DS2 and the specific requirements for CoF transactions.

Background: 3DS2 and CoF Transactions

3DS2 is a security protocol designed to make online payments more secure. It enables better authentication of the cardholder by the bank that issued the card. Credential on File refers to the storage of payment information by a merchant or payment provider to simplify future transactions.

In CoF transactions, there are two types: Customer Initiated Transactions (CIT) and Merchant Initiated Transactions (MIT). CITs are transactions where the customer is actively involved, while MITs are transactions initiated by the merchant without direct customer involvement.

Why Do Soft Declines Occur in 3DS2?

  1. Missing or Incorrect Labeling in the Initial CIT

When an initial transaction is conducted, it must be marked in the credentialOnFile JSON object as CIT; initial=true. This labeling signifies that it is the first transaction in a series of CoF transactions. If this labeling is missing or incorrect, the cardholder's bank may view the transaction as unauthenticated and thus reject it (Soft Decline).

  1. Failure to Transmit SchemeReferenceID in Subsequent Transactions

After successfully conducting an initial transaction, a SchemeReferenceID is returned by the payment gateway. This ID must be transmitted in every subsequent transaction to indicate that these transactions are connected to the initial, authenticated transaction. Failure to correctly transmit or include this ID can lead to a Soft Decline, as the bank or payment gateway cannot establish a connection to the original, authenticated transaction.

  1. Incorrect Flagging in MIT Transactions

For Merchant Initiated Transactions, the flag initial=false must be set. This indicates that it is a follow-up transaction based on an earlier transaction authorized by the customer. Incorrect flagging here can also lead to a Soft Decline, as the transaction is not correctly identified as part of an already authorized series of transactions.


Soft Declines in 3DS2 transactions, particularly in relation to Credential on File, typically occur due to inconsistencies in labeling and data transmission. It's crucial for merchants and payment providers to correctly mark initial transactions as CIT; initial=true, correctly transmit the SchemeReferenceID in all subsequent transactions, and set the flag initial=false for MITs. Adhering to these requirements helps avoid Soft Declines and ensures a smooth payment experience for customers.

Was this article helpful?
1 out of 1 found this helpful