Most acquiring-side 3DS implementations send the same shaped authentication request to every issuer and find out what happened afterwards. That works, in the sense that transactions authenticate. It also means a good deal of information the protocol hands you before the request is ever built goes unused.<\/p>\n
Card range data does not only tell you which protocol versions an issuer’s Access Control Server supports. It tells you which features that ACS supports for a given card range. If you are requesting behaviour the issuer cannot deliver, you can know that in advance.<\/p>\n
The ACS Information Indicator provides additional information to the 3DS Server for a particular protocol version, listing all applicable values for the card range.<\/p>\n
In practice it answers questions such as whether the ACS supports the trust list, whether it supports applying a trust list exemption, whether it supports device binding, and whether it supports each of the exemption types the protocol signals. Support for the trust list and support for the trust list exemption are carried as separate values, which is a useful indication of how granular this is. An ACS can be capable of prompting a cardholder to enrol a merchant without being capable of applying an exemption on that basis.<\/p>\n
The indicator arrives as part of a broader capability picture in card range data, alongside the most recent protocol versions the ACS supports, optionally the Directory Server hosting the range, and where configured the ACS URL for the browser-channel data collection mechanism. Supported message extensions are carried in the same structure.<\/p>\n
Taken together, this is a per-range profile of what the far end of the transaction can actually do.<\/p>\n
Three reasons, in ascending order of importance.<\/p>\n
Your requests become accurate.<\/strong> Setting a challenge indicator requesting a trust list exemption against an ACS that does not support one is not an error. Nothing rejects it. But you have expressed an intention that cannot be honoured, and your own reporting will now record an exemption request that was never realistically going to succeed.<\/p>\n Your reporting becomes interpretable.<\/strong> This is the larger benefit. If you measure exemption requests against exemptions granted without accounting for capability, your ratio is contaminated by requests made to issuers who could never have granted them. Segmenting by capability first turns a meaningless aggregate into a diagnostic that actually points at something.<\/p>\n Your feature decisions become evidence-based.<\/strong> Should you invest engineering effort in supporting device binding status in your requests? That depends substantially on what proportion of your traffic reaches issuers whose ACS supports it. That is a question card range data can answer, and very few acquirers have ever asked it.<\/p>\n All of this rests on your card range data being current.<\/p>\n The capability picture is supplied through card range data from the Directory Server. If your cache has drifted, your capability profile has drifted with it. You may be missing features an issuer has since enabled, or continuing to request ones that have been withdrawn.<\/p>\n There is a second-order consequence worth naming. Because capability is expressed per card range, and ranges change as portfolios move between processors and ACS platforms, a stale cache does not degrade uniformly. It degrades unevenly, affecting some issuers and not others, which makes the resulting pattern in your data look like issuer behaviour rather than a cache problem. Teams have spent a long time investigating an issuer’s apparent change in risk appetite that turned out to be their own refresh cadence.<\/p>\n Before you build anything on capability discovery, confirm your refresh is working and that you can demonstrate it.<\/p>\n You do not need a full implementation to get value from this. A read-only analysis is a reasonable first step and can usually be done from data you already hold.<\/p>\n Take your card range data as it currently stands and profile it. For each feature the indicator can express, what proportion of your transaction volume reaches an ACS that supports it? Not what proportion of ranges, which will mislead you, but what proportion of actual volume, weighted properly.<\/p>\n That single table tends to reorder feature roadmaps. Teams frequently discover that a capability they had deprioritised is supported across most of their volume, or that one they were about to build reaches almost none of it.<\/p>\n From there, the natural second step is to gate your request construction on capability rather than sending a uniform request shape. And the third, once both are in place, is to segment your authentication reporting by capability so that your success metrics compare like with like.<\/p>\n Two limits worth stating plainly, because overreading this is the main way to get it wrong.<\/p>\n Capability is not willingness. An ACS that supports an exemption type will not necessarily apply it. The issuer evaluates the risk associated with each transaction and decides, and support for a feature says nothing about how conservatively that issuer’s risk model is tuned. Capability tells you whether the request is coherent. It does not predict the outcome.<\/p>\n And capability is per card range, not per issuer. A single issuer may present differently across ranges, particularly where portfolios have been acquired or migrated. Aggregating capability to the issuer level will produce a tidier table and a less accurate one.<\/p>\n Capability discovery is unglamorous and it is one of the cheaper improvements available to an acquiring-side implementation, because it requires no change from issuers and no new integration. The data is already arriving. The question is whether anything reads it.<\/p>\n For most 3DS Servers, the answer today is that it is used to determine protocol version and then discarded. There is considerably more in it than that.<\/p>\n Which indicator values are actually valid?<\/strong><\/p>\n It depends on the protocol version, and the ranges differ substantially. In the EMVCo-defined range there are two valid values for version 2.1.0, four for version 2.2.0, and eleven for version 2.3.1. Values are only valid for the version they are defined for, so a value that is meaningful on one version may not be on another.<\/p>\n What should the 3DS Server do with an unrecognised value?<\/strong><\/p>\n Where a preparation response contains an indicator value that is undefined for the protocol version, 3DS Servers must respond with an error message. This is a requirement rather than a recommendation, so it is worth confirming your implementation does it.<\/p>\n Does a supported capability mean the issuer will honour a request?<\/strong><\/p>\n No. Capability tells you whether your request is coherent. It says nothing about how conservatively that issuer’s risk model is tuned. The issuer evaluates each transaction and decides, so support and willingness are separate questions and should be measured separately.<\/p>\n Where do values outside the EMVCo range come from?<\/strong><\/p>\n Some values are reserved for Directory Server use. For those, 3DS Servers should refer to the individual 3DS programmes to understand which values have been defined and are considered valid, since they are scheme-specific rather than protocol-wide.<\/p>\n Reviewing your 3DS Server implementation?<\/strong> ActiveServer<\/a> is the GPayments 3DS Server solution for acquirers, gateways and payment service providers. Speak with a 3DS specialist<\/a> about capability-aware request construction.<\/p>\n\n\n","protected":false},"excerpt":{"rendered":" Most acquiring-side 3DS implementations send the same shaped authentication request to every issuer and find out what happened afterwards. That works, in the sense that transactions authenticate. It also means a good deal of information the protocol hands you before the request is ever built goes unused. Card range data does not only tell you […]<\/p>\n","protected":false},"author":13,"featured_media":3026,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[2],"tags":[37,46],"class_list":["post-3025","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article","tag-acs","tag-activeserver"],"aioseo_notices":[],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3025","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=3025"}],"version-history":[{"count":3,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3025\/revisions"}],"predecessor-version":[{"id":3032,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3025\/revisions\/3032"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media\/3026"}],"wp:attachment":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media?parent=3025"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/categories?post=3025"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/tags?post=3025"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The dependency nobody checks<\/strong><\/h2>\n
A practical way to start<\/strong><\/h2>\n
What it does not tell you<\/strong><\/h2>\n
Where this fits<\/strong><\/h2>\n
Frequently Asked Questions<\/strong><\/h2>\n