Server-to-Server Payments with 3D Secure

Step 1: (Client-side) Set up your front-end 

Set up your front-end to include the .JS scripts for card encryption and Cardinal Commerce (3DS):

Card encryption: https://cst.jsclient.vficloud.net/verifone.js

3DS:

Throughout the documentation we are using the CST environment. Use the appropriate environment for your account. See more in Getting started.

HTML Example:

<head>   
<script src="https://cst.jsclient.vficloud.net/verifone.js"></script>   
<script src= "https://songbirdstag.cardinalcommerce.com/edge/v1/songbird.js"></script>   
</head>  

Step 2: (Server-side) Collect a JWT Token

API Reference: https://verifone.cloud/api-catalog/3d-secure-api#tag/V2/operation/postV2JwtCreate

Make a Post request using your 3D Secure Contract ID to collect a JWT token. This is used later for initializing the 3D Secure script client side.

Request Method: POST 

URL: https://cst.test-gsc.vfims.com/oidc/3ds-service/v2/jwt/create

Body:

Response:

The JWT will expire after 2 hours and it is a single time use only.

 Pass the JWT token to your front-end for later use.

Step 3: (Client-Side) Initiate your Card Form 

Once you have a JWT token, you should generate your card collection form/page to begin the 3D Secure assessment and allow the customer to enter their credit card details at the same time.

Step 4: (Client-side) Configure the 3D Secure Script

Run the Cardinal.configure() function with your desired configuration options. For example:

Field
Type
Default
Description

timeout

int

8000

The time in milliseconds to wait before a request to Centinel API is considered a timeout.

extendedTimeout

int

extendedTimeout is only used in the event of the first request timing out. This configuration allows the merchant to set the timeout (in milliseconds) for subsequent retry attempts. (This configuration would be useful when the merchant wants to set higher timeout values on requests). If the value for the extendedTimeout is set to less than 4000 milliseconds, then the value will be automatically reset to 4000 milliseconds.

maxRequestRetries

int

1

How many times a request should be retried before giving up as a failure.

Step 5: (Client-side) Setup Event Listeners

payments.setupComplete() 

This listener will run after the payment setup has successfully been completed. SetupCompleteData will contain a session ID to be used for the 3DS lookup. 

payments.validated()

Payments Validated allows you to capture the different outcomes of the flow and handle them accordingly. 

Response Data and Outcome definitions

Type
Description

ActionCode

The resulting state of the transaction. Possible values:

  • SUCCESS - The authentication was successful. Details from the “Payment” Object can be used to perform a payment.

  • NOACTION - The API calls were completed and there is no further actionable items to complete. This can indicate that the card holder is not enrolled in 3D Secure or it could indicate a validation error was encountered. It is recommended that the rest of the response is reviewed to determine what has occurred.

  • FAILURE - The authentication resulted in an error. For example, this would indicate that the user failed authentication or an error was encountered while processing the transaction.

  • ERROR - A service level error was encountered. These are generally reserved for connectivity or API authentication issues. For example, if your JWT was from the wrong environment, or 3DS services are unavailable.

Validated

This value represents whether the authentication was successful or not.

ErrorNumber

Application error number. A non-zero value represents the error encountered while attempting the process the message request.

ErrorDescription

Application error description for the associated error number.

Payment

Payment Object, see below for details.

In the case of a SUCCESS outcome, the details returned from data.Payment.ExtendedData are used for payment in step 12.

Example for SUCCESS outcome:

Step 6: (Client-side) Initialize the 3D Secure Script 

Initialize the 3D Secure Script using the JWT Token generated from step 2.

This will begin the 3D Secure process:

Step 7: (Client-side) Card Number detection

While the customer is entering their card number, use one of the following “BIN detection” methods to positively impact authentication success rates, increase the opportunity for frictionless authentication, and reduce customer abandonment.

This implementation is the simplest and recommended approach and requires the least amount of work to complete. Simply add a new attribute to the input field to identify which field it maps to within the Order Object. The credit card number is mapped to the AccountNumber field, so for bin detection we would pass AccountNumber to the attibute data-cardinal-field.

Example:

Option 2: Event Based

The bin.process event is the recommended BIN Detection implementation. It provides you, or integrator, the greatest flexibility to initiate device profiling wherever they prefer in their purchase flow. It is best practice to initiate bin.process immediately upon receiving the customer’s card number. Whenever possible, provide a minimum of the first 9 BIN digits of the customer’s card number on bin.process. Merchants that provide fewer than the first 9 digits are at risk of running the incorrect issuer Method URL.

Example:

You may have to trigger the bin events more than once if the end user is able to change their card number at the point where Songbird is integrated. Songbird will only profile any given bin a single time, once profiling is completed Songbird will return a success status. It is important that BIN Detection is completed on the final card used for the purchase.

The event will resolve when bin profiling was successful or failed with a JSON object describing the outcome.

