Every authentication request your 3DS Server builds depends on information it obtained earlier, from a different source, about a card range it may not have seen recently. That information is card range data, and it is one of the quieter dependencies in an acquiring-side deployment.<\/p>\n
It is also one of the few places where a problem in your own infrastructure presents as a problem with somebody else’s.<\/p>\n
Card range data comes from the Directory Server and tells the 3DS Server what it needs to know about a range before building a request.<\/p>\n
It indicates the most recent protocol versions supported by the Access Control Server for that range. It optionally identifies the Directory Server hosting the range. Where configured, it carries the ACS URL used for the browser-channel data collection mechanism, which may be omitted where the ACS does not support that mechanism for the range.<\/p>\n
It also carries the ACS Information Indicator, which identifies the 3DS features the ACS supports for the range, such as trust list or decoupled authentication, and the supported message extensions.<\/p>\n
So a single card range record answers four questions at once. What version can we speak. Which features can we ask for. Which extensions will be honoured. And where do we send browser-channel data collection.<\/p>\n
This distinction matters more than it appears.<\/p>\n
Capability is expressed per card range. A single issuer can present differently across ranges, particularly where portfolios have been acquired, migrated between processors, or moved to a different ACS platform at different times.<\/p>\n
Aggregating your capability picture to issuer level produces a tidier table and a less accurate one. It also creates a specific failure mode, where a change affecting one range is either generalised across an issuer it does not apply to, or lost entirely because the aggregate did not move.<\/p>\n
If you are building reporting on top of this, keep the range as the unit.<\/p>\n
A stale cache does not produce an error. It produces a set of decisions made on an out-of-date picture, and the consequences show up in different places depending on which part of the record has moved.<\/p>\n
Version information drifts.<\/strong> You may build requests at a version the ACS no longer supports for the range, or continue at an older version after the issuer has enabled a newer one, which means you are leaving newer capabilities unavailable without knowing it.<\/p>\n Feature capability drifts.<\/strong> You request behaviour the ACS does not support, or you never request behaviour it has since enabled. Your feature adoption stalls for reasons that look like issuer conservatism.<\/p>\n The browser data collection URL drifts.<\/strong> Your pre-authentication data collection either fails or is skipped, which raises challenge rates in a population you have no obvious reason to suspect.<\/p>\n Extension support drifts.<\/strong> An extension you rely on is either unavailable at the far end, or newly available and unused.<\/p>\n Note the common shape. In every case the symptom appears on the issuer side of the transaction. Teams investigate the issuer, the issuer’s risk appetite, or the merchant segment routing to that issuer, when the cause sits inside their own refresh process.<\/p>\n A stale cache does not degrade evenly.<\/p>\n Card ranges change at different times for different reasons. Portfolios move. ACS platforms are upgraded. Features are enabled. A cache that has fallen behind is therefore wrong about some ranges and right about others, and the resulting pattern in your data looks like variation between issuers rather than a systemic problem in your infrastructure.<\/p>\n This is why the diagnostic is rarely reached by reasoning. It is reached by checking the refresh, which is a five-minute job that almost nobody does because the system appears to be working.<\/p>\n Four signals, none of them exotic, and most deployments currently monitor none of them.<\/p>\n Refresh success and recency.<\/strong> When did your last successful refresh complete, and would anybody know if it had not? A refresh process that fails silently is the most common version of this problem.<\/p>\n Coverage.<\/strong> What proportion of your live transaction volume matches a range you actually hold data for? Not what proportion of ranges, which will mislead you, but volume-weighted coverage.<\/p>\n Churn.<\/strong> How much of your card range data changed at the last refresh? A sudden change in churn is worth understanding. So is churn dropping to zero, which usually means the refresh has stopped working rather than that the world has stabilised.<\/p>\n Unmatched ranges.<\/strong> Transactions arriving for ranges you hold nothing for. A small proportion is normal. A rising proportion is a signal.<\/p>\n Card range data is upstream of several things that get discussed as though they were independent.<\/p>\n Your ability to use capability discovery deliberately depends on holding current capability data. Your ability to request exemptions coherently depends on knowing which the ACS supports. Your browser-channel data collection depends on holding the right URL. Your extension strategy depends on knowing where extensions will be honoured.<\/p>\n All four of those improvements are commonly pursued as separate projects. All four rest on the same foundation, and none of them will perform as expected if that foundation has quietly drifted.<\/p>\n Before investing in any of them, confirm the refresh is working and that you can evidence it. It is the cheapest prerequisite in the entire acquiring-side stack.<\/p>\n Take your current card range data as it stands and answer three questions.<\/p>\n When did it last refresh successfully, and how do you know? What proportion of last month’s transaction volume is covered by ranges you hold? And of the ranges carrying your highest volume, how many indicate support for features you are not currently requesting?<\/p>\n The third question usually produces the most surprise. Teams regularly find that capabilities they assumed were rare are supported across the majority of their volume, and that the reason adoption looked poor was never issuer readiness.<\/p>\n How is card range data actually retrieved?<\/strong><\/p>\n Through the preparation exchange. The 3DS Server sends a preparation request and the Directory Server returns card range data in the preparation response. From version 2.3.1 there is a second route: the Directory Server can instead provide a file URL for download, where both parties support it, signalled by a download indicator from the 3DS Server. Data retrieved by file download gets the same validation and processing as data received in the response message.<\/p>\n Is the file download method available on older protocol versions?<\/strong><\/p>\n Yes, through the bridging message extension for version 2.1.0 and version 2.2.0. One behaviour worth noting: when the file URL is present, the file contains the entire card range data, and the 3DS Server ignores any card range data and serial number present in the preparation response.<\/p>\n How often should we refresh?<\/strong><\/p>\n The specification does not set an interval, so there is no universal answer to quote. Refresh cadence is a matter for your Directory Server programme rules and your own operational monitoring. What matters more than the number is that the refresh is observable: a process that fails silently is the most common version of this problem.<\/p>\n What should happen when a transaction arrives for a range we hold nothing for?<\/strong><\/p>\n A small proportion of unmatched ranges is normal and the flow should handle it without treating it as an error. A rising proportion is a signal worth investigating, because it usually indicates either a refresh problem or a change in the traffic reaching you.<\/p>\n Reviewing your 3DS Server operations?<\/strong> ActiveServer<\/a> is the GPayments 3DS Server solution for acquirers, gateways, and payment service providers. Speak with a 3DS specialist<\/a> about card range data and capability handling.<\/p>\n\n\n\n\n","protected":false},"excerpt":{"rendered":" Every authentication request your 3DS Server builds depends on information it obtained earlier, from a different source, about a card range it may not have seen recently. That information is card range data, and it is one of the quieter dependencies in an acquiring-side deployment. It is also one of the few places where a […]<\/p>\n","protected":false},"author":13,"featured_media":3061,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[2],"tags":[35],"class_list":["post-3058","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article","tag-3ds-server"],"aioseo_notices":[],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3058","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=3058"}],"version-history":[{"count":4,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3058\/revisions"}],"predecessor-version":[{"id":3063,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3058\/revisions\/3063"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media\/3061"}],"wp:attachment":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media?parent=3058"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/categories?post=3058"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/tags?post=3058"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The pattern that makes this hard to spot<\/strong><\/h2>\n
What to monitor<\/strong><\/h2>\n
The dependency chain this sits at the top of<\/strong><\/h2>\n
A short starting exercise<\/strong><\/h2>\n
Frequently Asked Questions<\/strong><\/h2>\n