Scope 

Answers the below questions:

 “If we have 3DS enabled for a gateway, does it mean all the transactions processed via that Gateway are 3DS authorized?“

“Does Chargebee get to decide what cards are to be processed via 3DS?”

“My transaction is stuck or fails in the 3DS auth page, what can Chargebee do about it?”

Summary 

A brief note on where Chargebee stands in a typical 3DS transaction and what it has control over/what it doesn’t.

 We rolled out the 3DS 2.0 on Oct 20th, 2022 and we should be able to support the 3DS 2.0 workflow post that.

Explanation

If a Gateway is 3DS enabled, it will assume all transactions to be 3DS required. But to invoke the 3DS auth, the control is with the Card issuing bank, even the Gateway doesn't have control over it. So if the Gateway gets a REQUIRES CHALLENGE call from the Card issuing Bank (Challenge flow), it invokes the 3DS auth page where either fingerprint or OTP based auth is done to ensure the legitimacy of the transaction.

If the data sent to the bank by the Gateway, by default (i.e user agent info, fingerprint, acc creds, Recaptcha, etc.) is sufficient, 3DS auth is not handled (this should be the default flow for non 3DS configuration and is also known as Frictionless flow for a 3DS scenario).

Once the submit button is clicked on Chargebee Hosted pages, the relevant gateway is picked based on the currency and the smart routing configuration in the Chargebee site and the Gateway’s JS elements are invoked which in-turn checks with the bank whether to proceed with a Challenge flow or Frictionless flow.

Note: This is the overall outline for all 3DS supported Gateways in Chargebee.