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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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 use PLATFORM_CONFIG.

Name: PROGRAM_CONFIG

Possible statuses: APPROVED, SKIPPED, REJECTED

Possible reasons:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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.

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: