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:
- a unique token that identifies the card used for the transaction in your system,
partial credit card numbers, specifically
- the issuing country of the credit card, as provided by your payment processor,
- and information provided to you by your payment processor.
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
Note: the length of the IIN we detect in the
/credit_card/issuer_id_numberinput may be different than the length of the input itself. For example, if you send us 8 digits for the
/credit_card/issuer_id_numberinput, 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|
|6 digits||Any brand||Input truncated to 6 digits.||Send 4 digits.|
|8 digits||Any of the following brands:
||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|
If you are also passing the billing address:
You can read the full API specification for the IIN input on our developer portal:
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:
You can read the full API specification for the last digits input on our developer portal:
Card Issuer Country
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 .