3-D Secure can help you avoid fraudulent transactions by authenticating transactions before submitting them to the gateway for processing. When a credit card enrolled in 3-D Secure is submitted it will ensure that the customer is the owner of the credit card. Their bank will first collect a fingerprint of their device. On some occasions, this fingerprint is sufficient and the customer is immediately authenticated. This flow is often called “frictionless” because it does not require additional inputs from the user and does not interrupt the customer’s checkout flow. On other occasions, the bank will issue a challenge to the customer requiring them to submit a password or other information to validate themselves. This flow is often called “step up authentication”.Documentation Index
Fetch the complete documentation index at: https://bancofcalifornia-preview.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
3-D Secure Variables
When a customer successfully authenticates a transaction, the library may provide you the following, which you should submit to the payment API:| Variable | Description | When Received |
|---|---|---|
| cavv | Cardholder Authentication Verification Value The value that signifies that a customer was successfully authenticated. | On all successful authentications |
| xid | A transaction identifier from authentication processing | Occasionally provided for some card brands |
| directory_server_id | A transaction identifier assigned by the directory server. | On all successful 3DS2 authentications |
| eci | A number that indicates the result of the attempt to authenticate the cardholder. Values are dependent on the card brand. | On successful authentications |
| cardholder_auth | A string describing if a customer was successfully verified or attempted. “verified” indicates that a cardholder’s bank successfully verified the user. “attempted” indicates that a cardholder is enrolled in 3DS, but their bank does not support 3DS. Examples: verified, attempted | On successful authentications |
| three_ds_version | Determines which version of 3DS was used. Examples: 1.0.2, 2.1.0, 2.2.0 | On all successful authentications |
| cardholder_info* | Text provided by the ACS/Issuer to Cardholder. Example: Additional authentication is needed for this transaction, please contact (Issuer Name) at xxx-xxx-xxxx. | Occasionally provided for frictionless transactions |
Handling in Gateway.js
Using Collect.js or Customer Vault? See “Running 3DS with Collect.js” or “Running 3DS with Customer Vault” guides for information about integrating with other gateway services. example.htmlInitialize Gateway.js
Start by initializing Gateway.js with your public key. You can view your existing public keys
or create a new one in the merchant portal’s
Security Keys.
Create the interface object
Create an interface object with the details of the transaction. The details should include
cardNumber, cardExpMonth, cardExpYear, currency, amount, email, city,
address1, country, firstName, lastName, and postalCode. The created interface will
emit events that your application can subscribe to in order to respond to various results from
processing.Mount the interface to the DOM
Mount the interface to the DOM by providing a selector. The frame will be mounted inside the
provided element. This starts the authentication process.JavaScript frameworks such as React, Vue, or Angular may control the DOM in such a way that
would cause the frame to become detached from the DOM. You may need to prevent them from
managing the mount point in order to ensure that a mounted interface remains on the page.
Attach callbacks
Attach callbacks to listen for when the customer finishes authenticating themselves.
Send the 3DS data to your backend
Implement a callback for the complete event that sends the 3DS data to your backend.