OP1 - Message consistency or generic error

OP1 can appear for generic errors in stateless authorizations, such as when the HSM (Hardware Security Module) is unavailable, unexpected content in messages, invalid fields, or any unforeseen/platform-mapped error.

FR5 - Transaction made in Brazil with magnetic stripe

When the currency code is 986 - BRL, and the Track 1 or Track 2 data are present in the authorization message body without the chip data, this message is handled as a magnetic stripe and is denied.

At this point, the expiration date, service code, and CVV/CVC are not validated.

At the EMV POS (Europay, Mastercard, and Visa point-of-sale) entry mode, this denial happens before FRE, which is often used to deal with this specific situation.

FR1 and FR2 - CVV/CVC validation

If CVV/CVC1 is present in the authorization message body, a validation by the HSM is necessary using the following data: cryptographic key, primary account number, service code, and expiration date. If an error occurs in this HSM validation, the platform returns denial code FR1. However, if CVV/CVC2 is present, the same thing happens, except that FR2 is returned in case of error.

The CVV/CVC 1 or 2 validation is skipped in the following scenarios:

• Tokenized transactions with a safe authentication flag like MDES or VTS (Apple Pay, Samsung Pay, etc.).
• The emitter allowed no-CVM transactions.
• Recurring billing with 3DS authentication (SLI - 210), like Netflix or Spotify.
• Pre-authorization with 3DS authorization (SLI - 210).
• E-commerce authorizations.

FR3 - IAV - intelligent account validation

FR3 refers to an error message that may be displayed while processing a transaction with a card. The code indicates that the transaction was denied because the previously provided authorization number for the original transaction is invalid or does not match the expected authorization number.

This can occur for a number of reasons, including entering the authorization number incorrectly or attempting to use a previously invalid or expired authorization number

CED - Invalid expiration date provided

If a purchase has a verification method, such as CVV, password, or chip, it's necessary to verify it using the HSM. If the provided expiration date is invalid inside the HSM, check to see if the transaction is denied. This is a stateless validation, so a further validation to check the values in the database is made: VNM - Expired card.

FRH - POS (point-of-sale) entry mode validation

Denial list for terminal capability validation (POS or input device) and entry mode. This validation checks how the card data was acquired (card machine, online purchase, NFC, etc.) and the entry mode information. For example, in e-commerce, it’s not possible to retrieve the card chip data, so it’s not a valid entry mode and should be denied. For Visa, entry mode is in Field 60. For Mastercard, it's in DE 61.

The following combinations should be denied according to this specification:

Visa

0 - Unknown

91 - Contactless device-read-originated using magnetic stripe data rules

1 - Terminal not used

02 - Magnetic stripe read. CVV checking might not be possible.

03 - Optical code

04 - Reserved for future use

05 - Contact integrated circuit card read using VSDC chip data rules

06 - Reserved for future use

07 - Contactless device-read-originated using qVSDC chip data rules

90 - Magnetic stripe read and exact content of Track 1 or Track 2 included (CVV check possible)

91 - Contactless device-read-originated using magnetic stripe data rules

95 - Integrated circuit card read. CVV or iCVV checking might not be possible.

2 - Magnetic stripe read capability

03 - Optical code

04 - Reserved for future use

05 - Contact integrated circuit card read using VSDC chip data rules

06 - Reserved for future use

07 - Contactless device-read-originated using qVSDC chip data rules

91 - Contactless device-read-originated using magnetic stripe data rules

95 - Integrated circuit card read. CVV or iCVV checking might not be possible.

3 - Barcode read capability

02 - Magnetic stripe read. CVV checking might not be possible.

04 - Reserved for future use

05 - Contact integrated circuit card read using VSDC chip data rules

06 - Reserved for future use

07 - Contactless device-read-originated using qVSDC chip data rules

90 - Magnetic stripe read and exact content of Track 1 or Track 2 included (CVV check possible)

91 - Contactless device-read-originated using magnetic stripe data rules

95 - Integrated circuit card read. CVV or iCVV checking might not be possible.

4 - OCR-read capability

