Account Validation and Verification
Ensure payment to intended recipient.
Before initiating a push payment, or OCT, verify that the recipient's card is valid, active, and eligible to receive funds. The following practices help prevent failed transactions, reduce fraud exposure, and ensure funds reach the right account.
Authorization Checks
Look up key characteristics of the recipient card (e.g., country, card type, block status, etc.) and verify account (e.g., screen for lost, stolen or expired accounts).
- Require Card Verification Value (CVV2) and validate before proceeding
- Use $0 Account Verifications Requests to verify the account is open and in good standing.
Response Codes
The following response codes indicate account validation issues and the recommended action for each.
| Response Code | Description | PAN Eligible for Retry | Best Practices |
|---|---|---|---|
| 05 - Do Not Honor | Generic issuer response for a variety of conditions | Yes |
|
| 14 - Invalid Account Number | Invalid account number | No |
|
| 41 - Pick up Card – Lost | Cardholder reported card lost | No | Account Verification |
| 43 - Pick up Card – Cardholder reported card stolen | Cardholder reported card stolen | No | Account Verification |
| 54 - Expired Card/No Expiry Date | Expired card or expiration date missing | No | Account Verification |
| 57 - Transaction Not Permitted– Restriction at BIN level to block specific transaction type | Restricted BIN | No |
|
| 61 - Over Activity Amount Limit | Exceeds velocity limits | Yes | Avoid resubmitting transactions that may exceed issuer transaction and velocity thresholds that caused the initial decline |
| 62 - Restricted Card | Restricted card | No | Account Verification |
| 65 - Over Activity Count Limit | Exceeds velocity limits | Yes | Avoid resubmitting transactions that may exceed issuer transaction and velocity thresholds that caused the initial decline |
| 91 - Issuer/Switch Inoperative | Issuer host system down for maintenance or connectivity to issuer is lost | Yes | Retry when host or network connectivity is resolved |
Storing and Passing Card Credentials
When disbursing funds to a cardholder, CVV2 and expiration date of the Destination Account receiving card (e.g. Beneficiary) are not required to initiate an OCT. However, depending on your existing controls, CVV2 and expiration date may be necessary to meet card authentication requirements.
Note: Cardholder address requirements may vary similarly depending on your use case(s) and controls.
Effective 1 April 2021, issuers must not decline OCTs solely due to the absence of expiration date or CVV2. If the expiration date is included, it must be accurate and not expired.
From a risk management standpoint it is best practice to validate AVS and CVV2, and require that the cardholder provide an accurate expiration date.
Expiration date and CVV2 are both optional in the Create Account API. You can choose to add accounts with expiration date and CVV2.
PCI StandardsAny client handling sensitive card information is required to meet a specified level of PCI DSS (Payment Card Industry Data Security Standards).
Expiration date and CVV2 are both optional in the Create Transaction API.
- If you send an expiration date and/or CVV2 they will be passed downstream to the network.
- If you stored an account with TabaPay, and it contains expiration date, then the information will be passed down to the network in a domestic OCTs, but not in a cross border OCT.
- When the expiration date and CVV2 are provided, they must be accurate. You can use Query Card API AVS to check if the CVV2 is valid.
- For disbursements, if you are storing cards with TabaPay, enable TabaPay's account updater service to ensure the CVV2 and expiration date stay up to date.