3-D Secure & SCA

Authenticate the cardholder with their issuer before you charge — frictionless where the issuer allows it, a challenge when it doesn't, and a liability shift when it succeeds.

3-D Secure is how the issuer confirms the person entering the card is the cardholder. Two reasons to care: in Europe and the UK it’s mandatory (Strong Customer Authentication), and everywhere it moves the cost of a fraud chargeback from you to the issuer. kepa runs the protocol; you read the outcome.

iProvider availability

Issuer challenges are enabled after a certified 3DS provider is configured for your account. If the provider is unavailable or no verified result arrives, Kepa fails checkout confirmation closed.

Automatic 3-D Secure

Pass threeDS: "automatic" to confirm and kepa.js starts the authentication exchange. Frictionless authentication resolves without interrupting the customer. When an issuer challenge is required, kepa.js renders the secure ACS frame and waits for Kepa to receive the provider-verified result before continuing.

// kepa.js — threeDS "automatic" starts authentication
await payment.confirm(checkoutSessionId, clientSecret, {
  threeDS: "automatic",
});
// frictionless: resolves immediately, authenticated
// challenge: renders the issuer ACS and waits for a verified provider result

Four outcomes

StatusMeansLiability

AUTHENTICATEDThe issuer authenticated the cardholder — frictionless, or after a challenge.Liability shifts

ATTEMPTEDThe issuer or network isn't enrolled, but the attempt is recorded.Partial shift

CHALLENGE_PENDINGThe issuer wants a step-up; the customer completes it, then it resolves.Resolves to one of the above

FAILEDAuthentication failed or the directory was unreachable.No shift — you decide

Liability shift

When authentication succeeds, the result carries liabilityShift: true along with the eci and cavvthe network needs. From that point, a fraudulent-transaction chargeback is the issuer’s liability rather than yours.

{
  "threeDS": {
    "status": "AUTHENTICATED",
    "eci": "05",
    "liabilityShift": true,
    "directoryServer": "visa",
    "dsTransactionId": "ds_9c2a…"
  }
}

Results are server-verified

The challenge happens in the customer’s browser, but the result is not taken from the browser. kepa records the outcome only from the directory server’s signed response, so a client that posts a forged “authenticated” result is rejected. When 3-D Secure is required but the directory is unreachable, kepa fails closed: the payment is not authorized unauthenticated.

◆You don't hold authentication data

The eci, cavv, and directory identifiers stay inside kepa and travel with the authorization. There’s nothing sensitive for you to store or forward.

When it triggers

kepa’s risk engine decides before authorization, and returns a REQUIRE_3DS decision when the order warrants it — the billing country requires a challenge, the amount crosses a threshold, the card has repeated failed attempts, or you forced 3-D Secure for that order. Low-value, low-risk payments are often exempted and authenticate frictionlessly. The friction only appears when the risk justifies it.

iCard on file

A saved card authenticated once doesn’t re-challenge on later merchant-initiated charges — the initial authentication and mandate carry the subsequent payments. See charging a saved method.