02 - Magnetic stripe read. CVV checking might not be possible.

03 - Optical code

05 - Contact integrated circuit card read using VSDC chip data rules

06 - Reserved for future use

07 - Contactless device-read-originated using qVSDC chip data rules

90 - Magnetic stripe read and exact content of Track 1 or Track 2 included (CVV check possible)

91 - Contactless device-read-originated using magnetic stripe data rules

95 - Integrated circuit card read. CVV or iCVV checking might not be possible.

5 - Chip-readable capability

03 - Optical code

04 - Reserved for future use

91 - Contactless device-read-originated using magnetic stripe data rules

95 - Integrated circuit card read. CVV or iCVV checking might not be possible.

8 - Proximity-read-capable terminal

02 - Magnetic stripe read. CVV checking might not be possible.

03 - Optical code

04 - Reserved for future use

05 - Contact integrated circuit card read using VSDC chip data rules

91 - Contactless device-read-originated using magnetic stripe data rules

95 - Integrated circuit card read. CVV or iCVV checking might not be possible.

9 - Terminal does not have the capability to read cards data

02 - Magnetic stripe read. CVV checking might not be possible.

03 - Optical code

04 - Reserved for future use

05 - Contact integrated circuit card read using VSDC chip data rules

06 - Reserved for future use

07 - Contactless device-read-originated using qVSDC chip data rules

90 - Magnetic stripe read and exact content of Track 1 or Track 2 included (CVV check possible)

91 - Contactless device-read-originated using magnetic stripe data rules

95 - Integrated circuit card read. CVV or iCVV checking might not be possible.

Mastercard

0 - Input capability unknown or unspecified

91 - Contactless magnetic stripe

1 - No terminal used (voice/ARU authorization)

02 - Magnetic stripe - not qualified

03 - Bar code reader

04 - OCR

05 - Chip

07 - Contactless magnetic stripe / chip

09 - PAN entry via eCommerce, including remote chip

79 - Chip --> Manual

80 - Chip --> Magnetic stripe

82 - PAN auto entry via server (issuer, acquirer, or third party)

90 - Magnetic sripe - full data

91 - Contactless magnetic stripe

95 - Visa Only - Chip with unreliable CVV

2 - Supports magnetic stripe input only

03 - Bar code reader

04 - OCR

05 - Chip

07 - Contactless magnetic stripe / chip

09 - PAN entry via eCommerce, including remote chip

82 - PAN auto entry via server (issuer, acquirer, or third party)

91 - Contactless magnetic stripe

95 - Visa only - Chip with unreliable CVV

3 - Supports contactless EMV input

91 - Contactless magnetic stripe

95 - Visa only - Chip with unreliable CVV

4 - Contactless magnetic stripe (proximity chip)

03 - Bar code reader

91 - Contactless magnetic stripe

95 - Visa only - Chip with unreliable CVV

5 - Supports EMV contact chip input and magnetic stripe input

03 - Bar code reader

04 - OCR

91 - Contactless magnetic stripe

95 - Visa only - Chip with unreliable CVV

6 - Supports key entry input only

02 - Magnetic stripe - not qualified

03 - Bar code reader

04 - OCR

05 - Chip

07 - Contactless magnetic stripe / chip

79 - Chip --> Manual

80 - Chip --> Magnetic stripe

90 - Magnetic stripe - full data

91 - Contactless magnetic stripe

95 - Visa only - Chip with unreliable CVV

7 - Supports magnetic stripe input and key entry input

03 - Bar code reader

04 - OCR

05 - Chip

07 - Contactless magnetic stripe / chip

91 - Contactless magnetic stripe

95 - Visa only - Chip with unreliable CVV

8 - Supports EMV contact chip input, magnetic stripe input, and key entry input

03 - Bar code reader

04 - OCR

07 - Contactless magnetic stripe / chip

91 - Contactless magnetic stripe

9 - Supports EMV contact chip input only

02 - Magnetic stripe - not qualified

03 - Bar code reader

04 - OCR

07 - Contactless magnetic stripe / chip

79 - Chip --> Manual