Step 8: (Client-side) Collect the sessionId

The sessionId is a unique ID which represents the device profile of the web user. This is used as part of the 3D Secure Authentication process.

If the setup was successful, the event listener in step 4, payments.setupComplete(), will be triggered, and return the session ID. 

Within the response of setupCompleteData, there will be a value called sessionId:

setupCompleteData.sessionId

Returns:

0_6e0fedb-d642-47d1-88e2-b12a59ffe39e 

Step 9: (Client-side) Collect Card Details with Verifone.JS 

Use the Verifone.js script to securely encrypt the card details before transmitting it to Verifone.

Collect your Secure card capture key, and set this to a variable, for example: 

const encryptionKey = '{Secure Card Capture Key}';  

Capture the cardholder details from the front-end and set this up as an object:

 Then call the verifone encryption method, passing in both the cardDetails and encryptionKey as parameters. 

Calling the method:

This method returns a Promise containing the encryptedCard field.

Response:

These are the card details encrypted . Pass this to your back end for processing payments.

Step 10: (Server-side) Perform a 3DS Lookup 

API Reference: https://verifone.cloud/api-catalog/3d-secure-api#tag/V2/operation/postV2Lookup

Make a POST request to Verifone using the encrypted card, device info (sessionId) and other data points to receive the 3D Secure Response.

The device_info_id is the same value as the sessionId returned from step 8.

Request Method: POST

URL: https://cst.test-gsc.vfims.com/oidc/3ds-service/v2/lookup

Body:

Response:

Step 11A: (Server-side) Successful 3D Secure Lookup

If the lookup attempt was successful, and the details provided match the card holder details on record, the field “pares_status” will be “Y”.

You can proceed directly to step 12 to perform a payment using the details from the lookup request.

Step 11B: (Client-side) Pares_status = “C” Continue to the authentication step 

In some cases, a one-time pin or “Step-up” challenge is required to authenticate the customer.

Cardinal.continue will only work after the payments.setupComplete event has been triggered.

Cardinal.continue is suggested to be run later in the flow if payments.setupComplete is not triggered yet.

Example:

This will present the 3D Secure modal window to the customer:

For Sandbox testing, the code will always be 1234 and not sent to a phone number.

After completion of the one-time pin challenge, the 3D Secure plugin will return an outcome from one of the SUCCESS Event Listener setup in step 5, for example:

Understanding the Impact of the different 3D Secure Responses

If "PAResStatus" is one of the following: “Y" – 3DS is Successful “A” – 3DS was Attempted

And “SignatureVerification” is: “Y” - Contents of the message can be trusted

And “enrolled” is: “Y” - Cardholders bank is participating in 3D Secure Process.

This will result in a liability shift off the merchant.

If "PAResStatus” is one of the following: “N” - Failed “U” - Unavailable “R” - Rejected “C” - Challenge required (Temporary status)

Or a blank value

Or “SignatureVerification” is: “N” - Signature verification is invalid

OR “enrolled” is: “N” - Cardholders bank is not participating in 3D Secure “U” - Enrollments status unavailable “B” - Enrollment status was bypassed

The liability of the transaction will remain with the merchant.

This is not a complete guarantee of liability shift. The information presented in this document is based on published Card Associations (Visa, Mastercard, AMEX, ProtectBuy, and JCB) Operating Rules and Regulations, and may be subject to change.

Step 12: (Server-side) Perform a Server-To-Server Payment with 3D Secure 

Using the data from the lookup and if applicable, the step-up challenge response, you may perform a 3D Secure authenticated payment. See the example API request below:

API Reference: https://verifone.cloud/api-catalog/verifone-ecommerce-api#tag/Ecom-Payments

Request method: POST

URL: https://cst.test-gsc.vfims.com/oidc/api/v2/transactions/card

Example API Request:

Response:

Your Server-to-server, 3D Secure Authenticated transaction is now complete.

Additional steps

Refund a transaction

Depending on your supported acquirer and according to the settlement time. A payment can be refunded fully or partially via Verifone Central, or via the eCommerce API using the refund payment API call.

Notification methods

Set up notifications in Verifone Central to receive transaction events via email or webhook URL’s. Leverage notifications to receive transaction results to different systems at the time of payment.

Advanced Payment flow with Preauthorization

To perform a preauthorization, two fields need to be specified in the payment request in Step 12:

  • capture_now : false

  • auth_type : “PRE_AUTH”

Once the Preauth is authorized, it can be captured for settlement, or cancelled (voided) using payment actions through Verifone Central or the eCommerce API.

Adding Tokenization

Set up a token scope in Verifone Central to set up a “Vault” with Verifone to store tokens. Request a token by adding the “Token_preference” object to your API request.

Adding Stored credentials

After setting up Tokenization, use the Stored Credential Framework to send MIT or CIT-approved transactions.

Last updated

Was this helpful?