The rules used by the Pismo platform to validate transactions are listed below. Refer to Authorization validation rules for card network operations 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": {}
}

Account number inquiry (ANI)

Account number inquiry (ANI) is a fraud prevention tool implemented by the networks, issuers, and acquirers.
An authorization request can come with the name of the cardholder on the ISO message.

The Issuer can validate this name data or handle the validation to the network sending the name of the cardholder on their database so the network will compare the data between issuer and acquirer.

Either way this is handled, it is another procedure to ensure that the transaction is safe and free of fraud, since there is key data to be confirmed by the issuer.

It is important for the issuer to confirm the type of enrollment they have in the network, if it is their responsibility to match the names or if it is the network's responsibility.

📘

This feature is currently available for Mastercard and Visa.

Issuer verification option (account_Name_Request = "I")

In this case, the customer performs the validation and returns the name matching decision.

Sample request:

The accountOwnerData is an array which contains the account owner information (sent by Visa for validation).

{
	account_Owner_Data: [
        {
                account_Owner_Type            :   PRIMARY_OWNER,
                account_Owner_Name_First       :   "FirstName",
                account_Owner_Name_Middle      :   "MiddleName",
                account_Owner_Name_Last        :   "LastName",               
        }
    ],
    additional_Service_Request_Data: {
            account_Name_Request                  :   "I"
    }
}

Visa verification option (account_Name_Request = "Y")

In this case, Visa performs the validation and returns the account owner information (primary account owner / secondary account owner (optional)).

Sample request:

{
	account_Owner_Data: []
    additional_Service_Request_Data: {
            account_Name_Request      :   "Y"
    }
}

Sample response:

name_Account_Match_Decision values could be:

MATCH,
PARTIAL_MATCH,
NO_MATCH,
UNVERIFIED (When for some reason the validation isn't performed)

account_Name_Request_Result values could be:

NAME_MATCH_PERFORMED,
NAME_MATCH_NOT_PERFORMED,
NAME_MATCH_NOT_SUPPORTED

{
	account_Owner_Data: {
        {
                account_Owner_Type            :   PRIMARY_OWNER,
                account_Owner_Name_First       :   "FirstName",
                account_Owner_Name_Middle      :   "MiddleName",
                account_Owner_Name_Last        :   "LastName",
                additional_Service_Result_Data : {
                        account_Name_Request_Result            :   "NAME_MATCH_PERFORMED",
                        full_Name_Account_Match_Decision        :   "MATCH",
                        last_Name_Account_Match_Decision        :   "MATCH",
                        middle_Name_Account_Match_Decision      :   "NO_MATCH",
                        first_Name_Account_Match_Decision       :   "PARTIAL_MATCH",
                },               
        }
    },
    additional_Service_Request_Data: {
            account_Name_Request                  :   "I"
    }
}

Address Verification Service (AVS)

AVS is a fraud prevention tool implemented by the networks, issuers, and acquirers.
An authorization request can come with the address data registered by the cardholder when processing transactions.

In the AVS workflow, the issuer must validate the address. It can validate information such postal code and street name/number.

This type of validation delivers a more secure transaction since the issuer uses one more key data to verify the cardholder identity and then approves the request for transaction.

📘

Note: this feature is currently available for Mastercard and Visa.

At Pismo, in the full balance workflow, Pismo APIs can use the account data register by the issuers to run the necessary validations. In that scenario, the issuers do not need to manage the data. The only responsibility is to make sure that the information of the cardholder is updated at Pismo Database.

For zero balance issuers, Pismo sends the required information to the customer to validate the address in the following format along with the other payload data on the webhook.

Sample request:

{
	cardholder_postal_code : 12345
	cardholder_street_number : 999
	cardholder_street_address : Production St.
}

Sample response:

Expected response from zero balance, along with other response fields:

{
	match_address : true
	match_postal_code : true
	no_address_data : false
}

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 performs a cardholder verification method (CVM) validation to check 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: CVM

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": {}
}

Installments validation

This rule validates if there is a valid number of installments (greater than 1) when it is a installment purchase.

📘

This validation is performed for both zero balance and full balance integration.
This validation is specific to and performed only for ELO when the processing code is 15.

Name: INSTALLMENTS

Possible statuses: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Not yet mapped

Payload example:

{
    "name": "INSTALLMENTS",
    "status": "APPROVED",
    "reason": "INSTALLMENTS_VALID",
    "description": "Installments are valid",
    "additional_data": {}
}

DCC validation

This rule validates if it is a dynamic currency conversion (DCC) transaction and if the program allows this type of transaction. This validation is based on disableDCC config on the NetworkTransactionsProgramsConfig table.

📘

This validation is performed for both zero balance and full balance integration.

Name: DCC

Possible statuses: APPROVED, REJECTED, SKIPPED

Possible reasons:

Additional data: The additional_data field provides comprehensive details about the DCC transaction, including the custom code, program ID, whether DCC is enabled, the program's currency and country codes, as well as the transaction's currency and merchant country codes.

Fields: custom_code, program_id, is_dcc, is_disable_dcc_config, program_currency_code, program_country_code, transaction_currency_code, transaction_merchant_country_code

Payload example:

{
    "name": "DCC",
    "status": "APPROVED",
    "reason": "DCC_TRANSACTION_ALLOWED",
    "description": "DCC transaction not allowed for program 123",
    "additional_data": {
          "custom_code": "DCC",
          "program_id": 888,
          "is_dcc": true,
          "is_disable_dcc_config": true,
          "program_currency_code": "986",
          "program_country_code": "BRA",
          "transaction_currency_code": "986",
          "transaction_merchant_country_code": "USA"
  }
}

Currency validation (deprecated)

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 was deprecated and replaced by 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": {}
}

Message format validation

The Pismo platform validates if the message coming from the network has a valid format, domain, and values.

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

📘

This validation is performed for both zero balance and full balance integration.

Name: MESSAGE_FORMAT

Possible statuses: APPROVED, REJECTED

Possible reasons:

Additional data: Not yet mapped

Payload example:

{
    "name": "MESSAGE_FORMAT",
    "status": "APPROVED",
    "reason": "VALID_MESSAGE_FORMAT",
    "description": "Message is 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: additional_data contains card token information.

Fields: custom_code, tokenRequestor, token

Payload example:

{
    "name": "CARD_TOKEN",
    "status": "REJECTED",
    "reason": "CARD_TOKEN_NOT_FOUND",
    "description": "Card token not found.",
    "additional_data": {
       "custom_code": "Z26",
       "tokenRequestor": "23876743",
       "token": "87287343",
    }
}

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: additional_data contains card token status information.

Field: tokenStatus

Payload example:

{
    "name": "CARD_TOKEN_STATUS",
    "status": "APPROVED",
    "reason": "CARD_TOKEN_STATUS_VALID",
    "description": "Card token status: ACTIVE.",
    "additional_data": {
      "tokenStatus": "ACTIVE"
    }
}

Fetch program

To process the authorization flow, the Pismo platform fetches the program to use its configurations. The program and its configurations are required and when they are not present or are not valid, the authorization request is declined.

📘

This validation is performed for both zero balance and full balance integration.

Name: PROGRAM

Possible statuses: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: additional_data specifies the program ID.

Field: program_id

Payload example:

{
    "name": "PROGRAM",
    "status": "APPROVED",
    "reason": "PROGRAM_FOUND",
    "description": "Program 123 found.",
    "additional_data": {
          "program_id": 888
    }
}

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: APPROVED, REJECTED

Possible reasons:

Additional data: When the validation is REJECTED, the additional_data field contains the custom_code field with the custom rejection code. When the validation is APPROVED, the additional_data field provides details about the processing codes: processing_code_by_network contains card network codes and processing_code_mapped contains custom processing codes created by Pismo.

FIELDS:

When validation is REJECTED: custom_code

When validation is APPROVED: processing_code_by_network, processing_code_mapped

Payload examples:

{
    "name": "PROCESSING_CODE",
    "status": "REJECTED",
    "reason": "PROCESSING_CODE_GENERIC_ERROR",
    "description": "Unexpected error performing processing code.",
    "additional_data": {
       "custom_code": "PCE"
    }
}

{
        "name": "PROCESSING_CODE",
        "status": "APPROVED",
        "reason": "PROCESSING_CODE_FOUND",
        "description": "Processing code by network 00 and processing code mapped is 003100.",
        "additional_data": {
          "processing_code_by_network": "00",
          "processing_code_mapped": "003100"
        }
}

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": {}
}

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: additional_data specifies the type of card mode.

Field: mode_type

Payload example:

{
    "name": "CARD_MODE",
    "status": "APPROVED",
    "reason": "CARD_MODE_VALID",
    "description": "Valid card mode",
    "additional_data": {
          "mode_type": "CREDIT"
   }
}

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: additional_data contains the card mode status. This field is only filled in for APPROVED and REJECTED scenarios.

Fields: status, custom code

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: additional_data provides information related to the contactless feature, including whether it is enabled, the entry mode, and the presence of a token.

Fields: is_contactless_enabled, entry_mode, is_token_present

Payload example:

{
        "name": "CONTACTLESS",
        "status": "APPROVED",
        "reason": "CONTACTLESS_ENABLED",
        "description": "Contactless enabled.",
        "additional_data": {
          "is_contactless_enabled": true,
          "entry_mode": "051",
          "is_token_present": false
        }
 }

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: additional_data contains account type field and card mode.

Fields: account_type, card_mode

Payload example:

{
    "name": "ACCOUNT_TYPE",
    "status": "APPROVED",
    "reason": "ACCOUNT_TYPE_VALID",
    "description": "Account Type: CREDIT_CARD_ACCOUNT. Card Mode: CREDIT.",
    "additional_data": {
          "account_type": "CREDIT_CARD_ACCOUNT",
          "card_mode": "CREDIT"
        }
}

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: additional data contains important fields used in ATC validation.

Fields: inputted_card_atc, persisted_card_atc, is_advice, merchant_category

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": {
          "inputted_card_atc": "242",
          "persisted_card_atc": "[241,240,239,238,237,236,235,234,233,232,231,230,229,228,227,226,225,224,223,222,221,220,219,218,217,216,215,214,213,212,211,210,209,208,207,206,205,204,203,202,201,200,199,198,197,196,195,194,193,192,191,190,189,188,187,186,185,184,183,182,181,180,179,178,177,176,175,174,173,172,171,170,169,168,167,166,165,164,163,162,161,160,159,158,157,156,155,154,153,152,151,150,149,148,147,146,145,144,143,142,141,140,139,138,137,136,135,134,133,132,131,130,129,128,127,126,125,124,123,122,121,120,119,118,117,116,115,114,113,112,111,110,109,108,107,106,105,104,103,102,101,100,99,98,97,96,95,94,93,92,91,90,89,88,87,86,85,84,83,82,81,80,79,78,77,76,75,74,73,72,71,70,69,68,67,66,65,64,63,62,61,60,59,58,57,56,55,54,53,52,51,50,49,48,47,46,45,44,43,42,41,40,39,38,37,36,35,34,33,32,31,30,29,28,27,26,25,24,23,22,21,20,19,18,17,16,15,14,13,12,11,10,9,8,7,6,5,4,3,2,1]",
          "is_advice": false,
          "merchant_category": "XAS"
        }
}

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: additional_data contains fields used in the step to define the operation of the transaction.

Fields: org_id, processing_code, program_id

Payload example:

{
    "name": "OPERATION",
    "status": "APPROVED",
    "reason": "VALID_OPERATION",
    "description": "Valid operation (00) for OrgId (TN-OrgId) and ProgramId (123).",
    "additional_data": {
          "org_id": "TN-OrgId",
          "processing_code": "003100",
          "program_id": "888"
        }
}

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: additional_data provides detailed information about the password attempts, including the maximum number of allowed tries, the current number of attempts made, and whether any invalid passwords have been entered.

Fields: password_max_tries, password_tries, has_invalid_password

Payload example:

{
    "name": "PASSWORD_ATTEMPTS",
    "status": "APPROVED",
    "reason": "CARD_PASSWORD_ATTEMPTS_VALID",
    "description": "Password tries is valid.",
    "additional_data": {
          "password_max_tries": "4",
          "password_tries": "1",
          "has_invalid_password": false
   }
}

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 also performed on hardware security module (HSM) validations since this information is part of the CVV calculation but the platform performs this validation at this point because not every request goes through HSM validation.

📘

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: additional_data provides specific details about the card's expiration date, including the actual expiration date and the entered expiration date.

Fields: expiration_date, inputted_expiration_date

Payload example:

{
    "name": "CARD_INPUTTED_EXPIRATION_DATE",
    "status": "APPROVED",
    "reason": "CARD_INPUTTED_EXPIRATION_DATE_VALID",
    "description": "Card inputted expiration date is valid.",
    "additional_data": {
          "expiration_date": "2805",
          "inputted_expiration_date": "2805"
        }
}