80 - Chip --> Magnetic stripe

90 - Magnetic stripe - full data

91 - Contactless magnetic stripe

95 - Visa Only - Chip with unreliable CVV

FRE - Cryptogram data validation

There are two possible scenarios for this denial code:

• Missing cryptogram in EMV chip authorizations
• Cryptogram was sent out of context

The first scenario happens when the POS entry mode is 05 (chip) or 07 (contactless) from a physical card (i.e., not a tokenized transaction) without the cryptogram. It’s possible that FR5 occurs in this case due to a validation conflict.

The second scenario occurs when a cryptogram is retrieved from a message, but the entry mode is neither 05 (chip) nor 07 (contactless).

FRN - Chip field validation

Validation of the chip cryptogram. When the field DE55 is present in the authorization message body, it’s necessary to recalculate the chip cryptogram from the following tags and chip keys:

The calculated response is compared to tag 9F26 - Application Cryptogram, which contains the cryptogram generated by the card. If the values are identical, you should send back the ARPC - Application Response Cryptogram (tag 91) so that it can be verified that the transaction was authorized by a trusted comparison method. However, if the values are different, the transaction is denied. The tags C0 - Secondary PIN Block and 91 - Issuer Authentication Data are not used in this validation.

Also, for Visa transactions, the transaction amount and country code are checked against the values present in the DE55 field (chip data).

FRO - Chip signature validation

Check the cardholder verification type used by POS at byte 1 of tag 9F34. If it is a deprecated value (1F - No CVM required, 1E or 5E - Signature), then the transaction is denied after the first CVM fails.

FR6 - Password validation

If the password is present, it is validated by the HSM against the password in the database. If it does not match, the transaction is denied. When the cardholder enters an invalid password, denial code FR6 is returned.

998 - Card hash not present in the database

There is an encrypted database that associates a hash with a primary account number. If no card is retrieved using the given hash, or if more than one card is retrieved, the transaction is denied.

For a tokenized card, if its status is not active, the transaction is also denied.

FR7 - Card not present in database

Besides the encrypted database, there is a PCI database with card data. If the card is not present in this database, the transaction is denied.

ANF - Acceptance not found

Check to see if the first two positions of sub field Transaction Type from Processing Code (DE3) present at the authorization message body are in internal program parameters. Each Transaction Type domain is an acceptance. If a domain isn’t parameterized, the transaction is denied.

Currently the processing codes 11 - Quasi-Cash Transaction, 39 - Eligibility Inquiry, 40 - Cardholder Account Transfer, 70 - PIN Change, and 72 - PIN Unblock are not mapped.

IAT - Invalid account transaction

Compares the field Account Type content of the Processing Code (DE3) sent in the authorization message body with the given card type. If the authorization mode (credit or debit) isn’t allowed for this card, the transaction is denied. For example, a credit card transaction with Account Type 20 (debit) is denied.

CMD - Card mode disabled

Scenarios in which the card mode is invalid or not registered (very unlikely). This can happen with combo cards that don't have the DEBIT or CREDIT mode specified or if the card is pure credit and doesn’t have the specified credit mode. The same happens for a pure debit card when it doesn’t have the debit mode specified.

VEV - Expired virtual card

Temporary cards are created with their expiration date set to their creation date plus one day. If a transaction occurs after the expiration date, the transaction is denied. So far, this applies only for the TEMPORARY card type, which is the only one that has this value set.

VNM - Expired card

For transactions which don’t have verification methods (CVV, password, chip), like recurring billings or purchases with a safe flag, this code indicates that the card is expired, based on the printed date on the card (which also is present in the database). This validation is made in two different scenarios:

• Transactions which have verification methods (CVV, password, chip) – In this case, the validation is made by the HSM.
• CED – Invalid expiration date provided.

CTE - Transaction counter exceeded

📘

Internationalization in progress

Work to internationalize the Pismo platform is ongoing. Some parameter names, such as LIMITE TRANSACOES CARTAO TEMPORARIO, are still in the original Portuguese.

