adyen "threeds2.device.channel": browser channel required for 3DS2 on web
Explains the Adyen requirement that the 3DS2 device channel be set to browser for web checkouts: the channel tells the issuer what kind of device is authenticating. Use when 3DS2 fails or misbehaves on web. Not for app or 3RI channel setups.
TL;DR
On a web checkout, the 3DS2 device channel must be browser. If it is missing or set to app, the issuer gets wrong device context and authentication can fail or route incorrectly. Set the channel to browser in the 3DS2 request data and confirm the browser info fields are included.
threeds2.device.channel browser channel requiredUse this when
- 3DS2 authentication fails on a web checkout with a channel complaint.
- You are wiring 3DS2 fields manually instead of using Drop-in.
- Payments work in the app but fail on web, or vice versa.
Not for this skill when
- You are doing app-based 3DS2. The channel should be app there.
- You are doing merchant-initiated 3RI transactions. Different channel rules.
Steps
- ('Inspect the 3DS2 request data your integration sends. Verify: the device channel field is present.', 'Set the channel to browser for web checkouts. Verify: the value is exactly the browser channel.', 'Include the browser info object (accept header, user agent, screen dimensions, timezone, language, color depth, java enabled). Verify: all fields are populated from the real browser.', 'Submit a test 3DS2 payment. Verify: authentication proceeds without channel errors.', 'If you support web and app, branch the channel value by platform. Verify: each platform sends its own channel.')
Variant phrasings
adyen 3ds2 device channel
Short search.
threeds2 device channel web checkout
Field search.
adyen 3ds2 browser info required
Related-field search.
Compatibility: Adyen Checkout API 3D Secure 2, all versions with device channel support.
Why it happens
3DS2 is device-aware: the issuer authenticates differently for a browser session, a native app, and a background merchant request. The device channel declares which one this is, and the browser info fields give the issuer the fingerprint it expects from a web session. A wrong or missing channel hands the issuer app-shaped data for a browser payment, and issuers reject what does not match the declared context.
Edge cases / pitfalls
- Collect browser info at checkout time, not at page load. Stale values fail validation.
- Hardcoding the channel to browser in a shared integration breaks your app checkout. Branch it.
- Some fields like color depth have limited valid values. Pass real values, not guesses.
- If you use Adyen Drop-in or Components, this is handled for you. Manual wiring is where it breaks.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_wX0PfaVwI3vt5LAguAiXsQ