{
"message": "<string>",
"code": "<string>",
"issues": [
{
"message": "<string>"
}
]
}Create 3DS session from external authentication values (bring your own 3DS)
You already run 3-D Secure with your own MPI / 3DS server and only want Tagada to charge.
Report the final authentication values (ECI, CAVV/AAV, DS transaction id, protocol version) and
Tagada stores them as an already-authenticated 3DS session. Pass the returned id as
threedsSessionId to POST /payments/process (or /checkout/pay-v2): the values are
forwarded verbatim to the acquirer, with no Tagada-side authentication. The acquirer can still ask
the shopper to authenticate if the issuer or its own rules require it.
When to use it
- You collect cards and run 3DS in your own PCI environment and use Tagada as one PSP among others.
- You authenticated once (3RI /
type: merchant) and charge later as a MIT — pair it withinitiatedBy: 'merchant'on the charge.
Rules
- Only
transStatusY(authenticated) andA(attempted, network stand-in) create a usable session;N/U/R/Iare stored as failed and their values are never forwarded. dsTransIDis required for a 3DS 2.x result withY/A, but the session is still created without one: many callers create sessions they never use. Its values are not forwarded to the charge, because acquirers reject an authenticated 2.x result with no DS transaction id.- The values are forwarded as-is; the acquirer validates the CAVV. Liability shift follows the scheme rules for the ECI you report, not a Tagada decision.
Acquirer support — the target processor must accept externally-authenticated values:
NMI, RouteSense, Mastercard MPGS, Adyen (mpiData), Airwallex (external_three_ds).
The processor must have enable3DS on and the payment flow threeDsEnabled.
Stripe accounts connected directly (not through TagadaPay) ignore them and run their own 3DS.
TagadaPay processors (Adyen, Stripe, Checkout.com) — on a TagadaPay account whose PSP is Adyen,
Stripe or Checkout.com, the values are used without enable3DS or threeDsEnabled, on
customer-initiated card charges: the PSP receives them in place of Tagada’s request for its own 3DS.
They are not used, and the payment runs as if none had been sent (the PSP’s own 3DS included), for a
3RI (type: merchant) session, a result other than Y / A, a CAVV that is not 28-character
base64, a dsTransID that is not a UUID, an ECI other than 01 / 02 / 05 / 06, a 3DS version other
than 2.1.x / 2.2.x, a Cartes Bancaires card, an authentication older than 90 days, a merchant-initiated
charge, a wallet payment or a $0 card verification. Stripe also skips them on a co-badged Cartes
Bancaires card and on a charge without customer-initiated stored credentials; Checkout.com skips them
on a card saved at Checkout.com. TagadaPay accounts on another PSP ignore them.
Also used by the internal payment sandbox to replay specific 3DS outcomes.
Requires: org:admin role
{
"message": "<string>",
"code": "<string>",
"issues": [
{
"message": "<string>"
}
]
}Authorizations
Enter your API key as: Bearer your-api-key
Body
Electronic Commerce Indicator returned by the 3DS server (e.g. 05 / 06 Visa, 02 / 01 Mastercard)
^\d{2}$CAVV (Visa, Amex, Discover) or AAV (Mastercard), base64 as returned by the 3DS server
1 - 128Final EMVCo transaction status: Y authenticated, A attempted (stand-in), N failed, U unavailable, R rejected, I informational. Only Y and A produce a usable session.
Y, A, N, U, R, I Directory Server transaction id (UUID). Acquirers require it for an authenticated 3DS 2.x result: a session without one is stored, but the charge that uses it is refused.
1 - 36ACS transaction id (UUID), when your 3DS server exposes it
1 - 363DS Server transaction id (UUID), when your 3DS server exposes it
1 - 36EMVCo 3DS protocol version used for the authentication (e.g. 2.2.0)
^(1\.0\.2|2\.\d\.\d)$Card brand the authentication ran on (visa, mastercard, amex…)
32customer for a cardholder-present (CIT) authentication, merchant for a 3RI / MIT authentication
customer, merchant Response
Successful response