Applies only for virtual cards. These cards have a transaction counter. When the count exceeds the value set in the program parameter LIMITE TRANSACOES CARTAO TEMPORARIO, the transaction is denied.

CND - Account blocked

Three parameters are checked for a transaction:

• AuthorizationStatus – Indicates if an account is allowed to operate.
• CreditStatus – Indicates if an account can receive a credit.
• DebitStatus – Indicates if an account can receive a debit.

If any of these conditions are invalid for the authorization in question, the transaction is denied. In other words, this can be applied for either a fully blocked account or an operation (credit or debit).

TSM - Password tries exceeded

📘

Internationalization in progress

Work to internationalize the Pismo platform is ongoing. Some parameter names, such as TENTATIVAS SENHA ERRADA, are still in the original Portuguese.

The program parameter TENTATIVAS SENHA ERRADA specifies the maximum number of tries the user is allowed when entering their password. When the password is present in the authorization message body, and the number of tries exceeds the value in TENTATIVAS SENHA ERRADA, the transaction is denied.

📘

When the correct password is entered before the limit is exceeded , the counter is reset to 0. However, when the limit is exceeded, the card is blocked.

For further information about the password tries reset endpoint, see Get OpenID access token.

FAT - ATC validation

The chip card application maintains an Application Transaction Counter (ATC) for security. (Since it runs locally on the chip, it qualifies as a fat application.) The ATC is incremented when the physical card is used to make a purchase.

ATC validation is performed to make the platform safe from fraud attempts such as cloned cards. A duplicated ATC or an unusual jump in its value could be a fraud warning sign.

Duplicated ATC

The platform compares a provided ATC value with a list of values from previous authorizations. This list can store around 2000 previous ATC values. If a duplicate is found, the authorization is denied.

ATC minimum offset

The parameter ATC MIN OFFSET represents the minimum allowed difference between the provided ATC value and the last ATC value. If the provided ATC value minus the last ATC value is less than ATC MIN OFFSET, the platform treats the event as a replay attack and the authorization is denied.

ATC maximum offset

The parameter ATC MAX OFFSET represents the maximum allowed difference between the provided ATC value and the last ATC value. If the provided ATC value minus the last ATC value is greater than ATC MAX OFFSET, this indicates unusual behavior. It's not necessarily a replay attack, but it suggests that the chip data was captured for a future attack.

For information about how to reset an ATC list, see Reset card ATC.

DCM - Original authorization not found at refund

When a refund transaction (MTI 0400 or 0420) is received, the original authorization must be retrieved from the database before proceeding. If the original authorization is not found, the transaction is declined.

810 - Available limit validation

If the balance or withdrawal limits are insufficient to complete a transaction, the Pismo platform denies the transaction. For insufficient balance, the response code is 51. For insufficient withdrawal limit, the denial code is 61.

LUT - Ledger timeout

If a timeout in the Ledger API service prevents the platform from completing a transaction, the Pismo platform denies the transaction.

LUE - Error on update Ledger

Any error that occurs in the Ledger API service that is not a timeout is denied with this code.

PFT - Denied by anti-fraud

This response indicates that an anti-fraud mechanism denied the transaction. In some cases, such as a referral, a different response might override this one. (A referral is a specific designation of fraud used by some Brazilian clients. This kind of response is regarded as more serious than a simple “fraud” response.)

FL6 - Card blocked by anti-fraud

When the anti-fraud mechanism flags a transaction as a referral (which is a specific designation of fraud used by some Brazilian clients), the card is blocked and the Pismo platform denies the transaction with this code.

MPC - Program config not found

This error occurs if the authorization platform doesn't have a valid program configuration. You need to contact a Pismo representative to fix the configuration.

RED - Operation not allowed by rules / Rules do not honor / Rules internal error

This error occurs when flexible transaction control validation fails. It can be the result of a 400 - Bad Request, a 500 - Internal Error, or an error in communication between the authorization system and the API flex controls.

In the case of a 400 - Bad Request, the authorization system could be sending an invalid field or value in the request payload.

In other cases, there is an error in the processing. If there is a single error, a retry could be enough to fix the problem. If there are multiple errors, there could be a bug in the flow.

