curl --request POST \
--url https://api.tagada.io/api/public/v1/threeds/create-from-values \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '
{
"eci": "05",
"authenticationValue": "AAABBIIFmAAAAAAAAAWYAAAAAAA=",
"transStatus": "Y",
"dsTransID": "dd21fcc9-6725-4a82-9591-ce603405b0db",
"acsTransID": "4f1b6a0e-1b6d-4a7c-9a4e-2f7f0d5e1c22",
"messageVersion": "2.2.0",
"cardBrand": "visa"
}
'{
"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 — no challenge, no redirect, no Tagada-side authentication.
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 the charge is declined at the 3DS step. dsTransIDis required for a 3DS 2.x result withY/A— acquirers reject the charge without it.- 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).
Hosted-3DS PSPs (Stripe, Checkout.com) ignore them and run their own 3DS.
The processor must have enable3DS on and the payment flow threeDsEnabled.
Also used by the internal payment sandbox to replay specific 3DS outcomes.
Requires: org:admin role
curl --request POST \
--url https://api.tagada.io/api/public/v1/threeds/create-from-values \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '
{
"eci": "05",
"authenticationValue": "AAABBIIFmAAAAAAAAAWYAAAAAAA=",
"transStatus": "Y",
"dsTransID": "dd21fcc9-6725-4a82-9591-ce603405b0db",
"acsTransID": "4f1b6a0e-1b6d-4a7c-9a4e-2f7f0d5e1c22",
"messageVersion": "2.2.0",
"cardBrand": "visa"
}
'{
"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). Required for 3DS 2.x results with transStatus Y or A.
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