Most merchants set up their challenge iframe once, during the original 3DS integration, and have not looked at it since. That was defensible when the guidance was advisory. It is not any more.<\/p>\n
EMVCo released the EMV 3D Secure Browser Flow Best Practices in September 2021, explaining the benefits of using iframes and setting out recommendations for iframe settings that support secure and smooth processing of both the challenge and the browser data collection mechanism.<\/p>\n
Those recommendations are now requirements, present across versions 2.1.0, 2.2.0, and 2.3.1.1 of the Core Specification. Merchants, as 3DS Requestors, must implement them, and EMVCo is direct about the consequence of not doing so: it puts 3DS transactions at risk of failure.<\/p>\n
If nobody at your organisation has reviewed the iframe configuration since the original build, this is worth a morning.<\/p>\n
The reason this moved from guidance to requirement is not administrative tidying. It is Secure Payment Confirmation and WebAuthn.<\/p>\n
EMVCo notes that merchants must implement these requirements for their own security and to enable correct processing of the 3DS flow, especially in view of the introduction of SPC and WebAuthn, meaning FIDO authentication, in version 2.3.1.1.<\/p>\n
That connection is worth understanding. Browser-based cryptographic authentication is considerably more sensitive to the security context an iframe runs in than a simple form-entry challenge ever was. An iframe configuration that was adequate for a cardholder typing a passcode may not permit the browser to perform a WebAuthn operation at all.<\/p>\n
So an implementation that has quietly worked for years can fail the first time an issuer offers a passwordless challenge to one of your cardholders, and it will fail for a reason nobody on your team is looking at.<\/p>\n
This is the part where an article should stop and point elsewhere, so that is what this one does.<\/p>\n
The specific iframe attributes and their required values are set out in the Browser Flow Best Practices document and, in requirement form, in the Core Specification for the version you are running. Take them from those sources rather than from a third-party summary, including this one. iframe security attributes are exactly the kind of detail where an out-of-date copy is worse than no copy, because it looks authoritative and is wrong.<\/p>\n
What this article can usefully tell you is where the requirements bite and what to check.<\/p>\n
Three distinct things run inside or alongside it, and each imposes its own constraints.<\/p>\n
The browser data collection mechanism.<\/strong> The requestor redirects a hidden iframe to the ACS URL using an HTTP post, and the ACS should use the appropriate content type for that first interaction. The ACS must ensure there is no user impact or interaction during execution. If your iframe configuration prevents that hidden execution from completing, you lose the device data that would have supported a frictionless outcome, and you lose it silently.<\/p>\n The challenge itself.<\/strong> The cardholder interacts inside the iframe. Anything your configuration blocks, the challenge cannot use.<\/p>\n Cryptographic authentication.<\/strong> SPC and WebAuthn operations have their own requirements for the browsing context they run in. This is the newest of the three and the one most likely to be unsupported by an older configuration.<\/p>\n Two other browser-channel problems interact with iframe configuration, and it is worth checking all three together rather than separately.<\/p>\n Where a cardholder authenticates out of band and the operating system reclaims the browser, the recovery depends on the requestor restoring the challenge iframe so the ACS can send the final response. EMVCo’s recommendation is that the requestor always restore the iframe on a browser restart, refresh the payment page, reopen the iframe and repost the original challenge request. An iframe that cannot be reliably recreated turns a recoverable interruption into a lost transaction.<\/p>\n And where the ACS has already sent its results message but has lost the connection to the challenge iframe, it may be unable to send the final challenge response at all unless the requestor reopens the iframe. The merchant side holds the recovery path there, not the issuer.<\/p>\n Five things to establish.<\/p>\n Which version of the iframe guidance your configuration was built against, and whether anyone has compared it to the current requirements for your protocol version.<\/p>\n Whether the hidden browser data collection mechanism actually completes in your live checkout, rather than being assumed to.<\/p>\n Whether a WebAuthn or SPC operation can run in your challenge context. If you cannot answer this, you do not yet know whether you support passwordless challenges.<\/p>\n Whether your checkout can recreate the challenge iframe after a page reload, and post the same challenge request again.<\/p>\n Whether anyone owns this configuration. In most organisations the answer is that it was set by a contractor during the original integration and has no current owner, which is the underlying reason it goes stale.<\/p>\n Are the iframe settings mandatory or just recommended?<\/strong><\/p>\n Mandatory. EMVCo published them as recommendations in September 2021, and they are now requirements in the Core Specification across versions 2.1.0, 2.2.0, and 2.3.1.1. Merchants must implement them, and EMVCo states that not doing so puts transactions at risk of failure.<\/p>\n Why did this become more important recently?<\/strong><\/p>\n Because of the introduction of Secure Payment Confirmation and WebAuthn in version 2.3.1.1. EMVCo highlights these specifically when explaining why merchants must implement the requirements. Browser-based cryptographic authentication depends on the security context of the iframe in ways that a form-entry challenge does not.<\/p>\n Where should we get the actual settings from?<\/strong><\/p>\n From the EMV 3D Secure Browser Flow Best Practices document and the Core Specification for your version. Iframe security attributes change, and a third-party summary that has fallen out of date is more dangerous than no summary at all.<\/p>\n Does this affect the hidden data collection iframe as well as the challenge?<\/strong><\/p>\n Yes. The same guidance covers iframe settings for both the challenge and the browser data collection mechanism. A configuration that blocks the hidden execution costs you device data and therefore frictionless outcomes, and it fails silently.<\/p>\n Reviewing your browser-channel configuration?<\/strong> ActiveServer<\/a> is the GPayments 3DS Server solution for merchants, acquirers and payment service providers. Speak with a 3DS specialist<\/a> about browser flow implementation.<\/p>\n","protected":false},"excerpt":{"rendered":" Most merchants set up their challenge iframe once, during the original 3DS integration, and have not looked at it since. That was defensible when the guidance was advisory. It is not any more. EMVCo released the EMV 3D Secure Browser Flow Best Practices in September 2021, explaining the benefits of using iframes and setting out […]<\/p>\n","protected":false},"author":13,"featured_media":3111,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[2],"tags":[13],"class_list":["post-3098","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article","tag-3ds2"],"aioseo_notices":[],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3098","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=3098"}],"version-history":[{"count":4,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3098\/revisions"}],"predecessor-version":[{"id":3112,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3098\/revisions\/3112"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media\/3111"}],"wp:attachment":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media?parent=3098"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/categories?post=3098"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/tags?post=3098"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Where this connects to the failures you are already seeing<\/strong><\/h2>\n
A short review checklist<\/strong><\/h2>\n
Frequently Asked Questions<\/strong><\/h2>\n