Card expiration date validation

The Pismo platform validates whether the card is expired by the time of the authorization request. 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.
Field: expiration_date

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.
Field: valid_until

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: additional_data provides the specific status of the card.

Field: status

Payload example:

{
    "name": "CARD_STATUS",
    "status": "APPROVED",
    "reason": "CARD_STATUS_VALID",
    "description": "Card status: NORMAL.",
    "additional_data": {
          "status": "NORMAL"
     }
}

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: additional_data contains the account ID.

Field: account_id

Payload example:

{
    "name": "ACCOUNT",
    "status": "APPROVED",
    "reason": "ACCOUNT_FOUND",
    "description": "Account found.",
    "additional_data": {
      "account_id": "123"
    }
}

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: additional_data contains the account ID.

Field: account_id

Payload example:

{
    "name": "ACCOUNT_LIMITS",
    "status": "APPROVED",
    "reason": "ACCOUNT_LIMITS_FOUND",
    "description": "Account limits exists.",
    "additional_data": {
      "account_id": "123"
    }
}

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: additional_data contains the account status.

Field: status

Payload example:

{
    "name": "ACCOUNT_STATUS",
    "status": "APPROVED",
    "reason": "ACCOUNT_STATUS_VALID",
    "description": "Account has a valid status: true.",
    "additional_data": {
      "status": "NORMAL"
    }
}

Max installments number validation

The Pismo platform validates if the number of installments is less than or equal to the number configured for the program. This validation is based on maxInstallmentsNumber config on the NetworkTransactionsProgramsConfig table.

📘

This validation is performed only for full balance integration.

Name: MAX_INSTALLMENTS_NUMBER

Possible statuses: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: additional_data contains the program ID and the max number of Installments allowed for this program. This field is only filled in APPROVED and REJECTED status scenarios.

Fields: program_id, max_installments_number

Payload example:

{
    "name": "MAX_INSTALLMENTS_NUMBER",
    "status": "APPROVED",
    "reason": "MAX_INSTALLMENTS_NUMBER_VALID",
    "description": "Number of installments allowed for the program.",
    "additional_data": {
      "program_id": 123,
      "max_installments_number": 12
    }
}

Fetch impact information

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. The field custom_code is only present when the validation is REJECTED.

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: additional_data contains the number of transactions (transactions) and the maximum transactions limit (limit) for a temporary card. This field is only filled in APPROVED and REJECTED status scenarios.

Fields: limit, transactions

Payload example:

{
        "name": "MAX_TRANSACTIONS_FOR_TEMPORARY_CARD",
        "status": "APPROVED",
        "reason": "MAX_TRANSACTIONS_IF_TEMPORARY_CARD_APPROVED",
        "description": "The temporary card has limit for this transaction, limit: 2, number of transactions: 0",
        "additional_data": {
          "limit": 2,
          "transactions": 0
        }
}

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.

Field: transaction_limit

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

Pismo Authorization platform validates the accounts limits to define whether the amount of the authorization can be approved or not. At this moment, Ledger-API is called to proceed with the validation and impact of the account limits. Ledge also validates 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, max credit limit, and dry run indicator. These fields are only filled in for APPROVED status scenarios or the REJECTED reason LEDGER_INSUFFICIENT_BALANCE.

Validation results from Ledger will be available in additional_data for APPROVED and the following REJECTED reasons:

• LEDGER_INSUFFICIENT_BALANCE
• LEDGER_EXCEEDS_WITHDRAWAL_LIMIT
• LEDGER_NOT_ALLOWED_OPERATION

The dry_run_result field indicates the result for the dry run validation. For dry run validation, the Ledger validations are performed, but the account balance is not impacted. The dry run is performed for the following statuses:

• SKIPPED, except for cases where There is no Credit Impact configured for this operation
• REJECTED, for these reasons:
  • LEDGER_INSUFFICIENT_BALANCE
  • LEDGER_EXCEEDS_WITHDRAWAL_LIMIT
  • LEDGER_NOT_ALLOWED_OPERATION

The dry_run_result field indicates the result for the dry run validation. It will be passed when dry_run is true. Possible values for this field are:

