3DS Standalone runs only the 3D Secure authentication step — no payment provider is involved and no authorization happens. The response returns the authentication result (ECI + CAVV cryptogram and related data), which the merchant uses to decide what to do next (for example, forward it to their acquirer).The flow uses the standard /payments endpoint. What runs depends on how the route is configured: for standalone, the route must resolve only to the Yuno 3DS connection with no payment provider attached, so only the authentication runs.
Go to Dashboard → Connections → Add Connection and select Yuno 3DS. Check the “Yuno 3DS Standalone” checkbox, fill in the acquirer data, and click Next.The acquirer data is the 3DS registration data your acquirer provides. For the default provider (Netcetera) the fields are:
Acquirer BIN — the Bank Identification Number used to clear and settle the transaction, together with the country where it is licensed.
Merchant ID — the affiliation number provided by the acquirer.
Merchant Category Code (MCC) — the code representing your merchant category, provided by the acquirer.
Merchant Name — the official business name conducting the transaction.
Merchant URL — the merchant’s website / online platform.
Country Code — the country where the payment is processed (ISO 3166-1).
Go to Dashboard → Routing and create a CARD route that points all transactions to the Yuno 3DS connection. The branch that handles standalone traffic must resolve only to the Yuno 3DS connection — no payment provider.
If you already have a CARD route that points to a payment provider and want standalone authentication to coexist with it, you can isolate the standalone traffic with a condition group on metadata (for example 3ds_connection = standard) that points only to the Yuno 3DS connection.
Selecting a specific connection (more than one 3DS Standalone connection)
If you have more than one 3DS Standalone connection configured — for example one set to Data Only and another with no preference (standard) — the router cannot decide on its own which one to use. In that case you must drive the selection explicitly with metadata.The mechanism has two parts that must always work together:
In the route: add a condition group per connection that matches on a metadata key (for example 3ds_connection = standard for one connection and a different value for the other). Each value points the traffic to the connection you want.
In the requests: add a metadata entry carrying that same key/value. It must be sent in both the 3DS Setup request and the /payments request — and it must be identical in both.
The 3DS Setup and the payment are routed independently. If the metadata sent in the 3DS Setup does not match the metadata sent in /payments, each call can resolve to a different connection — the Setup and the payment would then run against different connections and the authentication would not complete. Always send the samemetadata in both calls so they select the same connection from the route.
metadata is a JSON array of { "key", "value" } entries. Send the same entry in both the Setup and the payment:
If you have a single 3DS Standalone connection and the route has no other condition groups beyond it (no other connections or conditionals), this metadata selection is not required — the route resolves to that connection automatically. If the route combines the 3DS Standalone connection with other conditionals (for example a second standalone connection), use the metadata mechanism above to isolate and select it.
The 3DS Setup has two possible values in the type field. The difference is who collects the browser/device data used for authentication:
type
What it does
When to use
STANDARD (default)
Yuno (through the 3DS provider) handles the device-data collection. The response returns a collect_url and a token; the merchant must complete the collection by loading that collect_url with the token.
The standard flow — let Yuno / the 3DS provider drive the device-data collection.
MERCHANT_PROVIDED
The merchant sends all the required data themselves (browser_info and device_fingerprints), so no device-data collection step is performed.
When a 3DS provider already collects this data on its own and hands it to you.
If you have more than one 3DS Standalone connection, include the metadata in this request (as shown below) so the Setup is routed to the intended connection. Remember to send the samemetadata later in the /payments request.
Yuno performs the device-data collection. The merchant must complete it by going to the collect_url returned in the response and using the token also provided there.STANDARD is the default, so the type field can be omitted.Request
Completing the device-data collectionAfter you receive the collect_url and token, complete the device-data collection (the 3DS Method) before creating the payment.
Suggested implementation (reference only — not a fixed contract). The exact field name and mechanics can vary by 3DS provider, so validate against the provider you use. The general idea: render a hidden iframe and auto-submit a form that POSTs the token to the collect_url, wait for the period indicated by timeout_value, then continue to create the payment.
<!-- Hidden iframe that receives the collection POST --><iframe name="ddc-iframe" style="display:none"></iframe><!-- Auto-submitting form: POST the token to the collect_url --><form id="ddc-form" target="ddc-iframe" method="POST" action="COLLECT_URL"> <input type="hidden" name="threeDSMethodData" value="TOKEN"></form><script> document.getElementById('ddc-form').submit(); // wait up to timeout_value (e.g. 3000) before continuing to create the payment</script>
If the provider returns an emptycollect_url and token (for example CHECKOUT_COM_3DS above), there is no collection step — skip it and go straight to creating the payment.
The merchant sends all the required data themselves (browser_info and device_fingerprints), so no device-data collection step is performed.
Use device_fingerprints only when a 3DS provider that collects this data on its own (i.e. does not use the collect_url) hands you the fingerprint id — forward that id here. The provider_id must match the 3DS provider configured on the connection.
Create the payment using the three_d_secure_setup_id generated in the previous step. Since the route resolves only to the Yuno 3DS connection (no payment provider), only the authentication runs and the 3DS result is returned — no authorization takes place.
Payment method: because this is a standalone 3DS authentication flow, the card must already be available to it — either send the card_data in the request, or reference a payment method that was enrolled (vaulted) beforehand. Do not send vault_on_success: true — this flow does not support it.
If you used metadata in the 3DS Setup to select a specific connection, you must send the samemetadata here. Otherwise the payment may be routed to a different 3DS Standalone connection than the Setup.
Workflow: a frictionless / data-only authentication resolves inline (the examples ran with workflow: DIRECT) and the result comes back on the payment response. A challenge needs the cardholder to act, so the payment returns PENDING with a redirect_url and checkout.sdk_action_required: true — handle it with a redirect-capable workflow (REDIRECT) or the Yuno SDK (see Authentication outcomes → Challenge).
The payment’s top-level status / sub_status tell you the outcome, and the 3DS result lives in payment_method.payment_method_detail.card.three_d_secure:
Frictionless / Data Only → status: SUCCEEDED, sub_status: THREE_D_SECURE_VERIFIED.
Challenge → status: PENDING, sub_status: WAITING_ADDITIONAL_STEP, with checkout.sdk_action_required: true and a redirect_url (resolves later — see Webhook notification).
A standalone payment ultimately resolves to either SUCCEEDED / THREE_D_SECURE_VERIFIED (authentication completed) or DECLINED (authentication failed or rejected). The transaction-level status and 3DS response codes follow the standard Yuno reference — Transaction statuses and response codes (for example SUCCEEDED_THREE_D_SECURE, CHALLENGE_REQUIRED, AUTHENTICATION_FAILED_THREE_D_SECURE, REJECTED_THREE_D_SECURE_REQUIRED).
The payment comes back as PENDING with a redirect_url and checkout.sdk_action_required: true. At this point the three_d_secure object carries the challenge data (pares_status: C, empty ECI, and a cryptogram that holds the encoded challenge request):
Once the cardholder completes the challenge, the final result is delivered through the payment webhook (see Webhook notification below): status: SUCCEEDED / THREE_D_SECURE_VERIFIED on success (populated electronic_commerce_indicator and cryptogram / CAVV, pares_status: Y, has_challenge: true), or status: DECLINED if the challenge fails.
Flow summary:
The payment response comes back as PENDING / WAITING_ADDITIONAL_STEP (response_code: CHALLENGE_REQUIRED), with checkout.sdk_action_required: true and a redirect_url.
The cardholder must complete the issuer challenge:
With the Yuno SDK: the SDK renders the challenge automatically.
With a redirect-capable workflow (REDIRECT): redirect the cardholder to the redirect_url returned in the payment response so they can complete the challenge.
The cardholder completes the challenge (OTP, biometrics, Out-of-Band, Decoupled, Passkeys/FIDO-SPC). It is asynchronous.
When finished, the cardholder is returned to your callback_url, and the final authentication result is delivered through the payment webhook (payment.purchase) — or read it via GET /v1/payments/{id}.
On success (pares_status = Y) the payment is SUCCEEDED / THREE_D_SECURE_VERIFIED and liability shift = yes; if the challenge fails the payment is DECLINED. Until the result arrives, the merchant sees the payment as PENDING.
The ACS returns a non-authenticated result (pares_status N / R) or the authentication is rejected.
The payment resolves to DECLINED; the transaction carries a failure response code such as AUTHENTICATION_FAILED_THREE_D_SECURE or REJECTED_THREE_D_SECURE_REQUIRED.
No liability shift — there is no successful authentication.
For frictionless and data-only, the three_d_secure result is available on the payment response immediately (status: SUCCEEDED). For a challenge, the result is delivered asynchronously once the cardholder finishes — see Webhook notification — or poll GET /v1/payments/{id} to read the final three_d_secure result.
The authentication result is delivered through the standard Yuno payment notification — the same webhook you already use for payment status updates. There is no separate 3DS-specific webhook. The event is a payment notification with type_event: "payment.purchase"; the payment is under data.payment, and the 3DS result is in data.payment.transactions.payment_method.payment_method_detail.card.three_d_secure.
For a declined authentication the same webhook (payment.purchase) is delivered — only the status changes: the payment is DECLINED and the transaction carries a failure response code such as AUTHENTICATION_FAILED_THREE_D_SECURE or REJECTED_THREE_D_SECURE_REQUIRED.
Example — successful authentication (after a completed challenge)
The 3D Secure protocol version used for the authentication (e.g. 2.1.0 / 2.2.0 / 2.3.1). Newer versions enable additional challenge methods (OOB, Passkeys/FIDO, etc.).
electronic_commerce_indicator (ECI)
Indicates the authentication result and who bears fraud liability. Visa: 05 authenticated / 06 attempted / 07 not authenticated. Mastercard: 02 authenticated / 01 attempted / 00 not authenticated. Empty while a challenge is still pending.
cryptogram
The CAVV/AAV — cryptographic proof generated by the issuer that authentication took place. Unique per transaction; sent to the acquirer in the authorization to validate the 3DS. While a challenge is pending, this field carries the encoded challenge request instead.
transaction_id
The 3DS Server Transaction ID (threeDSServerTransID) — identifier of the 3DS transaction assigned by the 3DS Server in 3DS2. Correlates the AReq/ARes messages. (This is the 3DS2 value; the legacy 3DS1 “XID” is a different field.)
directory_server_transaction_id (dsTransID)
Unique transaction identifier assigned by the Directory Server (Visa/Mastercard) in 3DS2. A mandatory value that must travel in the authorization alongside the cryptogram.
pares_status
Authentication result (EMVCo transStatus): Y authenticated, N failed, A attempted, U unavailable, R rejected, C challenge required, I data only.
acs_id
Identifier of the issuer’s ACS (Access Control Server) that processed the authentication. Used for reference/traceability to the ACS that responded.
has_challenge
Whether the authentication went through a challenge (true) or was frictionless / data-only (false). Present in the webhook payload.
For a challenge in the sandbox, complete it with the password Checkout1!. See the Checkout.com 3DS test cards documentation for expiry/CVV and additional cards.