The application of API rules can sometimes result in a transaction being denied and an error with code RED being generated.

LUD - Limit update duplicated ID error

This error occurs when there is a duplicate call. This would change the customer's balance twice for the same purchase, so the transaction is denied.

RAE - Error calling API-Rates

This code indicates an error in the communication with the Rates API service during the authorization amount calculation. This error can be a result of a 400 - Bad Request response, a 500 - Internal Error response, or an error in the communication between the authorization system and the API-Rates service. In the Bad Request scenario, the authorization system could be sending an invalid field or value in the request payload. In other scenarios, there could be an error in the processing. If it is a single error, a retry might be enough to fix the problem. Multiple errors might indicate a bug in the flow.

RAD - Rates API denial

Occurs when a transaction is denied by some logical error in Rates API. This error is the result of a 422 - Unprocessable Entity.

LCT - Ledger account timeout

During transaction flow, the Ledger API is called to get a list of account limits. If the request times out, the transaction is denied.

LNF - Account not found

If a communication error occurs when authorization tries to get a list of account limits from the Ledger API, this can result in an LNF error. For example, if the authorization system sends an invalid field or value in the request payload, it generates a 400 - Bad Request error, and the Pismo platform sends an LNF error in response.

LAE - An unexpected error happened while getting the account information

If the authorization system attempts to get a list of the available limits on an account from the Ledger API and a communication error occurs, this can result in an LAE error. For example, if there is a status code 500 - Internal Error from the API, the Pismo platform sends an LAE error in response.

PCT - A timeout occurred in processing code definition

This occurs when there is a communication error between the authorization flow and the processing code API. This can be a 400 - Bad Request, a 500 - Internal Error, or some other error. In the case of a 400 - Bad Request, the authorization system could be sending an invalid field or value in the request payload. In all other cases, there is a processing error, which could indicate a bug in the flow.

PCE - Unexpected error in processing code definition

This could be the result of a timeout in the processing code API.

PGE - Program Config Generic Error

This occurs when the program configuration cannot be retrieved, either because of a communication failure with the API or an internal error.

UBN - NFC disabled

The purchase is denied with code UBN when it is of the contactless type (entry mode 07) and the function is disabled.

ISE - Insufficient statements

If there are installments and interest to be calculated for the transaction, the Pismo platform has to fetch all the statements related to the installments, so it can use the due dates in its calculations. If the number of statements does not match the number of installments, the transaction is denied with code ISE. For example, if the transaction is for 36 installments, but there are only 30 statements created for the account, the transaction is denied.

NCV - Entry mode not allowed with no CVM

By default, the Pismo platform does not allow authorizations without any validation method (CVV, stripe, chip, password) and that is not marked as recurring and secure.

STD - Denied by second authorizer

This error occurs when the second authorizer denies the transaction.

DCE - distributor-api communication error

This error occurs when there is a communication error between the authorization system and the Parser API, or there is a timeout during the stateless validations. This could indicate a problem with the authorization flow. Note that the Parser API has 5 seconds to complete authorization validation. If validation is not completed in time, a DCE error occurs.

ACE - networktransactions-api communication error

This error occurs when there is a communication error or a timeout with the authorization system during the stateful validations. In this case, there could be a problem with the authorization flow.

DCC - DCC transaction not allowed for program

Each program is configured to allow or deny DCC transactions. The default is to allow them.

If a program is configured to deny DCC transactions, any transaction that is of type DCC is denied with code DCC.

DIC - Invalid country for DCC definition

The Pismo platform needs a valid country code to determine if a transaction is a DCC transaction. If there is no valid country code, the platform denies the transaction with code DIC.

DIY - Invalid currency for DCC definition

The Pismo platform needs a valid currency code to determine if a transaction is a DCC transaction. If there is no valid currency code, the platform denies the transaction with code DIY.

PRN - Program not found

If the program associated with a transaction is not found, the transaction is denied with code PRN.

PIC - Program has invalid currency code

If the program has an invalid currency code, the transaction is denied with code PIC.

PRT - A timeout occurred while fetching program

