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 Issuing Bank (or it's ACS provider) 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 cmpi_lookup request in the Cardinal Cruise Hybrid flow.

Device Data Collection (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.

Prerequisites

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

Completed Getting Started
Complete Cardinal Cruise Standard or Cardinal Cruise Hybrid integration

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:

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.

Style 1 Example

<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 Cardinal’s recommended BIN Detection implementation. It provides the merchant, 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.

Please 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. 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.

Style 2 Example

Cardinal.trigger("bin.process", '1234567894561237');

Looking 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. 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.

Please be aware

Initiating accountNumber.update after Cardinal.start (Cardinal Cruise Standard) or the cmpi_lookup request (Cardinal Cruise Hybrid) will not have any effect on 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.

Style 2 Example

Cardinal.trigger("accountNumber.update", '123456789');

Looking 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.

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.

Style 3 Example

var orderObject = {
  Consumer: {
    Account: {
      AccountNumber: '1234567894561237' 
    }
  }
};

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