A merchant sends a card transaction straight to authorisation without authenticating first. The issuer declines it, but not because anything is wrong with the card. The decline means something closer to: authenticate the cardholder and come back.<\/p>\n
This is a soft decline, and handling it correctly with 3DS is one of the more confusing moments in card payments, because a decline code that means try again looks exactly like a decline code that means stop. Merchants that treat the two the same lose sales they did not need to lose.<\/p>\n
The protocol has a specific way to handle the retry, and surprisingly few implementations use it properly.<\/p>\n
Depending on the market and the Directory Server rules in play, a merchant may send an ecommerce transaction directly for authorisation. In response, the issuer can indicate that the merchant should first initiate a 3DS authentication so the issuer can perform a challenge.<\/p>\n
The merchant then initiates that authentication. And here is the part that matters: when it does, the 3DS Server sets the requestor challenge indicator to the value meaning challenge requested by the issuer.<\/p>\n
That value exists specifically for this situation. It tells the ACS that this authentication is not the merchant speculatively asking for a challenge, but the merchant responding to the issuer’s own instruction. It is available in version 2.3.1.<\/p>\n
Consider what the ACS sees if you do not.<\/p>\n
An authentication request arrives with no particular indication of why. The ACS applies its normal risk assessment. It may conclude the transaction looks fine and return a frictionless result, because nothing in the request tells it that another part of the same institution has already asked for a challenge on this transaction.<\/p>\n
You then proceed to authorisation with a frictionless authentication in hand, and the issuer declines again, for the same reason as before. The cardholder sees two failures and gives up.<\/p>\n
Using the correct indicator closes that loop. The ACS understands the context and can act on it.<\/p>\n
Soft decline behaviour is driven by market rules and scheme programmes rather than by the protocol. It became common in markets subject to Strong Customer Authentication requirements, where an issuer receiving an unauthenticated ecommerce transaction that requires authentication has to do something other than approve it, but declining outright would be the wrong outcome for a legitimate cardholder.<\/p>\n
Two cautions follow, and both matter more than the mechanics.<\/p>\n
The specific decline response codes that indicate a soft decline, and the circumstances in which an issuer is expected to use them, are set by the card schemes and vary between them. Those codes are not defined in the 3DS specifications, and you should take them from your acquirer or the relevant scheme documentation rather than from a blog.<\/p>\n
And whether authenticating and retrying is permissible, and on what terms, depends on the applicable rules in the relevant market. Confirm requirements for the markets you operate in.<\/p>\n
Four things separate merchants who handle this well.<\/p>\n
Distinguish soft declines from hard declines in your response handling.<\/strong> This is the prerequisite. A retry-after-authentication response and a do-not-honour response should not take the same code path, and in a surprising number of gateways today they do.<\/p>\n Signal the retry correctly.<\/strong> Set the challenge indicator to the issuer-requested value rather than leaving it at a default or using a general challenge request. You have real information about why this authentication is happening, so pass it on.<\/p>\n Carry the same transaction context.<\/strong> The retry should describe the same purchase, at the same amount, with the same cardholder and merchant data as the original attempt. An authentication that looks like a different transaction from the one that was soft declined gives the issuer nothing to connect.<\/p>\n Cap the loop.<\/strong> A soft decline, an authentication, and one authorisation retry. If that second authorisation also fails, stop. Repeated cycles against the same card produce no better outcome and can look like probing behaviour to a fraud system.<\/p>\n Do not authenticate everything just to avoid this.<\/strong> It is tempting to conclude that the answer is to run 3DS on every transaction. For merchants in markets where authentication is generally required, that may well be right. For everyone else it means adding friction to the large majority of transactions that would have authorised cleanly, in order to avoid a retry on a small minority. Measure your actual soft decline rate before making that call.<\/p>\n Soft declines are usually invisible in merchant reporting because they are aggregated into a single decline figure alongside genuine declines.<\/p>\n Separating them out is worth doing, and the numbers tend to surprise people. You want to know what proportion of declines are soft, what proportion of those you retried with authentication, and what proportion of retries subsequently authorised. That third number is recovered revenue that currently appears nowhere.<\/p>\n If your gateway does not expose the distinction, that is a question worth putting to them, because everything else here depends on it.<\/p>\n Which response codes indicate a soft decline?<\/strong><\/p>\n They are set by the card schemes and differ between them, and they are not defined in the 3DS specifications. Take them from your acquirer or the relevant scheme documentation rather than assuming a common set.<\/p>\n Does the issuer have to challenge when we retry with the issuer-requested indicator?<\/strong><\/p>\n The ACS still performs its own risk assessment and decides. The indicator tells it that the authentication is a response to the issuer’s own request, which is materially more useful context than a generic challenge request, but it is not an instruction.<\/p>\n Is this only relevant in Europe?<\/strong><\/p>\n The pattern is most common in markets with Strong Customer Authentication requirements, but soft decline behaviour is driven by scheme rules and market conditions rather than by any one regulation. Whether it applies to you depends on your markets and your scheme programmes.<\/p>\n Can we avoid soft declines by authenticating every transaction?<\/strong><\/p>\n You can, and in markets where authentication is generally required that may be the right answer anyway. Elsewhere it means adding friction to most transactions to avoid a retry on a few. Measure your soft decline rate first.<\/p>\n Handling authentication retries in your payment flow?<\/strong> ActiveServer<\/a> is the GPayments 3DS Server solution for merchants, acquirers and payment service providers. Speak with a 3DS specialist<\/a> about your authentication flow.<\/p>\n","protected":false},"excerpt":{"rendered":" A merchant sends a card transaction straight to authorisation without authenticating first. The issuer declines it, but not because anything is wrong with the card. The decline means something closer to: authenticate the cardholder and come back. This is a soft decline, and handling it correctly with 3DS is one of the more confusing moments […]<\/p>\n","protected":false},"author":13,"featured_media":3085,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[2],"tags":[19,37],"class_list":["post-3082","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article","tag-3d-secure","tag-acs"],"aioseo_notices":[],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3082","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/comments?post=3082"}],"version-history":[{"count":4,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3082\/revisions"}],"predecessor-version":[{"id":3087,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3082\/revisions\/3087"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media\/3085"}],"wp:attachment":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media?parent=3082"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/categories?post=3082"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/tags?post=3082"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The reporting most merchants are missing<\/strong><\/h2>\n
Frequently Asked Questions<\/strong><\/h2>\n