Q3DS — 3-D Secure Server

Q3DS — 3-D Secure Server

Q3DS is the QoinPay Enterprise 3-D Secure 2 server. It performs EMV 3DS cardholder authentication during e-commerce and card-on-file transactions, shifting fraud liability to the issuer where the protocol allows and reducing declines through risk-based frictionless authentication. Q3DS runs entirely on your infrastructure and connects outward only to the card-scheme Directory Servers and, through them, to issuer Access Control Servers (ACS).

What Q3DS does

Q3DS implements the 3DS Server role defined by the EMVCo 3-D Secure 2 specification. It orchestrates the authentication message flow between your commerce application (the merchant/acquirer side), the scheme Directory Server (DS), and the issuer's ACS:

1. Method call — an optional browser step that lets the issuer's ACS fingerprint the device before authentication, improving the chance of a frictionless outcome.
2. Authentication request (AReq) — Q3DS assembles the cardholder, transaction, device, and merchant data elements and sends the AReq to the DS, which routes it to the correct ACS.
3. Frictionless flow — if the issuer's risk assessment is satisfied, the ACS returns an authentication response (ARes) with a valid authentication value and no cardholder interaction. This is the common, best-experience path.
4. Challenge flow — if the issuer needs step-up, Q3DS drives the challenge (CReq/CRes) — a one-time passcode, a banking-app approval, or biometric — and completes with a results request (RReq/RRes) carrying the final authentication value.

The output is an authentication value (CAVV/AAV) and ECI that your authorization request carries to the acquirer, together with the transaction status and, where applicable, the liability-shift indicator.

Capabilities

• 3DS2 browser and app flows — full support for 2.x browser-based and in-app SDK authentication, including the method-call device fingerprint and both challenge and frictionless outcomes.
• Multi-scheme — a single Q3DS instance can be configured with the DS endpoints and signing material for multiple card networks, selected automatically by BIN range.
• Risk data enrichment — Q3DS forwards the rich 3DS2 data set (device, prior transaction, account age, shipping) to maximize frictionless rates; the fields you populate directly affect approval outcomes.
• Results and audit — every authentication is persisted with its message identifiers (threeDSServerTransID, acsTransID, dsTransID), status, and the returned authentication value, giving a complete, disputable audit trail.

Integration

Q3DS exposes a compact REST surface at /api/v1 for the three logical steps your application needs: begin authentication, submit challenge result, and fetch the final outcome. Scheme-facing traffic (AReq/RReq to the DS) is handled by Q3DS itself over mutually authenticated TLS with the scheme-issued certificates.

POST /api/v1/3ds/authentications
Content-Type: application/json

{
  "acctNumberToken": "tok_9f2a...",
  "purchaseAmount": "4999",
  "purchaseCurrency": "840",
  "messageCategory": "01",
  "deviceChannel": "02"
}

A typical response tells your flow whether to proceed straight to authorization or to render a challenge:

{
  "threeDSServerTransID": "c9b1...",
  "transStatus": "C",
  "acsURL": "https://acs.issuer.example/challenge",
  "authenticationValue": null
}

Note the account number is supplied as a QVault token, not a raw PAN — keeping Q3DS and your commerce application out of PCI cardholder-data scope wherever possible.

Editions

• Standard — single-scheme 3DS2 server with browser and app flows, frictionless and challenge, and full authentication audit. Appropriate for merchants and single-network acquirers.
• Advanced — multi-scheme routing by BIN, high-availability active-active deployment, extended risk-data mapping, and the signed-webhook results stream for asynchronous reconciliation.

The active edition is set by the license key and can be upgraded in place.

Sizing

3DS authentication is latency-sensitive and largely I/O-bound on the outbound TLS calls to the DS:

• Up to ~30 auth/s: 4 vCPU / 8 GB, single node, with adequate outbound bandwidth and low-latency routes to the scheme directories.
• 30–150 auth/s: 8 vCPU / 16 GB across two or more nodes behind the load balancer; size the connection pool to the DS for peak concurrency.
• 150+ auth/s: scale nodes horizontally and pin scheme TLS sessions; the authentication store grows at roughly 2–4 KB per authentication including message identifiers.

Because challenge flows hold state between requests, ensure sticky routing or a shared session store when running multiple nodes.

Licensing

Q3DS is perpetually licensed per production instance, with the edition and enabled schemes encoded in the activation key. First-year SnS is included and covers EMVCo specification updates, scheme-mandated protocol changes, and certificate-rotation tooling — important because scheme mandates change on a fixed cadence. See the licensing overview for the entitlement lifecycle and activation.

Deployment security

• Q3DS holds scheme-issued signing and TLS certificates — store their private keys in the platform HSM or key store, never in the application config, and restrict file permissions on any on-disk material.
• Terminate scheme TLS with mutual authentication; validate the DS certificate chain and pin where the scheme supports it.
• Keep the Q3DS REST surface on the internal tier behind your authenticated gateway; the only components that should reach it are your commerce backend and, for the challenge redirect, the cardholder browser via a controlled URL.
• Never persist raw PANs — reference cards by QVault token throughout, and pair with QShield so authentication outcomes can feed transaction-level fraud rules.