adyen 403 on /payments when the merchant is not enabled for 3DS2

Adyen 403 on /payments when the merchant is not enabled for 3DS2

TL;DR

A 403 on /payments that mentions 3DS2 is an account configuration problem, not a code bug: your merchant account is not enabled for 3DS2, so Adyen refuses to process the request. Enable 3DS2 in the Customer Area (or ask Adyen support to enable it), then retry the same request unchanged. No code change is needed.

adyen 403 on /payments when the merchant is not enabled for 3DS2

Steps

1. Read the full 403 response body. Confirm it references 3DS2 enablement rather than authentication. Success check: the error text is about 3DS2 not being enabled, not about invalid credentials.

1. Rule out credential problems first: check you are using the right API key for the right environment (test vs live) and that it has not been revoked. Success check: a plain non-3DS request (or a request without 3DS fields) does not 403.

1. In the Customer Area, find the 3DS2 settings for your merchant account and enable 3DS2, or contact Adyen support to enable it if the toggle is not self-serve on your account. Success check: the account shows 3DS2 as enabled.

1. Retry the exact same /payments request that 403'd. Success check: the request now returns a normal resultCode (Authorised, Refused, or a 3DS2 action) instead of 403.

1. If the 403 persists after enablement, wait a few minutes for the config to propagate, then check you are hitting the matching environment endpoint (test key against the test URL, live key against the live URL). Success check: environment and key match.

When this applies

• /payments returns 403 with a message about 3DS2 not being enabled on the merchant account.
• A new Adyen integration works for plain payments but 403s as soon as 3DS2 is involved.
• An agent set up the integration with fresh test credentials and skipped the Customer Area setup.

When it doesn't

• 401 or 403 about invalid API keys; that is authentication, fix the key.
• 403 on other endpoints for other reasons; read the message, the fix follows the message.
• The 3DS challenge itself failing for the shopper; that is a flow problem, not enablement.

Tool + version compatibility

Adyen Checkout API v68+, Customer Area account configuration, EMV 3-D Secure 2.

"adyen payments 403 forbidden"

Read the body. A 403 with a 3DS2 message is enablement; a 403 with an auth message is credentials.

"adyen 3ds2 not enabled merchant account"

This is the same issue. Enablement lives in the Customer Area, not in your code.

"adyen 403 threeDS2RequestData"

If you are sending 3DS2 fields and getting 403, the account side is almost certainly the cause.

Why it happens

Adyen gates 3DS2 processing per merchant account. Agent-built integrations often go straight from API key to code and never touch the Customer Area, so the first 3DS2 payment hits an account that was never opted in. The API answers 403 because, from its perspective, you are requesting a capability the account does not have.

Edge cases / pitfalls

• Test and live are separate: enabling 3DS2 on test does nothing for live. Enable both.
• Some account types need Adyen support to flip the switch; the toggle may not exist in your Customer Area view.
• After enablement there can be a short propagation delay; do not re-diagnose a 403 in the first few minutes.
• Do not "fix" this by stripping 3DS fields from requests to dodge the 403; that changes your liability shift and compliance posture.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_dU18KvRLwZp3nCaaYGGjLQ