If a timeout occurs while attempting to retrieve the program details, the transaction is denied with code PRT.

PRE - Unexpected error while fetching program

If an unexpected error occurs while attempting to retrieve the program details, the transaction is denied with code PRE.

ZBP - Partial authorization response invalid in Zero Balance Flow

In zero balance flow, it's possible to authorize transactions partially. A response code of "10" signifies that the transaction has been partially approved and the issuer must return the approved amounts. If these amounts are not returned or the amounts are negative, Pismo issues the custom code ZBP.

CV3 - CVC3 not configured

Purchases with entry mode 91 (910, 911, and 912) that are not made via wallet are denied with code CV3, if there is no CVC3 validation configured.

IMF - Invalid message format

If the message recieved from the network has an invalid format, domain, or value, the transaction cannot be processed and is denied with code IMF.

Currently, this validation is only performed for the ELO network.

IMA - Invalid message authentication code

If the message authentication code recieved from the network is invalid, the transaction cannot be processed and is denied.

Currently, this validation is only performed for the RuPay network.

ZBU - Unavailable endpoint, zero balance client webhook returns 503 status code.

If the zero balance client webhook returns status code 503 - Service Unavailable, the transaction is denied with code ZBP.

ZBT - Zero balance client webhook throws timeout exception.

If the zero balance client webhook exceeds the allowed time (2 seconds), it throws a timeout exception, and the transaction is denied with code ZBT.

ZBF - Zero balance client webhook returns 403 status code, forbidden.

If the zero balance client webhook returns status code 403 - Forbidden, the transaction is denied with code ZBF.

ZBA - Zero balance client webhook returns 401 status code, unauthorized.

If the zero balance client webhook returns status code 401 - Unauthorized, the transaction is denied with code ZBA.

ZBE - Zero balance client webhook returns general error

If the zero balance client webhook returns an error status code not covered by one of the other custom codes, the transaction is denied with code ZBE. Example: status code 400, 404 and others.

ETR - Exceed time to reversal

This denial code is specific for ELO. It means that the reversal advice (mti 0420) came 24 hours or more after the persisted authorization. This behavior is not allowed for ELO in reversal advice cases.

HCE - HSM communication error

This occurs when there’s a communication error between our applications and the Hardware Security Module (HSM).

CAV - CAVV 3DS validation result

If CAV was returned in the denial_code field, it is necessary to call the PCI-Cards team (cards).

For a 3DS transaction, it's necessary to do the CAVV validation with the HSM. This validation is only needed when the 3DS transaction/customer uses the CAVV algorithm.

To Elo, those 3DS-related values are found on BIT-122.

GCD - GCD Gift card denial

This code is returned when a gift card transaction is denied.

It was necessary to create a new denial code to be used in an ELO response when the transaction kind is a gift card. In this case, the Elo network does not allow this kind of transaction, but this type of block can be done by the client. When GCD appears in the answer, the response code is 57.

CGE - Card generic error

When the authorization got a error (invalid response code) trying to retrieve the card data, in this case the network should will be notified that we have an internal error and in some cases an advice will be generated for this authorization.

CET - Card timeout

When the authorization got a error (timeout reached) while trying to retrieve the card data, in this case the network should will be notified that we have an internal error and in some cases an advice will be generated for this authorization.

Z30 - Token found, but does not match card

The token and card were found but they are not related to each other, in other words the PAN given by network is not related with the token.

CNU - Account status unknown

Indicates if account status is unknown, then it is not allowed to operate, just only NORMAL account status is valid. It’s a domain from Accounts team and we validate in the online authorization time.

CNC - Account cancelled

Indicates if an account is cancelled, then it is not allowed to operate. It’s a domain from Accounts team and we validate in the online authorization time.

Card status validation

A card's status determines whether the card can be used. For statuses NORMAL and REISSUED, all transactions are approved. The CREATED status is only approved for tokenized transactions from digital wallets. This provides the cardless experience, which enables a customer to use their card before the physical one arrives. For all other statuses, transactions are denied.

The following table shows the card statuses that are associated with denial codes: