3DS Decisioning by Lithic

For customers who prefer simpler implementations, Lithic can decision on 3DS authentications on your behalf. Lithic’s goal is to decline the riskiest 3DS authentications based on network-provided signals. No real-time response is required from you in order to handle responding to these authentication requests, and no customization of the rules is supported at this time.

Summary of the flow of information:

• 3DS Flow:
  • Cardholder initiates e-commerce transaction at a 3DS-enabled merchant
  • Merchant/acquirer initiates a 3DS authentication request, which routes to Lithic
  • If the card is enabled for 3DS decisioning by Lithic, Lithic runs a set of risk-based rules, and generates a response
  • The 3DS authentication response is routed back from Lithic to the merchant/acquirer; at the same time, Lithic sends a three_ds_authentication.created event webhook via our Events API to the card program
• Authorization Flow (assuming the merchant decides to proceed with the authorization):
  • Merchant/acquirer initiates authorization request, which routes to Lithic
  • Lithic sends an ASA request to the card program, which indicates whether liability has shifted from the merchant to the issuer in the cardholder_authentication object
  • Card program incorporates the liability shift signal into its decisioning logic, and responds to the ASA request
  • The authorization response is routed back from Lithic to the merchant/acquirer

What do I need to do to get started? (more implementation details here)

• Let your Implementation Manager or our Support Team know you want to use 3DS Decisioning by Lithic on your card program
• Subscribe to 3DS authentication events via the Events API
• Start incorporating data included in the ASA request’s cardholder_authentication object into your decisioning

Customer 3DS Decisioning

For customers who prefer more control over 3DS authentication decisions on their card program, a real-time request can be sent to an endpoint that you have configured containing the critical data elements provided in the authentication request. You can then ingest that data and respond with your decision of whether or not to approve the authentication.

Note that the card networks maintain requirements of a minimum percentage of 3DS authentications that must be approved. Any fees associated with a failure to meet these requirements will be passed on from Lithic. Also note that in certain rare cases, such as when Lithic detects a card testing attempt from a merchant, we may decline authentications on your behalf to prevent disclosing the existence of valid PANs. Reach out to your Customer Success Manager for more details.

Summary of the flow of information:

• 3DS Flow:
  • Cardholder initiates e-commerce transaction at a 3DS-enabled merchant
  • Merchant/acquirer initiates a 3DS authentication request, which routes to Lithic
  • If the card is enabled for Customer 3DS decisioning, Lithic sends a real-time request to the card program’s endpoint
  • Card program ingests the data contained in the request, and responds within 1 second
  • The 3DS authentication response is routed back from Lithic to the merchant/acquirer; at the same time, Lithic sends a three_ds_authentication.created event webhook via our Events API to the card program
• Authorization Flow (assuming the merchant decides to proceed with the authorization):
  • Merchant/acquirer initiates authorization request, which routes to Lithic
  • Lithic sends an ASA request to the card program, which indicates whether liability has shifted from the merchant to the issuer in the cardholder_authentication object
  • Card program incorporates the liability shift signal into its decisioning logic, and responds to the ASA request
  • The authorization response is routed back from Lithic to the merchant/acquirer

What do I need to do to get started? (more implementation details here)

• Let your Implementation Manager or our Support Team know you want to use 3DS Decisioning by Lithic on your card program
• Set up and test your 3DS decisioning responder; first in Sandbox, followed by Production
• Subscribe to 3DS authentication events via the Events API
• Start incorporating data included in the ASA request’s cardholder_authentication object into your decisioning

Setting Up a 3DS Decisioning Responder

To use Customer 3DS Decisioning, you’ll first have to set up a responder to which we’ll send 3DS Decisioning Requests. This responder should reply to our requests with a 3DS Decisioning Response.

Create a 3DS decisioning responder

POST https://api.lithic.com/v1/responder_endpoints

For details about enrolling a 3DS Decisioning responder, view our API documentation: Enroll a responder endpoint

Delete a 3DS decisioning responder

DELETE https://api.lithic.com/v1/responder_endpoints

For details about enrolling a 3DS Decisioning responder, view our API documentation: Disenroll a responder endpoint

Get a 3DS decisioning responder

GET https://api.lithic.com/v1/responder_endpoints

For details about enrolling a 3DS Decisioning responder, view our API documentation: Get a responder endpoint

3DS Decisioning HMAC Secrets

3DS decisioning requests use the same HMAC functionality as Lithic's Events API for security. You'll need to sign your responses with your HMAC secret. See the Events API's Verifying Webhooks documentation for more information.

Get 3DS Decision Secret

GET https://api.lithic.com/v1/three_ds_decisioning/secret

For details about enrolling a 3DS Decisioning responder, view our API documentation: Retrieve the 3DS Decisioning HMAC secret key

Rotate 3DS decisioning secret

POST https://api.lithic.com/v1/three_ds_decisioning/secret/rotate

Call the retrieve the 3DS Decisioning HMAC secret key endpoint to get your new secret key.

3DS Decisioning Request

Once you've set up your 3DS decisioning responder, we'll send you a decisioning request for each 3DS authentication with a request body that looks very similar to the 3DS Authentication Object. They are identical except that the 3DS Decisioning Request will not have the authentication_result or decision_made_by fields; these fields will be populated after your endpoint responds to the request and then sent to you in the 3DS Authentication Created Webhook. See the 3DS Authentication Object page for the latest description of each field.

3DS Decisioning Response

Your responder should be set up to respond to Lithic's 3DS Decisioning Request with the below response. It requires a simple approve or decline response.

Sample Response:

{
    "three_ds_authentication_decision": "APPROVE" or "DECLINE" // in future, "CHALLENGE_REQUESTED"
}

Response Guidelines

Note that the allowed response time is 1 second. If we do not receive a 3DS decisioning response from you within that time, we will decision on the 3DS authentication request on your behalf. You will be able to tell that this happened because the ASA request will contain a cardholder_authentication.decision_made_by value of LITHIC_RULES.