• APPROVED—Ledger dry run approved
• REJECTED—Ledger dry run rejected
• TIMEOUT—Timeout calling Ledger dry run
• ERROR—Error calling Ledger dry run

Payload examples:

{
    "name": "LEDGER",
    "status": "APPROVED",
    "reason": "LEDGER_APPROVED",
    "description": "Ledger validations approved.",
    "additional_data": {
        "dry_run": false,
        "available_credit_limit": 1000.00,
        "total_credit_limit": 1000.00,
        "max_credit_limit": 1000.00,
        "validation_results": [
            {
                "account_id": 123456,
                "available_amounts": {
                    "details": {
                        "result": {
                            "overlimit": 0,
                            "held_funds": 0,
                            "additional_funds": 0,
                            "total_overdraft_limit": 0,
                            "available_credit_limit": 1000,
                            "available_withdraw_limit": 100,
                            "available_installment_limit": 0,
                            "available_savings_account_limit": 0
                        }
                    },
                    "validation_status": "APPROVED"
                },
                "ledger_operation_status": {
                    "validation_status": "APPROVED"
                }
            }
        ]
    }
}

{
    "name": "LEDGER",
    "status": "REJECTED",
    "reason": "LEDGER_INSUFFICIENT_BALANCE",
    "description": "Account limits is insufficient to perform transaction.",
    "additional_data": {
        "dry_run": true,
      	"dry_run_result": "REJECTED",
        "custom_code": "810",
        "available_credit_limit": 1000.0,
        "total_credit_limit": 15000.0,
        "max_credit_limit": 15000.0,
        "validation_results": [
            {
                "account_id": 123456,
                "available_amounts": {
                    "details": {
                        "mock_result": {
                            "overlimit": 0,
                            "held_funds": 0,
                            "additional_funds": 0,
                            "total_overdraft_limit": 0,
                            "available_credit_limit": -10.0,
                            "available_withdraw_limit": 200,
                            "available_installment_limit": 1000,
                            "available_savings_account_limit": 0
                        }
                    },
                    "validation_status": "REJECTED"
                },
                "ledger_operation_status": {
                    "validation_status": "APPROVED"
                }
            }
        ]
    }
}

{
    "name": "LEDGER",
    "status": "SKIPPED",
    "reason": "SKIPPED",
    "description": "Ledger validations skipped by dry run.",
    "additional_data": {
        "available_credit_limit": 4709.73,
        "total_credit_limit": 15000.0,
        "max_credit_limit": 15000.0,
        "dry_run": true,
        "dry_run_result": "APPROVED",
        "validation_results": [
            {
                "account_id": 123456,
                "ledger_operation_status": {
                    "validation_status": "APPROVED"
                },
                "available_amounts": {
                    "validation_status": "APPROVED",
                    "details": {
                        "result": {
                            "available_credit_limit": 4709.72,
                            "available_withdraw_limit": 450,
                            "available_installment_limit": 1000,
                            "available_savings_account_limit": 0,
                            "held_funds": 0,
                            "additional_funds": 0,
                            "total_overdraft_limit": 0,
                            "overlimit": 0
                        }
                    }
                }
            }
        ]
    }
}

Flex controls validation

The Pismo Authorization platform calls the Flex Controls API to evaluate the configured rules against the request being processed. If any rule fails, the request is declined.

Name: RULES

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

📘

Flex controls with Zero balance workflows

In Zero Balance workflows, the Pismo platform is not responsible for calculating currency exchange rates, fees, taxes, interest, tariffs, or any other financial components. These values are not provided to the platform.

Because the principal amount is the only monetary value received by the Pismo platform in Zero Balance workflows, and Pismo does not calculate any additional components (fees, taxes, interest, exchange rates, and so on), Flex Controls performs all validations and accumulations exclusively based on the principal amount, rather than the full contract amount.

As a result, the validation of the transaction amount and the accumulated amounts calculated by Flex Controls may be inaccurate when the principal amount differs from the contract amount (for example, principal amount + fees + taxes + interest, and so on).

Additional data: additional_data 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 filled in Approved and Operation Not Allowed scenarios.

The dry run information indicates if it is a dry run validation. For dry run validation, Flex Controls validations are performed, but rules values are not impacted/incremented. A dry run validation happens when the authorization already has a previous REJECTED validation or RULES validation is rejected for one of the following reasons:

• RULES_OPERATION_NOT_ALLOWED
• RULES_OPERATION_NOT_ALLOWED_CREDIT_VOUCHER

