In browser-based EMV 3D Secure (EMV 3DS), the 3DS Method lets the issuer’s Access Control Server (ACS) collect browser information through a hidden frame on the merchant’s checkout. Because that frame belongs to the ACS while the page belongs to the merchant, anything the ACS stores there runs in a third-party context. Browser rules on third-party cookies and storage therefore decide how much the ACS can recognise about a returning device.
Where browsers stand on third-party cookies
The position changed several times between 2020 and 2025 and has now settled:
|
Browser |
Third-party cookies by default |
Source |
|
Safari |
Blocked, through Intelligent Tracking Prevention, since 2020 |
|
|
Firefox and Brave |
Blocked by default |
|
|
Chrome |
Allowed; Google confirmed in April 2025 that it would keep its existing approach and user controls rather than phase them out |
Chrome has separately enforced storage partitioning in third-party contexts since Chrome 115, so local storage used inside a third-party frame is kept separate for each top-level site (Salesforce developer guidance). In October 2025 Google retired most of its Privacy Sandbox APIs, keeping CHIPS (partitioned cookies), FedCM and Private State Tokens.
What restrictions on third-party cookies mean for the 3DS Method
Where an ACS relies on a cookie or stored identifier set inside the 3DS Method frame to recognise a returning device, that recognition works differently across browsers. In Safari, Firefox and Brave, the third-party cookie is blocked by default. Even where storage is allowed, partitioning means a value stored while the cardholder shops at one merchant is not visible when the same cardholder shops at another.
The 3DS Method itself still matters. It gives the ACS a chance to collect current browser information before the authentication request, and skipping it still raises challenge rates (why skipping the 3DS Method raises your challenge rate). What changes is the value of anything the ACS expects to persist in that frame between visits.
What issuers should rely on instead
- Browser data delivered in the authentication request itself, which does not depend on storage in the frame.
- Device binding established in the issuer’s own context, such as its banking app (device binding and ACS risk assessment).
- Passkeys registered with the issuer and used through Secure Payment Confirmation, which are bound to the issuer’s origin rather than a third-party cookie (passkeys and EMV 3DS).
- Risk models evaluated by browser family, so a lower recognition rate in Safari is not mistaken for higher risk.
What merchants and PSPs should check
Merchants cannot change how browsers treat the ACS frame, but they can make sure the 3DS Method runs on every browser authentication and that their content security policy does not block it. Merchants should also expect frictionless rates to differ by browser and should segment results that way before drawing conclusions (how merchants should measure 3D Secure performance).
Frequently asked questions
Did Chrome remove third-party cookies?
No. Google confirmed in April 2025 that Chrome would keep its existing approach to third-party cookies, with user controls in settings rather than a phase-out.
Does Safari block the 3DS Method?
No. The 3DS Method frame still loads and can collect browser information. What Safari blocks by default is third-party cookies set within that frame.
Should issuers stop using cookies in the 3DS Method?
Issuers should not depend on them for recognising returning devices across merchants, and should design risk models that work without them.
Do partitioned cookies (CHIPS) help?
Partitioned cookies keep a value separate for each top-level site, so they can help recognise a device returning to the same merchant, but not the same device at a different merchant.
Does this affect app-based 3DS?
Not in the same way. App-based flows use the 3DS SDK to collect device information, which does not rely on browser cookies.
Building recognition that lasts
GPayments provides ActiveAccess for issuers and ActiveServer for acquirers, PSPs and merchants. To discuss device recognition and the 3DS Method in your programme, contact GPayments.