Credit Card and Payments Inputs

You can pass information about the payment details and credit card information submitted by the end user or customer for the transaction. The minFraud services accept the following inputs about payments and credit cards:

Unique Tokens

You can pass a unique token that can identify the specific card used in the transaction as an input to the minFraud services. You can use this token to cross-reference minFraud transactions with logs and other data in your own system. It will also be used to enhance risk scoring through velocity checks, as a planned future feature.

The credit card token must not be a primary account number (PAN) or a simple transformation of it.
You can read the full API specification for the credit card token input on our developer portal:

Partial Credit Card Numbers

Two inputs to the minFraud service can accept partial credit card numbers: issuer ID number, and last digits.

Passing this data enhances the risk score returned by the minFraud services based on fraud patterns related to credit cards on the minFraud network, as well as velocity checks on credit cards. Learn more about velocity checks.

In addition, passing these inputs allows minFraud Insights and Factors services to return risk data related to the credit card issuer, and the minFraud Factors service to return a risk factor score keyed to the issuer of the credit card.

Credit Card Number Truncation

The minFraud service supports compliance with PCI standards by processing only the credit card data that is necessary to provide risk scoring and risk data. If you send more credit card data than we need, the minFraud service will issue a warning in its API response, and we will truncate the input.

How much data the minFraud service will accept for the two credit card number inputs depends on:

  • the length of the issuer ID number (IIN) that we detect in the /credit_card/issuer_id_number input
    Note: the length of the IIN we detect in the /credit_card/issuer_id_number input may be different than the length of the input itself. For example, if you send us 8 digits for the /credit_card/issuer_id_number input, we may detect a 6 digit IIN in that input.
  • and the credit card brand that we detect.

See the table below for a description of how many digits each of these inputs can accept, depending on the IIN and credit card brand:

IIN Card Brand Digits Accepted as Input
/credit_card/issuer_id_number /credit_card/last_digits
6 digits Any brand Input truncated to 6 digits. Send 4 digits.
8 digits Any of the following brands:
  • Discover
  • JCB
  • Mastercard
  • UnionPay
  • Visa
Send 8 digits. Send 4 digits.
8 digits Any brand not listed above Send 8 digits. Input truncated to 2 digits.

Issuer ID Number (IIN) or Bank ID Number (BIN)

You can pass the issuer ID number (IIN) of the credit card used for the transaction to the minFraud service. The issuer ID number is sometimes called the bank ID number (BIN), because it identifies the issuer of the credit card, which is usually a bank. The IIN input is one of the recommended high value inputs to pass to the minFraud service when it is available.

The minFraud service can accept 6 or 8 digit IINs, and when possible you should set up your integration to send 6 or 8 digits for this input based on the length of the customer’s IIN. Learn more about how much data to send in the section on credit card number truncation, above.

When you pass the IIN input, you should get the following effect based on the minFraud service that you are using. Click on the links below to learn more about how this input is used to help generate risk scores and risk data:

minFraud Score, Insights, and Factors minFraud Insights and Factors minFraud Factors
  • Risk scoring will be improved.

 

If you are also passing the billing address:

Learn more about the billing address input.

Please note that we will not always return the risk factor scores and risk data above if we do not find the data significant to the risk scoring of your transaction.

You can read the full API specification for the IIN input on our developer portal:

Last Digits

You can pass the last digits of the credit card used for the transaction to the minFraud service. You can pass either 2 or 4 of the last digits of the credit card, depending on the length of the issuer ID number for the credit card. The preferred integration would be to pass to 4 of the last digits for most credit cards, and 2 digits for credit cards of certain brands when they use 8 digit IINs. Learn more about how much data to send in the section on credit card number truncation, above.

When you pass the last digits input, you should get the following effect based on the minFraud service that you are using. Click on the links below to learn more about how this input is used to help generate risk scores and risk data:

minFraud Score, Insights, and Factors

If you are also passing the credit card IIN:

  • Risk scoring will be improved.

Learn more about the credit card IIN input above.

You can read the full API specification for the last digits input on our developer portal:

Card Issuer Country

The card issuer country input is only required if you are not passing the issuer ID number (IIN or BIN) as an input, above. Learn more about the issuer ID number input above.

If your payment processor does not provide you with the issuer ID number (IIN or BIN) associated with the payment card, they may still return the card issuer country to you. If you pass the card issuer country as an input, you will receive a lot of the benefit that you would get from passing the issuer ID number.

You can read the full API specification for the card issuer country input on our developer portal:

Payment Processor Information

You can pass the results of various checks done by your payment process, as well as various information about the payment process used for the transaction, to the minFraud service. The minFraud services can accept the results of AVS, CVV, and 3-D Secure checks as inputs. In addition, the minFraud services can accept the name of your payment processor, whether the transaction was authorized, and the decline code provided by your payment processor.

When available, these inputs help with risk scoring, elevating the risk score for transactions in which various security checks have failed. These inputs are also used to identify patterns of fraud in the transactions specific to your account, and across the minFraud network.

In addition, minFraud Factors users benefit from risk factor scores keyed to the results of your AVS and CVV checks. Learn more about the AVS and CVV risk factor scores.

You can read the full API specification for payment processor inputs on our developer portal:

This page was last updated on .

Was this article helpful?