The Dry Run Result field indicates the result for the dry run validation. It will be passed when Dry Run is true. Possible values for this field are:

• APPROVED: Rules dry run approved
• REJECTED: Rules dry run rejected
• ERROR: Error calling Rules dry run

Fields:

• For reason RULES_APPROVED: dry_run, evaluated_controls
• For reason RULES_OPERATION_NOT_ALLOWED: dry_run, dry_run-result, denial_code, error_code, custom_code, evaluated_controls
• For reason RULES_INTERNAL_ERROR: dry_run, custom_code
• For reason SKIPPED: dry_run, dry_run_result, custom_code, evaluated_controls

Payload examples:

{
    "name": "RULES",
    "status": "REJECTED",
    "reason": "RULES_OPERATION_NOT_ALLOWED",
    "description": "Transaction not authorized as rule evaluation failed with error code [RULV10400], denial code [DENY_CODE], response code [63] and custom code [null]",
    "additional_data": {
      "dry_run": true,
        "dry_run_result": "REJECTED",
        "denial_code": "DENY_CODE",
        "error_code": "RULV10400",
        "custom_code": "RED",
        "evaluated_controls": [
            {
              "id": "id-rule-1",
              "name": "Rule 1",
              "message": "Message rule 1",
              "deny_code": "DENY_CODE",
              "response_code": "63",
              "available_limit": 0,
              "evaluation_result": false
            },
            {
              "id": "id-rule-2",
              "name": "Rule 2",
              "deny_code": "OTHER_DENY_CODE",
              "max_limit": 200000,
              "custom_code": "R01",
              "response_code": "63",
              "available_limit": 184951,
              "accumulated_limit": 15049,
              "evaluation_result": true
            }
        ]
    }
}

{
    "name": "RULES",
    "status": "SKIPPED",
    "reason": "SKIPPED",
    "description": "Rules evaluation skipped by dry run.",
    "additional_data": {
        "dry_run": true,
        "dry_run_result": "REJECTED",
        "custom_code": "RED",
        "evaluated_controls": [
            {
              "id": "id-rule-1",
              "name": "Rule 1",
              "message": "Message rule 1",
              "deny_code": "DENY_CODE",
              "response_code": "63",
              "available_limit": 0,
              "evaluation_result": false
            },
            {
              "id": "id-rule-2",
              "name": "Rule 2",
              "deny_code": "OTHER_DENY_CODE",
              "max_limit": 200000,
              "custom_code": "R01",
              "response_code": "63",
              "available_limit": 184951,
              "accumulated_limit": 15049,
              "evaluation_result": true
            }
        ]
    }
}

Anti-fraud validation

The Pismo Authorization platform calls an external endpoint to give the issuer the ability to perform any validation they wish. This endpoint can connect to an anti-fraud system or to the issuer themselves.

📘

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

Pismo Authorization platform performs all validations throughout the authorization flow. If anything breaks into the flow or any unexpected error happens that is not mapped on this list of validations and errors, an 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: additional_data will always contain the custom_code field since this validation is present only when an unexpected error occurs.

Field: custom_code

Payload example:

{
    "name": "UNKNOWN_ERROR",
    "status": "REJECTED",
    "reason": "UNKNOWN_ERROR",
    "description": "An unexpected error occurred.",
    "additional_data": {
        "custom_code": "OP1"
    }
}

Internal communication errors

Pismo Authorization platform consists of some APIs that together perform all the authorization request flow. If there is any communication error between those APIs before the Authorization system gets the message and build the validation result map, an error will be thrown and a denial response will be sent to the network. To identify these errors, you must look into the Card Network Authorization Return event, that shows the exact message the Pismo Authorization platform sent to the network. The table below shows the Response Code and Custom Code used for those timeout errors. The table below list the response codes and custom codes used for these timeout errors.

Fetch parameters

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 integration.

Name: PARAMETER

Possible Status: APPROVED, REJECTED

Possible Reasons:

Additional data: additional_data contains the program ID. This field is only filled in for APPROVED and REJECTED status scenarios.

Field: program_id

Payload example:

{
    "name": "PARAMETER",
    "status": "APPROVED",
    "reason": "PARAMETER_FOUND",
    "description": "Parameter by program found.",
    "additional_data": {
        "program_id": 1
    }
}