Rule list
The rules used by the Pismo platform to validate transactions are listed below. See Authorization validaton rules for general information about how to receive and interpret validation results.
Magnetic stripe validation
The Pismo platform checks that the country where the authorization is taking place allows the entry mode to be Magnetic Stripe. If an authorization request is performed in a country where Magnetic Stripe is not allowed, the authorization is denied by default.
This validation is performed for both zero balance and full balance integration.
Name: MAGNETIC_STRIPE
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
MAGNETIC_STRIPE_VALID | APPROVED | Magnetic Stripe present and validated. | NA | 00 (For all Networks) |
DEBIT_ECOMMERCE_TRANSACTION | SKIPPED | E-commerce debit transactions might have a Magnetic Stripe built-in by the network. Validation is skipped in this scenario. | NA | NA |
NO_MAGNETIC_STRIPE | SKIPPED | No Magnet Stripe in the request, so no need for this validation. | NA | NA |
NO_MAGNETIC_STRIPE_WITH_CRYPTOGRAM | SKIPPED | Request contains cryptogram information, so no need for this validation. | NA | NA |
NO_MAGNETIC_STRIPE_WITH_VALID_CVV2 | SKIPPED | Request contains CVV2 information, so no need for this validation. | NA | NA |
TOKENIZED_TRANSACTION | SKIPPED | Request is tokenized, so no need for this validation. (Visa only) | NA | NA |
COUNTRY_NOT_ALLOW_MAGNETIC_STRIPE | REJECTED | Country doesn’t allow Magnetic Stripe operations, so the authorization request is denied. | FR5 | Visa: 57 Mastercard: 57 Tecban: R9 Rupay: 57 |
Additional data: Not yet mapped
Payload example:
{
"name": "MAGNETIC_STRIPE",
"status": "APPROVED",
"reason": "MAGNETIC_STRIPE_VALID",
"description": "Magnetic stripe valid",
"additional_data": {}
}
ARQC validation
The Pismo platform checks that the information contained in the cryptogram field is valid. It calls the HSM to perform this validation.
This validation is performed for both zero balance and full balance integration.
Name: ARQC
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
ARQC_SIGNATURE_VALID | APPROVED | ARQC information present and valid. | NA | 00 (For all Networks) |
NO_CRYPTOGRAM | SKIPPED | No ARQC information present in request, so no need for this validation. | NA | NA |
INCOMPATIBLE_PROCESSING_CODE | SKIPPED | Request was a credit voucher with no ARQC information, so validation was skipped. | NA | NA |
ARQC_INVALID | REJECTED | HSM declined the transaction, because the cryptogram information was invalid. | FRN | Visa: 63 Mastercard: 63 Tecban: R9 Rupay: E3 |
HSM_COMMUNICATION_ERROR | REJECTED | Internal error while calling the HSM. | FRN | Visa: 63 Mastercard: 63 Tecban: R9 Rupay: E3 |
SHOULD_HAVE_CRYPTOGRAM | REJECTED | Request entry mode is Chip (05), but doesn’t have cryptogram information. | FRN | Visa: 63 Mastercard: 63 Tecban: R9 Rupay: E3 |
SHOULD_NOT_HAVE_CRYPTOGRAM | REJECTED | Request contains cryptogram information, but entry mode is not valid for chip operations. | FRN | Visa: 63 Mastercard: 63 Tecban: R9 Rupay: E3 |
Additional data: Not yet mapped
Payload example:
{
"name": "ARQC",
"status": "APPROVED",
"reason": "ARQC_SIGNATURE_VALID",
"description": "ARQC valid",
"additional_data": {}
}
CVM validation
The Pismo platform checks that the CVV or PIN information contained in the authorization request is valid. If no verification method is present (CVV, Cryptogram, or PIN), the platform checks that the request is marked as secure, if it is a recurring authorization, or if NoCVM requests are allowed by the issuer.
This validation is performed for both zero balance and full balance integration.
Name: CMV
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
PIN_AND_CVV_VALID | APPROVED | PIN or CVV present and the information was valid. | NA | 00 (For all Networks) |
SAFE_TRANSACTION | APPROVED | No CVM information, but authorization was flagged as safe by the Acquirer/Network. | NA | 00 (For all Networks)00 (For all Networks) |
VISA_PROVISIONING_VALIDATION_REQUEST | APPROVED | No CVM information, but the authorization is a Visa Provisioning Validation request. (Visa only. | NA | 00 (For all Networks) |
RECURRING_TRANSACTION_WITH_NO_AUTH_METHOD | APPROVED | No CVM information, but the transaction is Recurring. | NA | 00 (For all Networks) |
NO_CVM_TRANSACTION_WITH_NO_AUTH_METHOD | APPROVED | No CVM information, but the issuer enabled the NoCVM configuration to validate the authorization in the anti-fraud system. | NA | 00 (For all Networks) |
PRE_AUTH_TRANSACTION_WITH_NO_AUTH_METHOD | APPROVED | No CVM information, but the authorization was flagged as safe by the Acquirer/Network and is a pre-authorization. (Mastercard only). | NA | 00 (For all Networks) |
MANUAL_ENTRY_MODE_TRANSACTION_WITH_NO_AUTH_METHOD | APPROVED | No CVM information, but the authorization was performed using PAN Manual Entry (Entry Mode = 01). | NA | 00 (For all Networks) |
HSM_EMPTY_RESPONSE | SKIPPED | No response from HSM. | NA | NA |
ENTRY_MODE_NOT_ALLOWED_WITH_NO_CVM | REJECTED | No CVM information and none of the NoCVM exceptions were met to approve this request. | NCV | Visa: 57 Mastercard: 57 Tecban: 57 Rupay: 57 |
PIN_INVALID | REJECTED | Request contained incorrect PIN. | FR6 | Visa: 55 Mastercard: 55 Tecban: 55 Rupay: 55 |
CVV1_INVALID | REJECTED | Request contained incorrect tracking data on Magnetic Stripe. | FR1 | Visa: 82 Mastercard: 88 Tecban: 57 Rupay: 14 |
CVV2_INVALID | REJECTED | Request contained incorrect CVV2 information. | FR2 | Visa: 82 Mastercard: 88 Tecban: 57 Rupay: 14 |
SERVICE_CODE_INVALID | REJECTED | Internal Service Code to validate CVV was invalid or misconfigured. | FR7 | Visa: 14 Mastercard: 14 Tecban: 14 Rupay: 14 |
EXPIRATION_DATE_INVALID | REJECTED | Expiration date provided in the network message (input by the cardholder) was invalid. | CED | Visa: 54 Mastercard: 54 Tecban: 54 Rupay: 14 |
INCOMPLETE_TRANSACTION | REJECTED | Internal error on HSM response. | OP1 | Visa: 12 Mastercard: 30 Tecban: 30 Rupay: 30 |
GENERIC_HSM_ERROR | REJECTED | Unexpected error from HSM processing. | OP1 | Visa: N0 Mastercard: 96 Tecban: 06 Rupay: 96 |
Additional data: Not yet mapped
Payload example:
{
"name": "CVM",
"status": "APPROVED",
"reason": "PIN_AND_CVV_VALID",
"description": "Pin and CVV are valid",
"additional_data": {}
}
Entry mode validation
The Pismo platform checks the card's cryptogram information to verify that the entry mode used in the request is allowed.
This validation is performed for both zero balance and full balance integration.
Name: ENTRY_MODE
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
ENTRY_MODE_VALID | APPROVED | Entry mode is valid, based on the cryptogram information. | NA | 00 (For all Networks) |
TRANSACTION_HAS_NO_CRYPTOGRAM | REJECTED | Entry mode is Chip (05), but there is no cryptogram information in the request. | FRE | Visa: 63 Mastercard: 57 Tecban: R9 Rupay: 57 |
TRANSACTION_HAS_CRYPTOGRAM | REJECTED | Entry mode is not Chip or Contactless, but the operation contains cryptogram information. | FRE | Visa: 63 Mastercard: 57 Tecban: R9 Rupay: 57 |
Additional data: Not yet mapped
Payload example:
{
"name": "ENTRY_MODE",
"status": "APPROVED",
"reason": "ENTRY_MODE_VALID",
"description": "Entry mode valid",
"additional_data": {}
}
Currency validation
This rule validates if it is a purchase using Brazilian currency outside Brazil.
This validation is performed for both zero balance and full balance integration.
This validation will be deprecated and replaced by a new DCC validation.
Name: CURRENCY
Possible statuses: APPROVED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
CURRENCY_ALLOWED | APPROVED | Purchase is not in Brazilian currency or it originates in Brazil. | NA | 00 (For all Networks) |
CURRENCY_NOT_ALLOWED | REJECTED | Purchase uses Brazilian currency, and it is for an international merchant. | DCC | Visa: 57 Mastercard: 57 Tecban: 57 Rupay: 57 |
Additional data: Not yet mapped
Payload example:
{
"name": "CURRENCY",
"status": "APPROVED",
"reason": "CURRENCY_ALLOWED",
"description": "Currency allowed",
"additional_data": {}
}
Terminal capability validation
The Pismo platform verifies that the POS terminal has the capability required for the entry mode.
This validation is performed for both zero balance and full balance integration.
Name: TERMINAL_CAPABILITY
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
TERMINAL_CAPABILITY_VALID | APPROVED | Terminal has the capability to process the received entry mode. | NA | 00 (For all Networks) |
TERMINAL_CAPABILITY_UNKNOWN | SKIPPED | No mapping for the received terminal capability. | NA | NA |
TERMINAL_CAPABILITY_INVALID | REJECTED | Terminal doesn’t have the capability to process the received entry mode. | FRH | Visa: 58 Mastercard: 58 Tecban: 58 Rupay: 58 |
Additional data: Not yet mapped
Payload example:
{
"name": "TERMINAL_CAPABILITY",
"status": "APPROVED",
"reason": "TERMINAL_CAPABILITY_VALID",
"description": "Terminal capability is valid",
"additional_data": {}
}
Chip values validation
The Pismo platform checks that information like amount and country in the cryptogram field match the information in the authorization message.
This validation is performed for both zero balance and full balance integration.
This rule today is only applied to Visa processing.
Name: CHIP_VALUES
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
CHIP_VALUES_MATCH | APPROVED | ARQC information matched with authorization message information. | NA | 00 (For all Networks) |
PROCESSING_CODE_WITHDRAWAL | SKIPPED | Validation is skipped for withdrawals, because some values are expected to be different. | NA | NA |
TRANSACTION_HAS_NO_CHIP | SKIPPED | Operation not being processed using Chip, so no need for this validation. | NA | NA |
CHIP_TRANSACTION_AMOUNT_DOES_NOT_MATCH | REJECTED | Amount of the transaction is different from the amount of the transaction in the Chip Information. | FRE | Visa: 63 Mastercard: 57 Tecban: R9 Rupay: 57 |
CHIP_TRANSACTION_COUNTRY_DOES_NOT_MATCH | REJECTED | Country of the transaction is different from the country of the transaction in the Chip Information. | FRE | Visa: 63 Mastercard: 57 Tecban: R9 Rupay: 57 |
Additional data: Not yet mapped
Payload example:
{
"name": "CHIP_VALUES",
"status": "APPROVED",
"reason": "CHIP_VALUES_MATCH",
"description": "Chip values match",
"additional_data": {}
}
Chip signature validation
The Pismo platform checks that the verification method specified in the cryptogram data is valid. By default, the platform denies transactions that use Paper Signature as the validation method.
This validation is performed for both zero balance and full balance integration.
Name: CHIP_SIGNATURE
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
CHIP_SIGNATURE_VALID | APPROVED | Validation method used is valid. | NA | 00 (For all Networks) |
NO_CHIP_SIGNATURE | SKIPPED | No chip information, so no need for this validation. | NA | NA |
CHIP_SIGNATURE_DEPRECATED | REJECTED | Transaction performed using Paper Signature as validation method. | FR0 | Visa: 82 Mastercard: 88 Tecban: R9 Rupay: 81 |
Additional data: Not yet mapped
Payload example:
{
"name": "CHIP_SIGNATURE",
"status": "APPROVED",
"reason": "CHIP_SIGNATURE_VALID",
"description": "Chip signature valid",
"additional_data": {}
}
Valid card validation
The Pismo platform checks that the card number used for the authorization is registered in Pismo's internal database.
This validation is performed for both zero balance and full balance integration.
Name: CARD_EXISTS
Possible statuses: APPROVED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
CARD_FOUND | APPROVED | Card found in the database. | NA | 00 (For all Networks) |
CARD_NOT_FOUND | REJECTED | Card not found in the database. | 998 | Visa: 46 Mastercard: 14 Tecban: 56 Rupay: 14 |
Additional data: additional_data
contains the card type. This field is only filled in for APPROVED and REJECTED status scenarios.
Payload example:
{
"name": "CARD_EXISTS",
"status": "APPROVED",
"reason": "CARD_FOUND",
"description": "Card exists.",
"additional_data": {
"type": "PLASTIC"
}
}
Valid card token validation
This rule only applies to authorizations that use tokens. The Pismo platform checks that the token used for the authorization is registered in Pismo's internal database.
This validation is performed for both zero balance and full balance integration.
Name: CARD_TOKEN
Possible statuses: APPROVED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
CARD_FOUND | APPROVED | Valid card found in the database using the token. | NA | 00 (For all Networks) |
CARD_TOKEN_NOT_FOUND | REJECTED | Token was not found in the database. The platform will try to get the card information based on the card hash (card number), but the authorization will be declined because the token is not registered. | Z26 | Visa: 14 Mastercard: 14 Tecban: 57 Rupay: 57 |
Additional data: Not yet mapped
Payload example:
{
"name": "CARD_TOKEN",
"status": "REJECTED",
"reason": "CARD_TOKEN_NOT_FOUND",
"description": "Card token not found.",
"additional_data": {}
}
Token status validation
This rule only applies to authorizations that use tokens. The Pismo platform checks that the token used for the authorization is valid.
This validation is performed for both zero balance and full balance integration.
Name: CARD_TOKEN_STATUS
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
CARD_TOKEN_STATUS_VALID | APPROVED | Token found and has status ACTIVE. | NA | 00 (For all Networks) |
SKIPPED | SKIPPED | Authorization is not Tokenized, or it is a credit voucher or payment authorization request. | NA | NA |
CARD_TOKEN_DEACTIVATED | REJECTED | Token has status DEACTIVATED. | Z23 | Visa: 14 Mastercard: 57 Tecban: 57 Rupay: 57 |
CARD_TOKEN_FAILED | REJECTED | Token has status FAILED. | Z29 | Visa: 14 Mastercard: 57 Tecban: 57 Rupay: 57 |
CARD_TOKEN_INACTIVE | REJECTED | Token has status INACTIVE. | Z24 | Visa: 14 Mastercard: 57 Tecban: 57 Rupay: 57 |
CARD_TOKEN_SUSPENDED | REJECTED | Token has status SUSPENDED. | Z22 | Visa: 14 Mastercard: 57 Tecban: 57 Rupay: 57 |
CARD_TOKEN_STATUS_UNKNOWN | REJECTED | Token has a status that is not mapped by the authorization system, and it is different from ACTIVE. | Z27 | Visa: 14 Mastercard: 57 Tecban: 57 Rupay: 57 |
Additional data: Not yet mapped
Payload example:
{
"name": "CARD_TOKEN_STATUS",
"status": "APPROVED",
"reason": "CARD_TOKEN_STATUS_VALID",
"description": "Card token status: ACTIVE.",
"additional_data": {}
}
Processing code definition
If the definition for the transaction processing code cannot be retrieved, the authorization request is declined.
This validation is performed for both zero balance and full balance integration.
Name: PROCESSING_CODE
Possible statuses: REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
PROCESSING_CODE_GENERIC_ERROR | REJECTED | Unexpected error occurred while calling the API that defines the processing code to be used. | PCE | Visa: 14 Mastercard: 96 Tecban: 06 Rupay: 96 |
PROCESSING_CODE_TIMEOUT | REJECTED | Timeout occurred while calling the API that defines the processing code to be used. | PCT | Visa: N0 Mastercard: 96 Tecban: 06 Rupay: 96 |
Additional data: Not yet mapped
Payload example:
{
"name": "PROCESSING_CODE",
"status": "REJECTED",
"reason": "PROCESSING_CODE_GENERIC_ERROR",
"description": "Unexpected error performing processing code.",
"additional_data": {}
}
Fetch authorization configuration
The Pismo platform retrieves the configuration related to the platform. This configuration is required. If not found, the authorization request is declined.
This validation is performed for both zero balance and full balance integration.
Name: PLATFORM_CONFIG
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
PLATFORM_CONFIG_FOUND | APPROVED | Valid configuration found. | NA | 00 (For all Networks) |
CARD_NOT_FOUND | SKIPPED | If card is not found, there is no way to find the platform or account, so validation can’t be performed. | NA | NA |
PLATFORM_CONFIG_NOT_FOUND | REJECTED | Configuration not found. | MPC | Visa: 14 Mastercard: 96 Tecban: 06 Rupay: 96 |
PLATFORM_CONFIG_GENERIC_ERROR | REJECTED | Unexpected error occurred while fetching the configurations. | PCE | Visa: 14 Mastercard: 96 Tecban: 06 Rupay: 96 |
Additional data: Not yet mapped
Payload example:
{
"name": "PLATFORM_CONFIG",
"status": "APPROVED",
"reason": "PLATFORM_CONFIG_FOUND",
"description": "Platform Config found.",
"additional_data": {}
}
Fetch authorization configuration (outdated)
The Pismo platform retrieves the configuration related to the program. This configuration is required. If not found, the authorization request is declined.
This validation is performed for both zero balance and full balance integration.
PROGRAM_CONFIG
is being deprecated and to usePLATFORM_CONFIG
.
Name: PROGRAM_CONFIG
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
PROGRAM_CONFIG_FOUND | APPROVED | Valid configuration found. | NA | 00 (For all Networks) |
CARD_NOT_FOUND | SKIPPED | If card is not found, there is no way to find the program or account, so validation can’t be performed. | NA | NA |
PROGRAM_CONFIG_NOT_FOUND | REJECTED | Configuration not found. | MPC | Visa: 14 Mastercard: 96 Tecban: 06 Rupay: 96 |
PROGRAM_CONFIG_GENERIC_ERROR | REJECTED | Unexpected error occurred while fetching the configurations. | PCE | Visa: 14 Mastercard: 96 Tecban: 06 Rupay: 96 |
Additional data: Not yet mapped
Payload example:
{
"name": "PROGRAM_CONFIG",
"status": "APPROVED",
"reason": "PROGRAM_CONFIG_FOUND",
"description": "Program found.",
"additional_data": {}
}
Card mode validation
This rule applies to combination cards. The Pismo platform checks if the card has the mode enabled for the account type of the transaction. For example, purchases in credit mode are only approved if the card has the mode Credit
enabled.
This validation is performed for both zero balance and full balance integration.
Name: CARD_MODE
Possible statuses: APPROVED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
CARD_MODE_VALID | APPROVED | Card mode is valid and enabled for the operation or the card is not a combination card with modes. | NA | 00 (For all Networks) |
CARD_MODE_INVALID | REJECTED | Card mode not enabled for operation. For example, the purchase is in the credit mode, but the card has only the debit mode enabled. | CMD | Visa: 57 Mastercard: 57 Tecban: 5 Rupay: 57 |
Additional data: Not yet mapped
Payload example:
{
"name": "CARD_MODE",
"status": "APPROVED",
"reason": "CARD_MODE_VALID",
"description": "Valid card mode",
"additional_data": {}
}
Card mode status validation
This rule is applied to cards issued as combination cards with card modes (Mode type: COMBO). This validation checks if the card has the mode status enable based on the ACTIVE status. Otherwise, if the card mode is SUSPENDED or INACTIVE, the authorization will be denied.
Card mode status validation is independent of the card status, i.e. either one of them doesn’t change the other. This validation is performed for both Zero Balance and Full Balance Flow.
Name: CARD_MODE_STATUS
Possible Status: APPROVED, REJECTED, SKIPPED
Possible Reasons:
Reason | Status | Description | Custom Code | Response code |
---|---|---|---|---|
CARD_MODE_STATUS_ACTIVE | APPROVED | Card mode status: ACTIVE | NA | 00 (for all networks) |
CARD_MODE_STATUS_DEBIT_INACTIVE | REJECTED | Status with INACTIVE mode | CMD | Visa: 57 Mastercard: 57 Tecban: 57 Rupay: 57 |
CARD_MODE_STATUS_DEBIT_SUSPENDED | REJECTED | Status with SUSPENDED mode | CMD | Visa: 57 Mastercard: 57 Tecban: 57 Rupay: 57 |
CARD_MODE_STATUS_CREDIT_INACTIVE | REJECTED | Status with INACTIVE mode | CMD | Visa: 57 Mastercard: 57 Tecban: 57 Rupay: 57 |
CARD_MODE_STATUS_CREDIT_SUSPENDED | REJECTED | Status with SUSPENDED mode | CMD | Visa: 57 Mastercard: 57 Tecban: 57 Rupay: 57 |
CARD_MODE_STATUS_NOT_FOUND | REJECTED | Statusless mode | CMD | Visa: 57 Mastercard: 57 Tecban: 57 Rupay: 57 |
CARD_MODE_STATUS_SKIPPED | SKIPPED | Card with mode type other than COMBO | NA | NA |
Additional Data: Not mapped yet.
Payload example
{
"name": "CARD_MODE_STATUS",
"status": "APPROVED",
"reason": "CARD_MODE_STATUS_ACTIVE",
"description": "Card status: ACTIVE.",
"additional_data": {}
}
Contactless allowed validation
The Pismo platform checks to see if the contactless function is allowed for the card.
This validation is performed for both zero balance and full balance integration.
Name: CONTACTLESS
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
CONTACTLESS_ENABLED | APPROVED | Contactless is enabled or the operation is not using contactless entry mode (07) | NA | 00 (For all Networks) |
CARD_NOT_FOUND | SKIPPED | Card not found, so validation can’t be performed. | NA | NA |
CONTACTLESS_DISABLED | REJECTED | Authorization has entry mode contactless (07), and this function is disabled for this card. | UBN | Visa: 57 Mastercard: 57 Tecban: 57 Rupay: 57 |
Additional data: Not yet mapped
Payload example:
{
"name": "CONTACTLESS",
"status": "APPROVED",
"reason": "CONTACTLESS_ENABLED",
"description": "Contactless enabled.",
"additional_data": {}
}
Account type validation
The account type must be valid for the card being used. For example, a credit card can’t process a request on a debit account.
This validation is performed for both zero balance and full balance integration.
Name: ACCOUNT_TYPE
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
ACCOUNT_TYPE_VALID | APPROVED | Account type valid for card mode. (Authorization request is in credit mode and card is a credit card, or request is in debit mode and card is a debit card.) | NA | 00 (For all Networks) |
CARD_NOT_FOUND | SKIPPED | Card not found, so validation can’t be performed. | NA | NA |
ACCOUNT_TYPE_INVALID | REJECTED | Account type invalid for card mode. (Authorization request is in credit mode but card is a debit card, or request is in debit mode but card is a credit card.) | IAT | Visa: 57 Mastercard: 57 Tecban: 57 Rupay: 57 |
Additional data: Not yet mapped
Payload example:
{
"name": "ACCOUNT_TYPE",
"status": "APPROVED",
"reason": "ACCOUNT_TYPE_VALID",
"description": "Account Type: CREDIT_CARD_ACCOUNT. Card Mode: CREDIT.",
"additional_data": {}
}
Card ATC validation
ATC is the transaction counter present in the chip information of the card. Every time the cardholder performs a transaction using a POS that reads chip data, the counter is incremented. The Pismo platform compares the counter value received in the request with the ones registered in the database from previous authorizations. If the value is not duplicated and it is within an allowed range (configured by the issuer), the request is validated.
This validation is performed for both zero balance and full balance integration.
Name: CARD_ATC
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
CARD_ATC_VALID | APPROVED | Request is not using chip data, or, if it is, the ATC is present in the request, is not duplicated, and is within the allowed range. | NA | 00 (For all Networks) |
CARD_NOT_FOUND | SKIPPED | Card not found, so validation can’t be performed. | NA | NA |
CARD_ATC_INVALID | REJECTED | ATC is duplicated or is outside the allowed range. | FAT | Visa: 63 Mastercard: 63 Tecban: 01 Rupay: 05 |
Additional data: Not yet mapped
Payload example:
{
"name": "CARD_ATC",
"status": "APPROVED",
"reason": "CARD_ATC_VALID",
"description": "Received 12 but the last is [9,6,5,1]. Used these params: MinOffset: 5, MaxOffset: 15, IsAdvice: false.",
"additional_data": {}
}
Operation validation
The Pismo platform checks to see if the operation is allowed by the issuer. To do this, it checks that the processing code is configured for the program of the card.
This validation is performed only for full balance integration.
Name: OPERATION
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
VALID_OPERATION | APPROVED | Operation is configured and is allowed by the issuer for the program of the card that was used. | NA | 00 (For all Networks) |
CARD_NOT_FOUND | SKIPPED | Card not found, so validation can’t be performed. | NA | NA |
OPERATION_NOT_ALLOWED | REJECTED | Operation not configured by the issuer for the program of the card that was used. | ANF | Visa: 57 Mastercard: 57 Tecban: 57 Rupay: 57 |
Additional data: Not yet mapped
Payload example:
{
"name": "OPERATION",
"status": "APPROVED",
"reason": "VALID_OPERATION",
"description": "Valid operation (00) for OrgId (TN-OrgId) and ProgramId (123).",
"additional_data": {}
}
Password tries validation
The Pismo platform keeps track of how many times in a row a cardholder enters the wrong password. If this count reaches a configured threshold, the card is blocked and no new requests are allowed. This threshold is configured by the issuer on the Pismo platform.
The counter is only reset when the cardholder inputs the correct password in a new authorization request before reaching the blocking threshold. Requests that don't use a password, like e-commerce or contactless requests, do not reset the counter, even if they are approved. After reaching the threshold even requests that do not require a password are declined.
This validation is performed for both zero balance and full balance integration.
Name: PASSWORD_ATTEMPTS
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
CARD_PASSWORD_ATTEMPTS_VALID | APPROVED | Password was not needed or the correct password was entered before the allowed number of attempts was exceeded. | NA | 00 (For all Networks) |
CARD_NOT_FOUND | SKIPPED | Card not found, so validation can’t be performed. | NA | NA |
CARD_PASSWORD_ATTEMPTS_EXCEEDED | REJECTED | Card was blocked because the allowed number of attempts was exceeded. | TSM | Visa: 75 Mastercard: 75 Tecban: 75 Rupay: 75 |
Additional data: Not yet mapped
Payload example:
{
"name": "PASSWORD_ATTEMPTS",
"status": "APPROVED",
"reason": "CARD_PASSWORD_ATTEMPTS_VALID",
"description": "Password tries is valid.",
"additional_data": {}
}
Card inputted expiration date validation
The Pismo platform checks that the card expiration date provided by the cardholder matches the card's registered expiration date.
This validation is performed for both zero balance and full balance integration.
Name: CARD_INPUTTED_EXPIRATION_DATE
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
CARD_INPUTTED_EXPIRATION_DATE_VALID | APPROVED | Correct expiration date entered. | NA | 00 (For all Networks) |
CARD_NOT_FOUND | SKIPPED | Card not found, so validation can’t be performed. | NA | NA |
CARD_INPUTTED_EXPIRATION_DATE_MISMATCH | REJECTED | Incorrect expiration date entered. | CED | Visa: 54 Mastercard: 54 Tecban: 54 Rupay: 54 |
Additional data: Not yet mapped
Payload example:
{
"name": "CARD_INPUTTED_EXPIRATION_DATE",
"status": "APPROVED",
"reason": "CARD_INPUTTED_EXPIRATION_DATE_VALID",
"description": "Card inputted expiration date is valid.",
"additional_data": {}
}
Card expiration date validation
If the card's expiration date has passed, the request is declined.
This validation is performed for both zero balance and full balance integration.
Name: CARD_EXPIRATION_DATE
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
CARD_NOT_EXPIRED | APPROVED | Registered card expiration date is after the current time of the authorization request. | NA | 00 (For all Networks) |
CARD_NOT_FOUND | SKIPPED | Card not found, so validation can’t be performed. | NA | NA |
CARD_EXPIRED | REJECTED | Registered card expiration date is before the current time of the authorization request. | VNM | Visa: 54 Mastercard: 54 Tecban: 54 Rupay: 54 |
Additional data: additional_data
contains the card expiration date. This field is only filled in for APPROVED and REJECTED status scenarios.
Payload example:
{
"name": "CARD_EXPIRATION_DATE",
"status": "APPROVED",
"reason": "CARD_NOT_EXPIRED",
"description": "Card not expired.",
"additional_data": {
"expiration_date": "2028-05-23"
}
}
Card valid until validation
Cards can have a second expiration date called "valid until". This feature is used for temporary cards, which might need to be valid for a shorter time than would otherwise be allowed by the actual expiration date. The Pismo platform checks to make sure that the "valid until" date is greater then the current time. If not, the request is declined.
This validation is performed for both zero balance and full balance integration.
Name: CARD_VALID_UNTIL
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
CARD_VALID_UNTIL_VALID | APPROVED | "Until date" is after the current time of the authorization request. | NA | 00 (For all Networks) |
CARD_NOT_FOUND | SKIPPED | Card not found, so validation can’t be performed. | NA | NA |
CARD_VALID_UNTIL_INVALID | REJECTED | "Until date" is before the current time of the authorization request. | VEV | Visa: 54 Mastercard: 54 Tecban: 54 Rupay: 54 |
Additional data: additional_data
contains the valid until date. This field is only filled in for APPROVED and REJECTED status scenarios.
Payload example:
{
"name": "CARD_VALID_UNTIL",
"status": "APPROVED",
"reason": "CARD_VALID_UNTIL_VALID",
"description": "Card is valid.",
"additional_data": {
"valid_until": "2023-02-04T16:58:14"
}
}
Card status validation
The Pismo platform checks a card's current status to make sure it is not blocked.
This validation is performed for both zero balance and full balance integration.
Name: CARD_STATUS
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
CARD_STATUS_VALID | APPROVED | Card has status NORMAL or REISSUED. | NA | 00 (For all Networks) |
CARD_NOT_FOUND | SKIPPED | Card not found, so validation can’t be performed. | NA | NA |
CARD_STATUS_INVALID_CREATED | REJECTED | Card has status CREATED. | FRB | Visa: 78 Mastercard: 57 Tecban: 57 Rupay: 57 |
CARD_STATUS_INVALID_BLOCKED | REJECTED | Card has status BLOCKED. | UBT | Visa: 59 Mastercard: 63 Tecban: 76 Rupay: 57 |
CARD_STATUS_INVALID_WARNING | REJECTED | Card has status WARNING. | BNW | Visa: 63 Mastercard: 63 Tecban: 57 Rupay: 57 |
CARD_STATUS_INVALID_CANCELED | REJECTED | Card has status CANCELED. | Visa: 46 Mastercard: 62 Tecban: 57 Rupay: 62 | |
CARD_STATUS_INVALID_CLIENTORDER | REJECTED | Card has status CLIENTORDER. | BND | Visa: 46 Mastercard: 62 Tecban: 57 Rupay: 62 |
CARD_STATUS_INVALID_FRAUD | REJECTED | Card has status FRAUD. | BNF | Visa: 07 Mastercard: 04 Tecban: 57 Rupay: 04 |
CARD_STATUS_INVALID_LOST | REJECTED | Card has status LOST. | BNP | Visa: 41 Mastercard: 41 Tecban: 41 Rupay: 41 |
CARD_STATUS_INVALID_ROBBED | REJECTED | Card has status ROBBED. | BNR | Visa: 43 Mastercard: 43 Tecban: 43 Rupay: 43 |
CARD_STATUS_INVALID_THEFT | REJECTED | Card has status THEFT. | BNR | Visa: 43 Mastercard: 43 Tecban: 43 Rupay: 43 |
CARD_STATUS_INVALID_DELETED | REJECTED | Card has status DELETED. | VED | Visa: 46 Mastercard: 57 Tecban: 56 Rupay: 57 |
CARD_STATUS_INVALID_DAMAGED | REJECTED | Card has status DAMAGED. | BNM | Visa: 57 Mastercard: 57 Tecban: 56 Rupay: 57 |
CARD_STATUS_INVALID_UNRECEIVED | REJECTED | Card has status UNRECEIVED. | BNU | Visa: 41 Mastercard: 41 Tecban: 41 Rupay: 57 |
CARD_STATUS_INVALID_INOPERATIVE | REJECTED | Card has status INOPERATIVE. | BNI | Visa: 14 Mastercard: 57 Tecban: 57 Rupay: 57 |
CARD_STATUS_UNKNOWN | REJECTED | Card has a status that is not mapped in the authorization system. | CSU | Visa: 14 Mastercard: 57 Tecban: 56 Rupay: 57 |
Additional data: Not yet mapped
Payload example:
{
"name": "CARD_STATUS",
"status": "APPROVED",
"reason": "CARD_STATUS_VALID",
"description": "Card status: NORMAL.",
"additional_data": {}
}
Fetch account
In order to process the authorization flow, the Pismo platform fetches the account to use its configurations. If an error happens while fetching these details, the authorization request is declined.
This validation is performed only for Full Balance Flow.
Name: ACCOUNT
Possible Status: APPROVED, SKIPPED, REJECTED
Possible Reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
ACCOUNT_FOUND | APPROVED | Account found. | NA | 00 (For all Networks) |
CARD_NOT_FOUND | SKIPPED | If card was not found, there is no way to find out the account. | NA | NA |
ACCOUNT_NOT_FOUND | REJECTED | Account was not found. | 998 | Visa: 14 Mastercard: 14 Tecban: 56 Rupay: 14 Elo: 14 |
ACCOUNT_GENERIC_ERROR | REJECTED | An unexpected error has happened while fetching the account. | AGE | Visa: N0 Mastercard: 96 Tecban: 06 Rupay: 96 Elo: 14 |
ACCOUNT_TIMEOUT | REJECTED | A timeout occurred while fetching account. | ACT | Visa: N0 Mastercard: 96 Tecban: 06 Rupay: 96 Elo: 96 |
Additional Data: Not mapped yet.
Payload example:
{
"name": "ACCOUNT",
"status": "APPROVED",
"reason": "ACCOUNT_FOUND",
"description": "Account 123 found.",
"additional_data": {}
}
Fetch account limit details
If the Pismo platform cannot retrieve details about the account limits, the request is declined.
This validation is performed only for full balance integration.
Name: ACCOUNT_LIMITS
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
ACCOUNT_LIMITS_FOUND | APPROVED | Account limit details retrieved successfully. | NA | 00 (For all Networks) |
CARD_NOT_FOUND | SKIPPED | Card not found, so validation can’t be performed. | NA | NA |
LEDGER_ACCOUNT_NOT_FOUND | REJECTED | Account limit details not found. | LNF | Visa: 14 Mastercard: 14 Tecban: 56 Rupay: 14 |
LEDGER_ACCOUNT_TIMEOUT | REJECTED | Timeout occurred while retrieving account limit details. | LCT | Visa: N0 Mastercard: 96 Tecban: 06 Rupay: 96 |
LEDGER_ACCOUNT_GENERIC_ERROR | REJECTED | Unexpected error occurred while retrieving account limit details. | LAE | Visa: 14 Mastercard: 96 Tecban: 06 Rupay: 96 |
Additional data: Not yet mapped
Payload example:
{
"name": "ACCOUNT_LIMITS",
"status": "APPROVED",
"reason": "ACCOUNT_LIMITS_FOUND",
"description": "Account limits exists.",
"additional_data": {}
}
Account status validation
The Pismo platform only authorizes a transaction on an account if the account status is NORMAL
.
This validation is performed only for full balance integration.
Name: ACCOUNT_STATUS
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
ACCOUNT_STATUS_VALID | APPROVED | Account is not blocked. | NA | 00 (For all Networks) |
CARD_NOT_FOUND | SKIPPED | Card not found, so validation can’t be performed. | NA | NA |
ACCOUNT_STATUS_INVALID | REJECTED | Account is blocked. | CND | Visa: 62 Mastercard: 57 Tecban: 57 Rupay: 57 Elo: 57 |
Additional data: Not yet mapped
Payload example:
{
"name": "ACCOUNT_STATUS",
"status": "APPROVED",
"reason": "ACCOUNT_STATUS_VALID",
"description": "Account has a valid status: true.",
"additional_data": {}
}
Fetch impact imformation
If the Pismo platform cannot retrieve the impact information for the operation, the authorization request is declined.
This is performed only for full balance integration.
Name: CREDIT_LIMIT
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
CREDIT_LIMIT_IMPACT_FOUND | APPROVED | Impact information was found and is correctly configured. | NA | 00 (For all Networks) |
SKIPPED | SKIPPED | Card not found, so validation can’t be performed. | NA | NA |
CREDIT_LIMIT_IMPACT_NOT_FOUND | REJECTED | Impact not found or is configured incorrectly. | 998 | Visa: 46 Mastercard: 14 Tecban: 56 Rupay: 14 |
Additional data: Not yet mapped
Payload example:
{
"name": "CREDIT_LIMIT",
"status": "APPROVED",
"reason": "CREDIT_LIMIT_IMPACT_FOUND",
"description": "Acceptances found.",
"additional_data": {}
}
Authorization amounts calculation
The Pismo platform performs calculations related to the transaction amount, such as currency conversion, installments calculations, and the application of fees and taxes. If an error occurs in a calculation or some needed information is missing, the authorization request is declined.
This validation is performed only for full balance integration.
Name: RATES
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
RATES_APPROVED | APPROVED | All calculations performed successfully. | NA | 00 (For all Networks) |
SKIPPED | SKIPPED | Card not found, so validation can’t be performed. | NA | NA |
RATES_REJECT | REJECTED | Unexpected error occurred while calculating the authorization amounts. | RAE | Visa: N0 Mastercard: 96 Tecban: 06 Rupay: 96 |
Additional data: Not yet mapped
Payload example:
{
"name": "RATES",
"status": "APPROVED",
"reason": "RATES_APPROVED",
"description": "All calculation were performed successfully.",
"additional_data": {}
}
Purchase with installments and interest validation
If installments and interest need to be calculated for a transaction, the Pismo platform must retrieve all the statements related to the number of installments. This is because the due date of each installment is used in the calculation. If there are more installments than configured statements, the calculation can't be performed, and the authorization request is declined.
This validation is performed only for full balance integration.
Name: STATEMENTS
Possible statuses: REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
INSUFFICIENT_STATEMENTS | REJECTED | Insufficient number of created statements to calculate installments. | ISE | Visa: 57 Mastercard: 57 Tecban: 06 Rupay: 57 |
Additional data: Not yet mapped
Payload example:
{
"name": "STATEMENTS",
"status": "REJECTED",
"reason": "INSUFFICIENT_STATEMENTS",
"description": "Insufficient number of created statements to calculate installments.",
"additional_data": {}
}
Max transactions validation for temporary cards
The Pismo platform ensures that the number of authorized transactions does not exceed the maximum allowed number of transactions for a temporary card. This parameter is configured in the program parameters. If this parameter is not set, or the card is not of type TEMPORARY
, this validation is not performed.
This validation is performed only for full balance integration.
Name: MAX_TRANSACTIONS_FOR_TEMPORARY_CARD
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
MAX_TRANSACTIONS_IF_TEMPORARY_CARD_APPROVED | APPROVED | Card is temporary and the number of transactions is under the configured threshold. | NA | 00 (For all Networks) |
CARD_NOT_FOUND | SKIPPED | Card not found, so validation can’t be performed. | NA | NA |
MAX_TRANSACTIONS_IF_TEMPORARY_CARD_SKIPPED | SKIPPED | Card is not temporary. | NA | NA |
MAX_TRANSACTIONS_IF_TEMPORARY_CARD_EXCEEDED | REJECTED | Number of transactions performed using temporary card exceeded the configured threshold. | CTE | Visa: 54 Mastercard: 54 Tecban: 54 Rupay: 54 |
Additional data: Not yet mapped
Payload example:
{
"name": "MAX_TRANSACTIONS_FOR_TEMPORARY_CARD",
"status": "SKIPPED",
"reason": "MAX_TRANSACTIONS_IF_TEMPORARY_CARD_SKIPPED",
"description": "Card is not temporary.",
"additional_data": {}
}
Max transaction amount validation
The Pismo platform validates that the transaction amount does not exceed the maximum amount allowed for the card. This validation is not cumulative, so for every new request, the same maximum amount is used. This parameter is configured when the card is created. If the parameter is not set, the validation is not performed.
This validation is performed only for full balance integration.
Name: CARD_TRANSACTION_LIMIT
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
LIMIT_APPROVED | APPROVED | Maximum transaction limit is greater than the amount of the authorization request. | NA | 00 (For all Networks) |
SKIPPED | SKIPPED | Card not found, so validation can’t be performed. | NA | NA |
LIMIT_INSUFFICIENT_FUNDS | REJECTED | Transaction amount is greater than the maximum transaction limit configured for the card. | 810 | Visa: 51 Mastercard: 51 Tecban: 51 Rupay: 51 |
Additional data: additional_data
contains the transaction limit. This field is only filled in for APPROVED and REJECTED status scenarios if this limit exists.
Payload example:
{
"name": "CARD_TRANSACTION_LIMIT",
"status": "APPROVED",
"reason": "LIMIT_APPROVED",
"description": "Card transaction sufficient limit.",
"additional_data": {
"transaction_limit": 9999.0
}
}
Available limits validation
The Pismo platform checks that the transaction amount is within the account limits. It also checks that the account is allowed to receive a debit or credit, depending on the operation being performed.
This validation is performed only for full balance integration.
Name: LEDGER
Possible statuses: APPROVED, SKIPPED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
LEDGER_APPROVED | APPROVED | All available limits successfully validated. | NA | 00 (For all Networks) |
SKIPPED | SKIPPED | If card was not found or there is any previous denial in the authorization request, the ledger is skipped to avoid impacts on the account limits. | NA | NA |
LEDGER_INSUFFICIENT_BALANCE | REJECTED | Transaction amount is greater than the account available limits. | 810 | Visa: 51 Mastercard: 51 Tecban: 51 Rupay: 51 |
LEDGER_EXCEEDS_WITHDRAWAL_LIMIT | REJECTED | Transaction is a withdrawal, and the amount is greater than the account available limits. | 810 | Visa: 61 Mastercard: 61 Tecban: 51 Rupay: 61 |
LEDGER_NOT_ALLOWED_OPERATION | REJECTED | Account is blocked from receiving debits or credits. | CND | Visa: 62 Mastercard: 57 Tecban: 57 Rupay: 57 |
LEDGER_DUPLICATED_TRACKING_ID | REJECTED | Internal error resulted in a duplicate tracking ID. | LUD | Visa: N0 Mastercard: 96 Tecban: 06 Rupay: 96 |
LEDGER_LIMIT_UPDATE_ERROR | REJECTED | Unexpected error occurred while calling ledger. | LUE | Visa: N0 Mastercard: 96 Tecban: 06 Rupay: 96 |
LEDGER_TIMEOUT | REJECTED | Timeout occurred while calling Ledger. | LUT | Visa: N0 Mastercard: 96 Tecban: 06 Rupay: 96 |
Additional data: additional_data
contains the available credit limit, total credit limit, and max credit limit. This field is only filled in for APPROVED status scenarios and the REJECTED reason LEDGER_INSUFFICIENT_BALANCE.
Payload example:
{
"name": "LEDGER",
"status": "APPROVED",
"reason": "LEDGER_APPROVED",
"description": "Ledger validations approved.",
"additional_data": {
"available_credit_limit": 1000.00,
"total_credit_limit": 1000.00,
"max_credit_limit": 1000.00
}
}
Flex controls validation
The Pismo platform cals the Flex Controls API to evaluate the configured rules against the request being processed. If any rule fails, the request is declined.
This validation is performed only for full balance integration.
Name: RULES
Fields: denial_code, error_code
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
RULES_APPROVED | APPROVED | All rules successfully evaluated and approved. | NA | 00 (For all Networks) |
SKIPPED | SKIPPED | There was a preview denial, so validation was skipped. | NA | NA |
RULES_NOT_ENABLED | SKIPPED | Flex controls evaluation not enabled for program/account/card, so validation was skipped. | NA | NA |
RULES_OPERATION_NOT_ALLOWED | REJECTED | Flex controls evaluation reported the request declined. | RED | Visa: 57 Mastercard: 57 Tecban: 57 Rupay: 57 |
RULES_INTERNAL_ERROR | REJECTED | Internal error occurred while calling flex controls API. | RED | Visa: N0 Mastercard: 96 Tecban: 06 Rupay: 96 |
Additional data: This field contains the Custom Denial Code configured in the Flex Control creation and also the error code returned by the Flex Controls API response. This field is only filled in Operation Not Allowed scenarios.
Payload example:
{
"name": "RULES",
"status": "REJECTED",
"reason": "RULES_OPERATION_NOT_ALLOWED",
"description": "Transaction not authorized as rule evaluation failed with error code:RULV10400 and denial code:DENY_CODE",
"additional_data": {
"denial_code": "DENY_CODE",
"error_code": "RULV10400"
}
}
Anti-fraud validation
The Pismo platform can be configured to call an external endpoint provided by the issuer. This endpoint can connect to an anti-fraud system or to a service implemented by the issuer.
This validation is performed only for full balance integration.
Name: ANTI_FRAUD
Possible Statuses: APPROVED, REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
ANTI_FRAUD_APPROVE | APPROVED | Call to third party endpoint was successful, and the request was approved. | NA | 00 (For all Networks) |
ANTI_FRAUD_FORCE_APPROVE | APPROVED | Call to third party endpoint was successful and overrides the Pismo platform denial decision. | NA | 00 (For all Networks) |
ANTI_FRAUD_APPROVE_BY_DEFAULT | APPROVED | Call to third party failed, but the PIsmo platform was configured to use its own decision in this scenario. The platform's decision was to approve the request. | NA | ANTI_FRAUD_OVERRIDE_REJECTION |
ANTI_FRAUD_OVERRIDE_REJECTION | REJECTED | Third party endpoint has declined the request and overrode the Pismo Platform response code. | PFT | Response Code returned in the response of the endpoint call. |
ANTI_FRAUD_REJECT | REJECTED | Third party endpoint declined the request. | PFT | Visa: 59 Mastercard: 63 Tecban: 57 Rupay: 63 |
ANTI_FRAUD_REFERRED | REJECTED | Third party endpoint declined the request and marked it as a referral. | PFT | Visa: 59 Mastercard: 63 Tecban: 57 Rupay: 63 |
ANTI_FRAUD_OVERRIDE_REFERRED | REJECTED | Third party endpoint declined the request, marked it as a referral, and overrode the Pismo platform's response code. | PFT | Response Code returned in the response of the endpoint call. |
ANTI_FRAUD_UNAVAILABLE | REJECTED | Call to third party endpoint failed, and the Pismo platform was not configured to approve by default, so the request was declined. | PFT | Visa: 59 Mastercard: 63 Tecban: 57 Rupay: 63 |
Additional data: Not yet mapped
Payload example:
{
"name": "ANTI_FRAUD",
"status": "APPROVED",
"reason": "ANTI_FRAUD_APPROVE",
"description": "AntiFraud approved this authorization",
"additional_data": {}
}
Unexpected errors
If an error occurs that is not covered by one of the other rules in this list, UNKNOWN_ERROR
is thrown, and the platform declines the request.
This validation is performed for both zero balance and full balance integration.
Name: UNKNOWN_ERROR
Possible Statuses: REJECTED
Possible reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
UNKNOWN_ERROR | REJECTED | Unexpected error occurred while processing authorization request. | OP1 | Visa: N0 Mastercard: 96 Tecban: 06 Rupay: 96 |
Additional data: Not yet mapped
Payload example:
{
"name": "UNKNOWN_ERROR",
"status": "REJECTED",
"reason": "UNKNOWN_ERROR",
"description": "An unexpected error occurred.",
"additional_data": {}
}
Internal communication errors
If an authorization request times out, an error is thrown and a denial response is sent to the network. To identify such internal communication errors, you need to consume the Card Network Authorization Return event, which contains the message the Pismo platform sent to the network. The table below shows the response codes and custom codes used for these errors.
Reason | Description | Custom Code | Response Code |
---|---|---|---|
Error while connecting to the Authorization System API | Unexpected error occurred when sending request to authorization system. | ACE | Visa: N0 Mastercard: 96 Tecban: 06 Rupay: 96 |
Error while connecting to the Distributor System API | Unexpected error occurred when sending request to distributor system. | DCE | Visa: N0 Mastercard: 96 Tecban: 06 Rupay: 96 |
Fetch parameters
In order to process the authorization flow, the platform fetches the parameters to use its configurations. If an error happens while fetching these details, the authorization request is declined.
- This validation is performed only for Full Balance Flow.
Name: PARAMETER
Possible Status: APPROVED, REJECTED
Possible Reasons:
Reason | Status | Description | Custom Code | Response Code |
---|---|---|---|---|
PARAMETER_FOUND | APPROVED | Parameters found. | NA | 00 (For all Networks) |
PARAMETER_GENERIC_ERROR | REJECTED | An unexpected error has happened while fetching the parameters. | PAE | Visa: N0 Mastercard: 96 Tecban: 06 Rupay: 96 Elo: 96 |
PARAMETER_TIMEOUT | REJECTED | A timeout occurred while fetching parameters. | PAT | Visa: N0 Mastercard: 96 Tecban: 06 Rupay: 96 Elo: 96 |
Updated 4 months ago