Insights and Verification
The Evervault API provides several endpoints that can be used to retrieve additional information for cards and BIN ranges. This can be used for tasks such as fraud detection and payment routing.
- Use the Card Insights endpoint to perform cardholder verification checks and enrichment.
- Use the BIN Lookup endpoint to retrieve metadata for a BIN range.
- Use the PAR Lookup endpoint to retrieve the Payment Account Reference (PAR) for a card number or network token.
Card Insights
Beta
The Card Insights API is currently in Beta for customers on custom plans. Please contact us at support@evervault.com for more information.
The Card Insights API provides a powerful, real-time interface for card and cardholder verification checks and enrichment. It allows you to run:
- Address verification (AVS)
- Cardholder name verification (ANI)
- CVV validation
- Email and phone verification
You can also retrieve BIN information, the Payment Account Reference (PAR), and the push and pull transaction capabilities for disbursements and collections. Checks can run against either a card or a network token. By unifying these inputs, the API provides real-time assessments of card and cardholder authenticity alongside rich card metadata—enabling precise validation and smarter routing, handling, and fraud prevention.
Creating a card insight
You can run Card Insights against either a card (PAN) or a network token. Provide exactly one of card or networkToken per request.
Card Insights is extensible - you choose the insights you need per request. Every response includes BIN data by default. You can add any of the following extensions:
- Address Verification (AVS) – Run AVS to verify postal code and street-level elements (line1, line2, city, state, country) against issuer records.
- Name Verification – Run ANI to verify the provided name (first, last, middle, suffix, and owner type) against issuer records.
- Transaction Capabilities – Determine push and pull transaction eligibility, network, regulatory status, and expected funds-availability windows.
- CVV Validation – Validate the CVV against issuer records. Not available for network tokens.
- Email Verification – Verify the provided email address against issuer records.
- Phone Verification – Verify the provided phone number against issuer records.
- Payment Account Reference (PAR) – Retrieve the Payment Account Reference for the card.
This example requests all possible extensions and includes both required and optional fields. The example response includes all possible fields.
Alternatively, provide a networkToken in place of card:
Extensions and required fields
| Extension | Required Fields |
|---|---|
capabilities | card.number |
address | card.number, card.expiry, address.postalCode |
cardholder |
|
cvv | card.number, card.expiry, card.cvv |
email | card.number, email |
phone | card.number, phone |
paymentAccountReference | card.number |
The cvv extension isn't available for network token lookups. For all other
extensions, replace the card.* requirements above with the equivalent
networkToken.* fields.
Request validation rules
There are some general rules that need to be followed for all strings fields. Failure to follow these will result in an error.
- All string fields must only consist of ASCII characters.
- Consecutive periods (
.) will result in an error.
The following characters are restricted for all string fields:
| Forbidden Character | Description |
|---|---|
\ | Backslash |
^ | Caret |
, | Comma |
" | Double Quotes |
() | Parentheses |
| | Pipe |
; | Semi-Colon |
~ | Tilde |
Card fields:
- The
numbermust be a valid card number (either in plaintext for as an Evervault encrypted string). - The
cvvmust be a valid CVV for the given card brand. - The
monthandyearfor theexpirymust be 2 digit strings.
Transaction fields
- The
amountmust be a number. - The
currencymust be a valid ISO-4217 three digit currency code.
Cardholder fields
firstNameandlastNameare required when thecardholderextension is requested.middleNameandsuffixare optional and refine the name match.ownerTypeis optional and indicates whether the cardholder is the primary (01) or secondary (02) account owner.
For name fields there are additional character restrictions. These are outlined below. Failure to remove these will result in an error.
| Forbidden Name Field Character | Description |
|---|---|
& | Ampersand |
$ | Dollar Sign |
= | Equal Sign |
! | Exclamation Mark |
/ | Forward Slash |
# | Hash / Pound |
% | Percent |
+ | Plus |
? | Question mark |
_ | Underscore |
Email and phone fields:
Email and phone verification aren't widely supported by issuers, so coverage is limited.
- The
emailmust be a valid email address. Required when theemailextension is requested. - The
phonemust be in IDD-prefixed E.164 format: E.164 international format with the00IDD prefix substituted for+(for example0016505551234for a US number). Required when thephoneextension is requested.
Network token fields:
- The
numbermust be a valid network token number (either in plaintext or as an Evervault encrypted string). - The
cryptogrammust be a valid cryptogram (either in plaintext or as an Evervault encrypted string). - The
monthandyearfor theexpirymust be 2 digit strings. transactionIdentifier,brand, andfundingare required for Amex and Discover network tokens.
Address fields
- If no
countryis provided, then it defaults tous. - If the country is
us(United States) then thepostalCodemust be a 5 or 9 digit string. The hyphen must be excluded. - If the country is
ca(Canada) then thepostalCodemust follow the Canadian postal code format (ANA NAN) e.g.A1A 1A1. The space character must be included. - The
statemust be a valid ISO-3166 subdivision code. e.gnyfor New York. - The
countrymust be a valid ISO-3166 two character country code.
BIN Lookup
The BIN Lookup API allows you to retrieve BIN data for a card number or BIN range. You can pass a plaintext card number, an encrypted card number, or the first 6-10 digits of a card number. If the number matches a range of BINs, the response returns metadata that is common to all the BINs in that range. The API key and app ID are required to authenticate the request, and the API key needs the binLookup:create permission.
The response includes the BIN metadata, such as the card brand, the funding type, the country, and other relevant details.
PAR Lookup
Beta
PAR Lookup is in beta for customers on custom plans. Contact Support for more information. Visa, Mastercard, and Discover cards are currently supported.
The PAR Lookup API returns the Payment Account Reference for a card number or network token. A PAR is a stable identifier the card network assigns to a card. Unlike a card number, it stays constant when a card is reissued, renewed, or replaced, and every network token derived from the card resolves to the same PAR.
This makes PAR useful for identifying when a network token and a physical card are the same underlying payment account. You can use the PAR to track a card across reissues, and linking its activity to a single cardholder for fraud detection or lifetime-value analysis.
Card and account identifiers
A PAR identifies a card and its tokens over time, not the underlying bank account or the cardholder. Distinct cards on the same account aren't guaranteed to share a PAR.
To look up a PAR, send a plaintext or Evervault-encrypted card number or network token to the PAR Lookup endpoint. The API key and app ID are required to authenticate the request, and the API key needs the parLookup:create permission.
The response includes the resolved PAR, along with an identifier for the lookup.