TL;DR — Confirm enablement first; re-authenticate with your provider rather than resubmitting the same evidence; never charge on an unconfirmed result.
When this happens
- The acquirer requires 3DS for this channel and no authentication evidence was supplied —
422 urn:radiumone:three-ds:authentication-required. - Authentication was attempted through RadiumOne’s own 3DS and did not succeed —
403 urn:radiumone:three-ds:not-authenticated. - Your outlet isn’t enabled to submit your own provider’s evidence —
422 urn:radiumone:three-ds:external-auth-not-permitted(Beta only — this gate doesn’t exist at the current Live SHA, so an unenabled outlet’s request is not yet rejected there; don’t rely on that as a substitute for confirming enablement). - The
three_dsevidence object has a missing, too-long, or unrecognized field —400(schema validation; the arm rejects unknown keys).
What you see
What to do
1
Confirm enablement before you rely on this path
See Use your own 3DS provider: before you begin. Without enablement, the charge is rejected.
2
Re-authenticate rather than resubmit the same evidence
A
three-ds:not-authenticated or authentication-required result means the charge needs a fresh, successful authentication from your provider — resubmitting the same (failed or missing) evidence won’t change the outcome.3
Never charge on an unconfirmed result
Charge only after your own provider has returned a verified result for this specific attempt — see Server policy.
4
Fix the evidence shape for a validation error
Check field lengths and that you’re not sending an unrecognized key inside the
three_ds object (API reference):Related
Use your own 3DS provider
The full guide, including ECI values and limitations.
Authentication results
The full 3DS error reference with HTTP codes and remedies.
Problem format and retries
The error shape, status guide, and retry rules.