Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

BIN Detection is a feature of our Cardinal Consumer Authentication product and is supported by our Cardinal Cruise Standard and Cardinal Cruise Hybrid integration methods.

BIN Detection facilitates the running of the 3DS Method in EMV 3DS, allowing for

additional device data to be collected by the

Issuing Bank (or it's ACS provider

to improve the overall authentication experience. This device data is collected prior to the CCA transaction being started and is used during the Issuer's risk assessment of the transaction. Failure to run BIN Detection may result in higher step up rates and/or downgrades to 3DS 1.0.2. This event will need to

) to collect rich data during the checkout process, prior to the authentication request. This additional device data improves the overall authentication experience. It can positively impact authentication success rates, increase the opportunity for frictionless authentication, and reduce customer abandonment.

Per EMVCo specifications, Method URL is mandatory for a merchant to run when provided by the issuer. Therefore, BIN Detection must occur before the Cardinal.start event of the Cardinal Cruise Standard flow or prior to

the

the cmpi_lookup

request

 request in the Cardinal Cruise Hybrid flow.

Info
In an event where Method URL exists,

Device Data Collection (DDC)

may take up to 10 seconds to complete. In such cases, we recommend an interval of 10 seconds between the BIN Detection response and cmpi_lookup request (Cardinal Cruise Hybrid) or, Cardinal.start event (Cardinal Cruise Standard) to allow successful completion of DDC.

is one of the most important steps of an EMV 3DS integration. Failure to integrate this step correctly can have significant impact on authentication performance.

Cardinal has several technical documents that provide merchants with best practices related to DDC so that our partners can achieve best possible results. It is highly recommended to contact your Cardinal representative for these materials.


Table of Contents

Prerequisites

To support BIN Detection, you must complete a full integration of Cardinal Consumer Authentication.  

Implementation Styles

The Cardinal Cruise integration supports multiple ways to add BIN Detection to your web application. You may choose which ever method fits best into your own work flow.

Style 1 - Field Decorator

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 as seen below:

Info

This style will handle all the heavy lifting for you. You do not need to do any additional work beyond identifying which field is the AccountNumber field.


Code Block
languagejs
titleStyle 1 Example
linenumberstrue
<input type="text" data-cardinal-field="AccountNumber" id="creditCardNumber" name="creditCardNumber" />

This will attach an event listener to the element that will update the bin as the consumer types it in. The BIN value will update automatically if they change cards or need to correct an entry.

Style 2 - Event Based 

A. Event Based - bin.process

The bin.process event is the recommended event base profiling which allows Cardinal’s recommended BIN Detection implementation. It provides the merchant, or integrator, the greatest flexibility to initiate the device profiling wherever profiling wherever they prefer is the best point in their purchase flow. It is best practice to initiate profiling.  The merchant will need to bin.process immediately upon receiving the customer’s card number. Whenever possible, provide a minimum of the first 9 (e.g. BIN) up to the full card number of the consumer (e.g. max of 19 digits).  The more digits of the card number provided the better chances of matching if there is a corresponding EMV 3DS 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.

Note
titlePlease be aware

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.

Be sure that bin profiling

 It is important that BIN Detection is completed on the final card

number that is eventually used to checkout with.If less than 9 digits is provided to this event, the event will be resolved successfully, but no profiling will actually take place.

used for the purchase.

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


Code Block
languagejs
titleStyle 2 Example
linenumberstrue
Cardinal.trigger("bin.process", '1234567894561237');


Info
titleLooking for more details?

Checkout the 'bin.process' documentation for more information on this event.

B. Event Based - accountNumber.update

The accountNumber.update event allows the merchant or integrator to initiate the device profiling when there is an update to the account number that will be used to make the purchase. The merchant will need to provide the full account number between the standard credit card number range of 13-19 digits.   Whenever possible, provide a minimum of the first 9 BIN digits of the customer’s card number on accountNumber.update.

For example, in a card-on-file use case, the accountNumber.update could be called when the card number that is being used to make the purchase changes.  This allows the merchant to collect the credit card number themselves, then only call this event when there is an update to this value.  When the accountNumber.update event is called, Songbird will update the in memory cached order object to include the new card number.  

Note
titlePlease be aware

Pushing changes after Initiating accountNumber.update after Cardinal.start  (Cardinal Cruise Standard) or the   cmpi_lookup  has been completed request (Cardinal Cruise Hybrid) will not have any effect on authentication. Please make sure that you have the finalized card number before using BIN Detection.

It is important that BIN Detection is completed on the final card used for the purchase prior to Cardinal.start   or   cmpi_lookup.If less than 9 digits is provided to this event, the event will be resolved successfully, but no profiling will actually take place. The event will resolve when bin profiling was successful or failed with a JSON object describing the outcome.


Code Block
languagejs
titleStyle 2 Example
linenumberstrue
Cardinal.trigger("accountNumber.update", '123456789');


Info
titleLooking for more details?

Checkout the 'accountNumber.update' documentation for more information on this event.

Style 3 - Configuration Based

If you already have the credit card number and just need to pass it to Cardinal, you can pass it within an order object as part of the setup object passed in on Cardinal.setup. You can only pass the card number once using this methodology, making it ideal in a flow where the consumer has already entered their payment information. If you do need to update the BIN value, you can pair this implementation with the event based implementation to push updated BINs to Cardinal.


Info

This style will be triggered as soon as the Cardinal.setup code is executed, which in most cases is on page load. If you do not have the bin value at this point, try the event based approach instead.


Code Block
languagejs
titleStyle 3 Example
linenumberstrue
var orderObject = {
  Consumer: {
    Account: {
      AccountNumber: '1234567894561237' 
    }
  }
};

Cardinal.setup('init', {
  jwt: 'ey...',
  order: orderObject
});