| Environment | Base URL |
|---|---|
| Sandbox | https://secure.epxuap.com |
Overview
The North payment platform along with our in-house processor, EPX, allows merchants to validate cardholder information using Visa's Account Name Inquiry (ANI) service.
This verification is typically performed before submitting authorization or full financial requests for card-not-present transactions. The resulting name match information provides a more robust and enhanced account verification solution, supporting a layered approach to risk and fraud mitigation.
Use Cases
| Use Case | Description |
|---|---|
| Online Marketplace Verification | Validate user identity pre-transaction to secure transactions and reduce fraud. |
| Digital Wallet Payment Method Addition | Confirm user info when adding a new payment method to a digital wallet to prevent unauthorized pulls. |
| Loan Funding | Check the cardholder name before pushing funds to a customer's card. |
| Push-to-Card Workflow Addition | Validate user names when adding a card to an account holding funds to prevent unauthorized push payments. |
Implementation Details
API Info:
Account Name Inquiry is part of our full-featured Server Post API. Start by exploring the Server Post API guides, download the Postman collection, and explore the supplemental resources.Transaction Type:
The Server Post API transaction type (TRAN_TYPE) for Account Name Inquiry is SS0A.Essential Request Fields:
Cardholder Name information is supplied using the "TLV_SETS" request field, and the validation result is returned in "AUTH_TLV_SETS" field.Documentation:
For further details on request and response tags, please refer to the EPX Data Dictionary.
TLV Format and Elements
The Visa cardholder account name data must be presented in Tag-Length-Value (TLV) format. This method encodes multiple pieces of information into a single string rather than using multiple individual EPX tags.
TLV_SETS Tag Structure
Each request must include the TLV_SETS tag, which can contain multiple concatenated TLV sets.
- Maximum Length: 4,000 bytes.
- Logical Format: set_length TLVset1, TLVset2... TLVsetN.
- Required Set: For ANI transactions, the
TLV_SETStag must always include the ACCT_NAME_INQ set.
TLV Element Components
A TLV set consists of two or more elements, each containing three sub-elements:
- Tag (3 digits): Identifies the type of data (e.g., 002 for First Name).
- Length (3 digits): The byte count of the value following it.
- Value (Variable): The actual alphanumeric data.
ACCT_NAME_INQ Request Data
Example:
The following TLV tags are used within the ACCT_NAME_INQ set for request data. Data must be valid (not all spaces or zeros) to avoid rejection.
| TLV Tag | Data Element | Variable Type | Max Length | Requirement | Additional Details |
|---|---|---|---|---|---|
| 000 | DATA_SET | alpha | 8 | Mandatory | Must be 'ACCT_NAME_INQ' |
| 001 | Owner Type | 'P' or 'S' | 1 | Optional | P=Primary; S=Secondary |
| 002 | First Name | alphanumeric | 20 | Mandatory | Upper case, no special characters |
| 003 | Middle Name | alphanumeric | 20 | Optional | Upper case, no special characters |
| 004 | Last Name | alphanumeric | 20 | Mandatory | Upper case, no special characters |
ACCT_NAME_INQ Response Data
Example:
Validation results from the Visa ANI service are returned in the AUTH_TLV_SETS response tag.
| TLV Tag | Data Element | Response Code Values |
|---|---|---|
| 000 | DATA_SET | 00=Match performed; 01=Not performed; 02=Not supported |
| 050 | Account Name Result | 01=Match; 50=Partial match; 99=No Match |
| 051 | Full Name Match | 01=Match; 50=Partial match; 99=No Match |
| 052 | First Name Match | 01=Match; 50=Partial match; 99=No Match |
| 053 | Middle Name Match | 01=Match; 50=Partial match; 99=No Match |
| 054 | Last Name Match | 01=Match; 50=Partial match; 99=No Match |
HTTPS POST Request Sample
Data is formatted utilizing the key-value pair or x-www-form-urlencoded format and sent via a POST request to the Server Post API over the standard HTTPS port, 443. Responses are received in XML format.
Response Sample
Request Fields
| Field Name | Description |
|---|---|
| CUST_NBR / MERCH_NBR / DBA_NBR / TERMINAL_NBR | The 4-part key represents the four merchant account credentials, and is often provided to you as one value in {CUST_NBR} - {MERCH_NBR} - {DBA_NBR} - {TERMINAL_NBR} format. |
| TRAN_TYPE | Transaction type for ANI is SS0A |
| TLV_SETS | Used to submit TLV data, in ANI case it’s the cardholder name. |
| CARD_ENT_METH | Indicates how the card number was entered for the transaction. Refer to the 'CARD_ENT_METH' section of the EPX Data Dictionary for a complete list of Card Entry Method codes. |
| BATCH_ID | The BATCH_ID field contains a unique number created by the operator to identify a batch of transactions. We suggest using the current date in YYYYMMDD format. |
| TRAN_NBR | A numeric value, used to identify the transaction. This should be unique for each transaction in a batch. |
| ACCOUNT_NBR | The card account number to be acted upon during the transaction. |
| EXP_DATE | Card expiration date in YYMM format. |
| CVV2 | Used for CVC (Card Verification Code) or CVV (Card Verification Value) |
Response Validation
To determine if a transaction was successful, check the AUTH_RESP value. A positive result is indicated by codes 00 or 85; all other codes signify a failure. A comprehensive list of EPX response codes is available in the EPX Data Dictionary.
Specifically for the ANI scenario, after verifying the AUTH_RESP, the next step is to analyze the AUTH_TLV_SETS.
Testing Triggers
The following data can be used in the EPX UAP/Sandbox environment to trigger responses. This exact data will return full matches. Changing the values or omitting certain TLV tags will trigger the various response code mismatches.
| ACCOUNT_NBR | EXP DATE | FIRST NAME | MIDDLE NAME | LAST NAME |
|---|---|---|---|---|
| 4000000000002602 | 12/49 | FIRST | MIDDLE | LAST |
| 4000000000002701 | 12/49 | FIRST | MIDDLE | LAST |
| 4000000000002800 | 12/49 | FIRST | MIDDLE | LAST |
BRIC / Card Token
BRIC tokens are used within the EPX platform to link subsequent transactions (e.g., reporting, chargebacks, recurring sales, refunds) to an original transaction without the need to store sensitive credit or debit card information, thereby mitigating risk and reducing PCI compliance burden.
The BRIC returned by the Account Name Inquiry (ANI) call is a temporary token, valid for 13 months. For merchants requiring a permanent card token for ongoing use, a follow-up BRIC Storage call must be performed to obtain an indefinite token value.
The BRIC is returned in the AUTH_GUID response field and can be used as ORIG_AUTH_GUID request field in follow-up transaction requests.
Example:
Refer to the EPX Data Dictionary or Server Post API Guide for additional specifications.
Subsequent Transactions
After a successful Account Name Inquiry (ANI), the same card data or the temporary BRIC token received in the response can be used for the subsequent transaction types listed below:
- CCE0 - Sale (Authorization & Capture transaction)
- CCE2 - Authorization only
- CCE8 - BRIC Storage
- SM0G - VMT Account Funding Transaction (AFT)
- SM0H - VMT Original Credit Transaction (OCT)
- SM0G - SMS Funding Transaction
- SM0K - SMS Payment Transaction