# Rule list

The rules used by the Pismo platform to validate transactions are listed below. Refer to [Authorization validation rules for card network operations](https://developers.pismo.io/pismo-docs/docs/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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

> 📘
>
> In this guide, table entries marked **N/A** indicate **Not Applicable**.

**Name:** MAGNETIC\_STRIPE

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        MAGNETIC\_STRIPE\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Magnetic Stripe present and validated.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        DEBIT\_ECOMMERCE\_TRANSACTION
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        E-commerce debit transactions might have a Magnetic Stripe built-in by the network. Validation is skipped in this scenario.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        NO\_MAGNETIC\_STRIPE
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        No Magnet Stripe in the request, so no need for this validation.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        NO\_MAGNETIC\_STRIPE\_WITH\_CRYPTOGRAM
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Request contains cryptogram information, so no need for this validation.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        NO\_MAGNETIC\_STRIPE\_WITH\_VALID\_CVV2
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Request contains CVV2 information, so no need for this validation.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        TOKENIZED\_TRANSACTION
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Request is tokenized, so no need for this validation. (Visa only)
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        COUNTRY\_NOT\_ALLOW\_MAGNETIC\_STRIPE
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Country doesn’t allow Magnetic Stripe operations, so the authorization request is denied.
      </td>

      <td>
        FR5
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* R9
        * *RuPay:*\* 57
        * *ELO:*\* 57
      </td>
    </tr>

    <tr>
      <td />

      <td />

      <td />

      <td />

      <td />
    </tr>
  </tbody>
</Table>

**Additional data:** Not yet mapped

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This feature is currently available for Mastercard and Visa.
</Callout>

## 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).

```json
{
	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:**

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

**Sample response:**

`name_Account_Match_Decision` values could be:

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

`account_Name_Request_Result` values could be:

```json
NAME_MATCH_PERFORMED,
NAME_MATCH_NOT_PERFORMED,
NAME_MATCH_NOT_SUPPORTED
```

```json
{
	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.

<Callout icon="📘" theme="info">
  Note: this feature is currently available for Mastercard and Visa.
</Callout>

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:**

```json
{
	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:

```json
{
	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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** ARQC

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        ARQC\_SIGNATURE\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        ARQC information present and valid.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        NO\_CRYPTOGRAM
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        No ARQC information present in request, so no need for this validation.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        INCOMPATIBLE\_PROCESSING\_CODE
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Request was a credit voucher with no ARQC information, so validation was skipped.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        ARQC\_INVALID
      </td>

      <td>
        REJECTED
      </td>

      <td>
        HSM declined the transaction, because the cryptogram information was invalid.
      </td>

      <td>
        FRN
      </td>

      <td>
        * *Visa:*\* 82
        * *Mastercard:*\* 63
        * *TecBan:*\* R9
        * *RuPay:*\* E3
        * *ELO:*\* 82
      </td>
    </tr>

    <tr>
      <td>
        HSM\_COMMUNICATION\_ERROR
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Internal error while calling the HSM.
      </td>

      <td>
        FRN
      </td>

      <td>
        * *Visa:*\* 82
        * *Mastercard:*\* 63
        * *TecBan:*\* R9
        * *RuPay:*\* E3
        * *ELO:*\* 82
      </td>
    </tr>

    <tr>
      <td>
        SHOULD\_HAVE\_CRYPTOGRAM
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Request entry mode is Chip (05), but doesn’t have cryptogram information.
      </td>

      <td>
        FRN
      </td>

      <td>
        * *Visa:*\* 82
        * *Mastercard:*\* 63
        * *TecBan:*\* R9
        * *RuPay:*\* E3
        * *ELO:*\* 82
      </td>
    </tr>

    <tr>
      <td>
        SHOULD\_NOT\_HAVE\_CRYPTOGRAM
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Request contains cryptogram information, but entry mode is not valid for chip operations.
      </td>

      <td>
        FRN
      </td>

      <td>
        * *Visa:*\* 82
        * *Mastercard:*\* 63
        * *TecBan:*\* R9
        * *RuPay:*\* E3
        * *ELO:*\* 82
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** Not yet mapped

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** CVM

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        PIN\_AND\_CVV\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        PIN or CVV present and the information was valid.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        SAFE\_TRANSACTION
      </td>

      <td>
        APPROVED
      </td>

      <td>
        No CVM information, but authorization was flagged as safe by the Acquirer/Network.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        VISA\_PROVISIONING\_VALIDATION\_REQUEST
      </td>

      <td>
        APPROVED
      </td>

      <td>
        No CVM information, but the authorization is a Visa Provisioning Validation request. (Visa only.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        RECURRING\_TRANSACTION\_WITH\_NO\_AUTH\_METHOD
      </td>

      <td>
        APPROVED
      </td>

      <td>
        No CVM information, but the transaction is Recurring.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        NO\_CVM\_TRANSACTION\_WITH\_NO\_AUTH\_METHOD
      </td>

      <td>
        APPROVED
      </td>

      <td>
        No CVM information, but the issuer enabled the NoCVM configuration to validate the authorization in the anti-fraud system.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        PRE\_AUTH\_TRANSACTION\_WITH\_NO\_AUTH\_METHOD
      </td>

      <td>
        APPROVED
      </td>

      <td>
        No CVM information, but the authorization was flagged as safe by the Acquirer/Network and is a pre-authorization. (Mastercard only).
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        MANUAL\_ENTRY\_MODE\_TRANSACTION\_WITH\_NO\_AUTH\_METHOD
      </td>

      <td>
        APPROVED
      </td>

      <td>
        No CVM information, but the authorization was performed using PAN Manual Entry (Entry Mode = 01).
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        HSM\_EMPTY\_RESPONSE
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        No response from HSM.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        ENTRY\_MODE\_NOT\_ALLOWED\_WITH\_NO\_CVM
      </td>

      <td>
        REJECTED
      </td>

      <td>
        No CVM information and none of the NoCVM exceptions were met to approve this request.
      </td>

      <td>
        NCV
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:* \*57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 57
      </td>
    </tr>

    <tr>
      <td>
        PIN\_INVALID
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Request contained incorrect PIN.
      </td>

      <td>
        FR6
      </td>

      <td>
        * *Visa:*\* 55
        * \*Mastercard:\*\*55
        * *TecBan:*\* 55
        * *RuPay:*\* 55
        * *ELO:*\* 55
      </td>
    </tr>

    <tr>
      <td>
        CVV1\_INVALID
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Request contained incorrect tracking data on Magnetic Stripe.
      </td>

      <td>
        FR1
      </td>

      <td>
        * *Visa:*\* 82
        * *Mastercard:*\* 63
        * *TecBan:*\* 57
        * *RuPay:*\* 05
        * *ELO:*\* 82
      </td>
    </tr>

    <tr>
      <td>
        CVV2\_INVALID
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Request contained incorrect CVV2 information.
      </td>

      <td>
        FR2
      </td>

      <td>
        * \*Visa:\*\*N7
        * *Mastercard:*\* 63
        * *TecBan:*\* 57
        * *RuPay:*\* 05
        * *ELO:*\* 63
      </td>
    </tr>

    <tr>
      <td>
        SERVICE\_CODE\_INVALID
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Internal Service Code to validate CVV was invalid or misconfigured.
      </td>

      <td>
        FR7
      </td>

      <td>
        * *Visa:*\* 14
        * *Mastercard:*\* 14
        * *TecBan:*\* 14
        * *RuPay:*\* 14
        * *ELO:*\* 14
      </td>
    </tr>

    <tr>
      <td>
        EXPIRATION\_DATE\_INVALID
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Expiration date provided in the network message (input by the cardholder) was invalid.
      </td>

      <td>
        CED
      </td>

      <td>
        * *Visa:*\* 54
        * *Mastercard:*\* 54
        * *TecBan:*\* 54
        * *RuPay:*\* 54
        * *ELO:*\* 54
      </td>
    </tr>

    <tr>
      <td>
        INCOMPLETE\_TRANSACTION
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Internal error on HSM response.
      </td>

      <td>
        OP1
      </td>

      <td>
        * *Visa:*\* 12
        * *Mastercard:*\* 30
        * *TecBan:*\* 30
        * *RuPay:*\* 30
        * *ELO:*\* 30
      </td>
    </tr>

    <tr>
      <td>
        GENERIC\_HSM\_ERROR
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Unexpected error from HSM processing.
      </td>

      <td>
        OP1
      </td>

      <td>
        * *Visa:*\* 05
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 05
      </td>
    </tr>

    <tr>
      <td>
        HSM\_UNKNOWN\_ERROR\_RESPONSE
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Unknown error response from HSM processing.
      </td>

      <td>
        OP1
      </td>

      <td>
        * *Visa:*\* 05
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 05
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** Not yet mapped

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** ENTRY\_MODE

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        ENTRY\_MODE\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Entry mode is valid, based on the cryptogram information.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        TRANSACTION\_HAS\_NO\_CRYPTOGRAM
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Entry mode is Chip (05), but there is no cryptogram information in the request.
      </td>

      <td>
        FRE
      </td>

      <td>
        * *Visa:*\* 63
        * *Mastercard:* \*57
        * *TecBan:*\* R9
        * *RuPay:*\* E3
        * *ELO:*\* 82
      </td>
    </tr>

    <tr>
      <td>
        TRANSACTION\_HAS\_CRYPTOGRAM
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Entry mode is not Chip or Contactless, but the operation contains cryptogram information.
      </td>

      <td>
        FRE
      </td>

      <td>
        * *Visa:*\* 63
        * *Mastercard:*\* 57
        * *TecBan:*\* R9
        * *RuPay:*\* E3
        * *ELO:*\* 82
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** Not yet mapped

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  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`.
</Callout>

**Name:** INSTALLMENTS

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        INSTALLMENTS\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Installments are valid.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        INVALID\_INSTALLMENTS\_NUMBER
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Invalid number of installments.
      </td>

      <td>
        OP1
      </td>

      <td>
        * *Visa:*\* 12
        * *Mastercard:* \*30
        * *TecBan:*\* 30
        * *RuPay:*\* 30
        * *ELO:*\* 30
      </td>
    </tr>

    <tr>
      <td>
        NOT\_INSTALLMENT\_TRANSACTION
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        It is not an installment transaction.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** Not yet mapped

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** DCC

**Possible statuses:** APPROVED, REJECTED, SKIPPED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        DCC\_TRANSACTION\_ALLOWED
      </td>

      <td>
        APPROVED
      </td>

      <td>
        DCC transaction allowed for program.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        DCC\_TRANSACTION\_NOT\_ALLOWED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        DCC transaction not allowed for program.
      </td>

      <td>
        DCC
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:* \*57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 57
      </td>
    </tr>

    <tr>
      <td>
        DCC\_INVALID\_COUNTRY
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Invalid country for DCC definition.
      </td>

      <td>
        DIC
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:* \*57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 57
      </td>
    </tr>

    <tr>
      <td>
        DCC\_INVALID\_CURRENCY
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Invalid currency for DCC definition.
      </td>

      <td>
        DIY
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:* \*57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 57
      </td>
    </tr>

    <tr>
      <td>
        NOT\_DCC\_TRANSACTION
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        It is not a DCC transaction.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        DCC\_INVALID\_PROGRAM
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Invalid program for DCC definition.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>
  </tbody>
</Table>

**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:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

<Callout icon="📘" theme="info">
  This validation was deprecated and replaced by DCC validation.
</Callout>

**Name:** CURRENCY

**Possible statuses:** APPROVED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CURRENCY\_ALLOWED
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Purchase is not in Brazilian currency or it originates in Brazil.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CURRENCY\_NOT\_ALLOWED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Purchase uses Brazilian currency, and it is for an international merchant.
      </td>

      <td>
        DCC
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 57
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** Not yet mapped

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** TERMINAL\_CAPABILITY

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        TERMINAL\_CAPABILITY\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Terminal has the capability to process the received entry mode.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        TERMINAL\_CAPABILITY\_UNKNOWN
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        No mapping for the received terminal capability.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        TERMINAL\_CAPABILITY\_INVALID
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Terminal doesn’t have the capability to process the received entry mode.
      </td>

      <td>
        FRH
      </td>

      <td>
        * *Visa:*\* 58
        * *Mastercard:*\* 58
        * *TecBan:*\* 58
        * *RuPay:*\* 58
        * *ELO:*\* 58
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** Not yet mapped

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

<Callout icon="📘" theme="info">
  This rule today is only applied to Visa processing.
</Callout>

**Name:** CHIP\_VALUES

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CHIP\_VALUES\_MATCH
      </td>

      <td>
        APPROVED
      </td>

      <td>
        ARQC information matched with authorization message information.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        PROCESSING\_CODE\_WITHDRAWAL
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Validation is skipped for withdrawals, because some values are expected to be different.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        TRANSACTION\_HAS\_NO\_CHIP
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Operation not being processed using Chip, so no need for this validation.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        CHIP\_TRANSACTION\_AMOUNT\_DOES\_NOT\_MATCH
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Amount of the transaction is different from the amount of the transaction in the Chip Information.
      </td>

      <td>
        FRE
      </td>

      <td>
        * *Visa:*\* 63
        * *Mastercard:*\* 57
        * *TecBan:*\* R9
        * *RuPay:*\* E3
        * *ELO:*\* 82
      </td>
    </tr>

    <tr>
      <td>
        CHIP\_TRANSACTION\_COUNTRY\_DOES\_NOT\_MATCH
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Country of the transaction is different from the country of the transaction in the Chip Information.
      </td>

      <td>
        FRE
      </td>

      <td>
        * *Visa:*\* 63
        * *Mastercard:*\* 57
        * *TecBan:*\* R9
        * *RuPay:*\* E3
        * *ELO:*\* 82
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** Not yet mapped

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** CHIP\_SIGNATURE

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CHIP\_SIGNATURE\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Validation method used is valid.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        NO\_CHIP\_SIGNATURE
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        No chip information, so no need for this validation.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        CHIP\_SIGNATURE\_DEPRECATED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Transaction performed using Paper Signature as validation method.
      </td>

      <td>
        FR0
      </td>

      <td>
        * *Visa:*\* 82
        * *Mastercard:*\* 88
        * *TecBan:*\* R9
        * *RuPay:*\* 81
        * *ELO:*\* 82
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** Not yet mapped

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** MESSAGE\_FORMAT

**Possible statuses:** APPROVED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        VALID\_MESSAGE\_FORMAT
      </td>

      <td>
        APPROVED
      </td>

      <td>
        The message is valid.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        INVALID\_MESSAGE\_FORMAT
      </td>

      <td>
        REJECTED
      </td>

      <td>
        The message is invalid.
      </td>

      <td>
        IMF
      </td>

      <td>
        * *Visa:*\* 12 or 5C
        * *Mastercard:*\* 30
        * *TecBan:*\* 30
        * *RuPay:*\* 30
        * *ELO:*\* 30
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** Not yet mapped

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** CARD\_EXISTS

**Possible statuses:** APPROVED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CARD\_FOUND
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Card found in the database.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card not found in the database.
      </td>

      <td>
        998
      </td>

      <td>
        * *Visa:*\* 14
        * *Mastercard:*\* 14
        * *TecBan:*\* 56
        * *RuPay:*\* 14
        * *ELO:*\* 14
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** `additional_data` contains the card type. This field is only filled in for APPROVED and REJECTED status scenarios.

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** CARD\_TOKEN

**Possible statuses:** APPROVED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CARD\_FOUND
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Valid card found in the database using the token.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_TOKEN\_NOT\_FOUND
      </td>

      <td>
        REJECTED
      </td>

      <td>
        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.
      </td>

      <td>
        Z26
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 14
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 12
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** `additional_data` contains card token information.

**Fields:** `custom_code`, `tokenRequestor`, `token`

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** CARD\_TOKEN\_STATUS

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CARD\_TOKEN\_STATUS\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Token found and has status ACTIVE.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        SKIPPED
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Authorization is not Tokenized, or it is a credit voucher or payment authorization request.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        CARD\_TOKEN\_DEACTIVATED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Token has status DEACTIVATED.
      </td>

      <td>
        Z23
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 12
      </td>
    </tr>

    <tr>
      <td>
        CARD\_TOKEN\_FAILED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Token has status FAILED.
      </td>

      <td>
        Z29
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 12
      </td>
    </tr>

    <tr>
      <td>
        CARD\_TOKEN\_INACTIVE
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Token has status INACTIVE.
      </td>

      <td>
        Z24
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 12
      </td>
    </tr>

    <tr>
      <td>
        CARD\_TOKEN\_SUSPENDED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Token has status SUSPENDED.
      </td>

      <td>
        Z22
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 12
      </td>
    </tr>

    <tr>
      <td>
        CARD\_TOKEN\_STATUS\_UNKNOWN
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Token has a status that is not mapped by the authorization system, and it is different from ACTIVE.
      </td>

      <td>
        Z27
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 12
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** `additional_data` contains card token status information.

**Field:** `tokenStatus`

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** PROGRAM

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        PROGRAM\_FOUND
      </td>

      <td>
        APPROVED
      </td>

      <td>
        The program was found.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        If card was not found, there is no way to find out the program or account hence this validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        PROGRAM\_NOT\_FOUND
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Program was not found.
      </td>

      <td>
        PRN
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>

    <tr>
      <td>
        PROGRAM\_GENERIC\_ERROR
      </td>

      <td>
        REJECTED
      </td>

      <td>
        An unexpected error has happened while fetching the program.
      </td>

      <td>
        PRE
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>

    <tr>
      <td>
        PROGRAM\_TIMEOUT
      </td>

      <td>
        REJECTED
      </td>

      <td>
        A timeout occurred while fetching program.
      </td>

      <td>
        PRT
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>

    <tr>
      <td>
        PROGRAM\_INVALID\_CURRENCY
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Program has invalid currency code.
      </td>

      <td>
        PIC
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 57
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** `additional_data` specifies the program ID.

**Field:** `program_id`

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** PROCESSING\_CODE

**Possible statuses:** APPROVED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        PROCESSING\_CODE\_FOUND
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Processing code was found.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        PROCESSING\_CODE\_GENERIC\_ERROR
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Unexpected error occurred while calling the API that defines the processing code to be used.
      </td>

      <td>
        PCE
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>

    <tr>
      <td>
        PROCESSING\_CODE\_TIMEOUT
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Timeout occurred while calling the API that defines the processing code to be used.
      </td>

      <td>
        PCT
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>
  </tbody>
</Table>

**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:**

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

```json
{
        "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** PLATFORM\_CONFIG

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        PLATFORM\_CONFIG\_FOUND
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Valid configuration  found.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        If card is not found, there is no way to find the platform or account, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        PLATFORM\_CONFIG\_NOT\_FOUND
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Configuration not found.
      </td>

      <td>
        MPC
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>

    <tr>
      <td>
        PLATFORM\_CONFIG\_GENERIC\_ERROR
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Unexpected error occurred while fetching the configurations.
      </td>

      <td>
        PCE
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** Not yet mapped

**Payload example:**

```json
{
    "name": "PLATFORM_CONFIG",
    "status": "APPROVED",
    "reason": "PLATFORM_CONFIG_FOUND",
    "description": "Platform Config found.",
    "additional_data": {}
}
```

# Card mode validation

This rule applies to [combination cards](https://developers.pismo.io/pismo-docs/docs/cards-overview-1#create-a-combination-card-with-card-modes). 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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** CARD\_MODE

**Possible statuses:** APPROVED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CARD\_MODE\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Card mode is valid and enabled for the operation or the card is not a combination card with modes.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_MODE\_INVALID
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card mode not enabled for  operation. For example, the purchase is in the credit mode, but the card has only the debit mode enabled.
      </td>

      <td>
        CMD
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * \*RuPay:\*\*57
          **ELO:**\
          57 (invalid mode)\
          AB (debit)\
          AC (credit)
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** `additional_data`  specifies the type of card mode.

**Field:** `mode_type`

**Payload example:**

```json
{
    "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](https://developers.pismo.io/pismo-docs/docs/cards-overview-1#create-a-combination-card-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:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CARD\_MODE\_STATUS\_ACTIVE
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Card mode status: ACTIVE
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_MODE\_STATUS\_DEBIT\_INACTIVE
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Status with  INACTIVE mode
      </td>

      <td>
        CMD
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * \*RuPay:\*\*57
          **ELO:**\
          57 (invalid mode)\
          AB (debit)\
          AC (credit)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_MODE\_STATUS\_DEBIT\_SUSPENDED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Status with SUSPENDED mode
      </td>

      <td>
        CMD
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * \*RuPay:\*\*57
          **ELO:**\
          57 (invalid mode)\
          AB (debit)\
          AC (credit)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_MODE\_STATUS\_CREDIT\_INACTIVE
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Status with INACTIVE  mode
      </td>

      <td>
        CMD
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * \*RuPay:\*\*57
          **ELO:**\
          57 (invalid mode)\
          AB (debit)\
          AC (credit)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_MODE\_STATUS\_CREDIT\_SUSPENDED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Status with SUSPENDED  mode
      </td>

      <td>
        CMD
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * \*RuPay:\*\*57
          **ELO:**\
          57 (invalid mode)\
          AB (debit)\
          AC (credit)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_MODE\_STATUS\_NOT\_FOUND
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Statusless mode
      </td>

      <td>
        CMD
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * \*RuPay:\*\*57
          **ELO:**\
          57 (invalid mode)\
          AB (debit)\
          AC (credit)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_MODE\_STATUS\_SKIPPED
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card with mode type other than COMBO
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>
  </tbody>
</Table>

**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**

```json
{
  "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** CONTACTLESS

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CONTACTLESS\_ENABLED
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Contactless is enabled or the operation is not using contactless entry mode (07)
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card not found, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        CONTACTLESS\_DISABLED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Authorization has entry mode contactless (07), and this function is disabled for this card.
      </td>

      <td>
        UBN
      </td>

      <td>
        * *Visa:*\* 78
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 78
      </td>
    </tr>
  </tbody>
</Table>

**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:**

```json
{
        "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** ACCOUNT\_TYPE

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        ACCOUNT\_TYPE\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        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.)
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card not found, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        ACCOUNT\_TYPE\_INVALID
      </td>

      <td>
        REJECTED
      </td>

      <td>
        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.)
      </td>

      <td>
        IAT
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * \*RuPay:\*\*57
          **ELO:**\
          AB (debit)\
          AC (credit)
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** `additional_data` contains account type field and card mode.

**Fields:** `account_type`, `card_mode`

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** CARD\_ATC

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CARD\_ATC\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        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.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card not found, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        CARD\_ATC\_INVALID
      </td>

      <td>
        REJECTED
      </td>

      <td>
        ATC is duplicated or is outside the allowed range.
      </td>

      <td>
        FAT
      </td>

      <td>
        * *Visa:*\* 63
        * *Mastercard:*\* 63
        * *TecBan:*\* 01
        * *RuPay:*\* 05
        * *ELO:*\* 82
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** `additional data` contains important fields used in ATC validation.

**Fields:** `inputted_card_atc`, `persisted_card_atc`, `is_advice`, `merchant_category`

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed only for full balance integration.
</Callout>

**Name:** OPERATION

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        VALID\_OPERATION
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Operation is configured and is allowed by the issuer for the program of the card that was used.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card not found, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        OPERATION\_NOT\_ALLOWED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Operation not configured by the issuer for the program of the card that was used.
      </td>

      <td>
        ANF
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 57
      </td>
    </tr>
  </tbody>
</Table>

**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:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** PASSWORD\_ATTEMPTS

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CARD\_PASSWORD\_ATTEMPTS\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Password was not needed or the correct password was entered before the allowed number of attempts was exceeded.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card not found, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        CARD\_PASSWORD\_ATTEMPTS\_EXCEEDED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card was blocked because the allowed number of attempts was exceeded.
      </td>

      <td>
        TSM
      </td>

      <td>
        * *Visa:*\* 75
        * *Mastercard:*\* 75
        * *TecBan:*\* 38
        * *RuPay:*\* 75
        * *ELO:*\* 38
      </td>
    </tr>
  </tbody>
</Table>

**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:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** CARD\_INPUTTED\_EXPIRATION\_DATE

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CARD\_INPUTTED\_EXPIRATION\_DATE\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Correct expiration date entered.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card not found, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        CARD\_INPUTTED\_EXPIRATION\_DATE\_MISMATCH
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Incorrect expiration date entered.
      </td>

      <td>
        CED
      </td>

      <td>
        * *Visa:*\* 54
        * *Mastercard:*\* 54
        * *TecBan:*\* 54
        * *RuPay:*\* 54
        * *ELO:*\* 54
      </td>
    </tr>
  </tbody>
</Table>

**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:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** CARD\_EXPIRATION\_DATE

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CARD\_NOT\_EXPIRED
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Registered card expiration date is after the current time of the authorization request.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card not found, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        CARD\_EXPIRED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Registered card expiration date is before the current time of the authorization request.
      </td>

      <td>
        VNM
      </td>

      <td>
        * *Visa:*\* 54
        * *Mastercard:*\* 54
        * *TecBan:*\* 54
        * *RuPay:*\* 54
        * *ELO:*\* 54
      </td>
    </tr>
  </tbody>
</Table>

**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:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** CARD\_VALID\_UNTIL

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CARD\_VALID\_UNTIL\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        "Until date" is after the current time of the authorization request.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card not found, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        CARD\_VALID\_UNTIL\_INVALID
      </td>

      <td>
        REJECTED
      </td>

      <td>
        "Until date" is before the current time of the authorization request.
      </td>

      <td>
        VEV
      </td>

      <td>
        * *Visa:*\* 54
        * *Mastercard:*\* 54
        * *TecBan:*\* 54
        * *RuPay:*\* 54
        * *ELO:*\* 54
      </td>
    </tr>
  </tbody>
</Table>

**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:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** CARD\_STATUS

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CARD\_STATUS\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Card has status NORMAL or REISSUED.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card not found, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        CARD\_STATUS\_INVALID\_CREATED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card has status CREATED.
      </td>

      <td>
        FRB
      </td>

      <td>
        * *Visa:*\* 78
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 78
      </td>
    </tr>

    <tr>
      <td>
        CARD\_STATUS\_INVALID\_BLOCKED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card has status BLOCKED.
      </td>

      <td>
        UBT
      </td>

      <td>
        * *Visa:*\* 78
        * *Mastercard:*\* 57
        * *TecBan:*\* 76
        * *RuPay:*\* 57
        * *ELO:*\* 78
      </td>
    </tr>

    <tr>
      <td>
        CARD\_STATUS\_INVALID\_WARNING
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card has status WARNING.
      </td>

      <td>
        BNW
      </td>

      <td>
        * *Visa:*\* 59
        * *Mastercard:*\* 63
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 62
      </td>
    </tr>

    <tr>
      <td>
        CARD\_STATUS\_INVALID\_CANCELED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card has status CANCELED.
      </td>

      <td>
        BND
      </td>

      <td>
        * *Visa:*\* 46
        * *Mastercard:*\* 62
        * *TecBan:*\* 57
        * *RuPay:*\* 62
        * *ELO:*\* 46
      </td>
    </tr>

    <tr>
      <td>
        CARD\_STATUS\_INVALID\_CLIENTORDER
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card has status CLIENTORDER.
      </td>

      <td>
        BND
      </td>

      <td>
        * *Visa:*\* 46
        * *Mastercard:*\* 62
        * *TecBan:*\* 57
        * *RuPay:*\* 62
        * *ELO:*\* 46
      </td>
    </tr>

    <tr>
      <td>
        CARD\_STATUS\_INVALID\_FRAUD
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card has status FRAUD.
      </td>

      <td>
        BNF
      </td>

      <td>
        * *Visa:*\* 07
        * *Mastercard:*\* 04
        * *TecBan:*\* 57
        * *RuPay:*\* 04
        * *ELO:*\* 57
      </td>
    </tr>

    <tr>
      <td>
        CARD\_STATUS\_INVALID\_LOST
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card has status LOST.
      </td>

      <td>
        BNP
      </td>

      <td>
        * *Visa:*\* 41
        * *Mastercard:*\* 41
        * *TecBan:*\* 41
        * *RuPay:*\* 41
        * *ELO:*\* 41
      </td>
    </tr>

    <tr>
      <td>
        CARD\_STATUS\_INVALID\_ROBBED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card has status ROBBED.
      </td>

      <td>
        BNR
      </td>

      <td>
        * *Visa:*\* 43
        * *Mastercard:*\* 43
        * *TecBan:*\* 43
        * *RuPay:*\* 43
        * *ELO:*\* 43
      </td>
    </tr>

    <tr>
      <td>
        CARD\_STATUS\_INVALID\_THEFT
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card has status THEFT.
      </td>

      <td>
        BNR
      </td>

      <td>
        * *Visa:*\* 43
        * *Mastercard:*\* 43
        * *TecBan:*\* 43
        * *RuPay:*\* 43
        * *ELO:*\* 43
      </td>
    </tr>

    <tr>
      <td>
        CARD\_STATUS\_INVALID\_DELETED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card has status DELETED.
      </td>

      <td>
        VED
      </td>

      <td>
        * *Visa:*\* 46
        * *Mastercard:*\* 57
        * *TecBan:*\* 56
        * *RuPay:*\* 57
        * *ELO:*\* 46
      </td>
    </tr>

    <tr>
      <td>
        CARD\_STATUS\_INVALID\_DAMAGED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card has status DAMAGED.
      </td>

      <td>
        BNM
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 56
        * *RuPay:*\* 57
        * *ELO:*\* 57
      </td>
    </tr>

    <tr>
      <td>
        CARD\_STATUS\_INVALID\_UNRECEIVED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card has status UNRECEIVED.
      </td>

      <td>
        BNU
      </td>

      <td>
        * *Visa:*\* 41
        * *Mastercard:*\* 41
        * *TecBan:*\* 41
        * *RuPay:*\* 57
        * *ELO:*\* 14
      </td>
    </tr>

    <tr>
      <td>
        CARD\_STATUS\_INVALID\_INOPERATIVE
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card has status INOPERATIVE.
      </td>

      <td>
        BNI
      </td>

      <td>
        * *Visa:*\* 14
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 14
      </td>
    </tr>

    <tr>
      <td>
        CARD\_STATUS\_UNKNOWN
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Card has a status that is not mapped in the authorization system.
      </td>

      <td>
        CSU
      </td>

      <td>
        * *Visa:*\* 14
        * *Mastercard:*\* 57
        * *TecBan:*\* 56
        * *RuPay:*\* 57
        * *ELO:*\* 14
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** `additional_data` provides the specific status of the card.

**Field:** `status`

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed only for Full Balance Flow.
</Callout>

**Name:** ACCOUNT

**Possible Status:** APPROVED, SKIPPED, REJECTED

**Possible Reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        ACCOUNT\_FOUND
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Account found.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        If card was not found, there is no way to find out the account.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        ACCOUNT\_NOT\_FOUND
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Account was not found.
      </td>

      <td>
        998
      </td>

      <td>
        * *Visa:*\* 14
        * *Mastercard:*\* 14
        * *TecBan:*\* 56
        * *RuPay:*\* 14
        * *ELO*\*: 14
      </td>
    </tr>

    <tr>
      <td>
        ACCOUNT\_GENERIC\_ERROR
      </td>

      <td>
        REJECTED
      </td>

      <td>
        An unexpected error has happened while fetching the account.
      </td>

      <td>
        AGE
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO*\*: 96
      </td>
    </tr>

    <tr>
      <td>
        ACCOUNT\_TIMEOUT
      </td>

      <td>
        REJECTED
      </td>

      <td>
        A timeout occurred while fetching account.
      </td>

      <td>
        ACT
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO*\*: 96
      </td>
    </tr>
  </tbody>
</Table>

**Additional Data:** `additional_data` contains the account ID.

**Field:** `account_id`

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed only for full balance integration.
</Callout>

**Name:** ACCOUNT\_LIMITS

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        ACCOUNT\_LIMITS\_FOUND
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Account limit details retrieved successfully.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card not found, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        LEDGER\_ACCOUNT\_NOT\_FOUND
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Account limit details not found.
      </td>

      <td>
        LNF
      </td>

      <td>
        * *Visa:*\* 14
        * *Mastercard:*\* 14
        * *TecBan:*\* 56
        * *RuPay:*\* 14
        * *ELO:*\* 14
      </td>
    </tr>

    <tr>
      <td>
        LEDGER\_ACCOUNT\_TIMEOUT
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Timeout occurred  while retrieving account limit details.
      </td>

      <td>
        LCT
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *Tecban:*\* 06
        * *Rupay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>

    <tr>
      <td>
        LEDGER\_ACCOUNT\_GENERIC\_ERROR
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Unexpected error occurred while retrieving account limit details.
      </td>

      <td>
        LAE
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>

    <tr>
      <td />

      <td />

      <td />

      <td />

      <td />
    </tr>
  </tbody>
</Table>

**Additional data:** `additional_data` contains the account ID.

**Field:** `account_id`

**Payload example:**

```json
{
    "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`.

<Callout icon="📘" theme="info">
  This validation is performed only for full balance integration.
</Callout>

**Name:** ACCOUNT\_STATUS

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        ACCOUNT\_STATUS\_VALID
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Account is not blocked.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card not found, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        ACCOUNT\_STATUS\_INVALID
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Account is blocked.
      </td>

      <td>
        CND
      </td>

      <td>
        * *Visa:*\* 62
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 62
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** `additional_data` contains the account status.

**Field:** `status`

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed only for full balance integration.
</Callout>

**Name:** MAX\_INSTALLMENTS\_NUMBER

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

| Reason                                      | Status   | Description                                                     | Custom Code | Response Code         |
| :------------------------------------------ | :------- | :-------------------------------------------------------------- | :---------- | :-------------------- |
| MAX\_INSTALLMENTS\_NUMBER\_VALID            | APPROVED | Number of installments are allowed for the program.             | N/A         | 00 (for all networks) |
| MAX\_INSTALLMENTS\_NUMBER\_NOT\_INSTALLMENT | SKIPPED  | It is not an installment transaction.                           | N/A         | N/A                   |
| MAX\_INSTALLMENTS\_NUMBER\_INVALID          | REJECTED | Number of installments is greater than allowed for the program. | N/A         | N/A                   |

**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:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This is performed only for full balance integration.
</Callout>

**Name:** CREDIT\_LIMIT

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        CREDIT\_LIMIT\_IMPACT\_FOUND
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Impact information was found and is correctly configured.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        SKIPPED
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card not found, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        CREDIT\_LIMIT\_IMPACT\_NOT\_FOUND
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Impact not found or is configured incorrectly.
      </td>

      <td>
        998
      </td>

      <td>
        * *Visa:*\* 14
        * *Mastercard:*\* 14
        * *TecBan:*\* 56
        * *RuPay:*\* 14
        * *ELO:*\* 14
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** Not yet mapped

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed only for full balance integration.
</Callout>

**Name:** RATES

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        RATES\_APPROVED
      </td>

      <td>
        APPROVED
      </td>

      <td>
        All calculations performed successfully.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        SKIPPED
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card not found, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        RATES\_REJECT
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Unexpected error occurred while calculating the authorization amounts.
      </td>

      <td>
        RAE
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** Not yet mapped

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed only for full balance integration.
</Callout>

**Name:** STATEMENTS

**Possible statuses:** REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        INSUFFICIENT\_STATEMENTS
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Insufficient number of created statements to calculate installments.
      </td>

      <td>
        ISE
      </td>

      <td>
        * *Visa:*\* 5C
        * *Mastercard:*\* 57
        * *TecBan:*\* 06
        * *RuPay:*\* 57
        * *ELO:*\* 57
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** Not yet mapped. The field `custom_code` is only present when the validation is REJECTED.

**Payload example:**

```json
{
    "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](https://developers.pismo.io/pismo-docs/reference/updateprogramparameter). If this parameter is not set, or the card is not of type `TEMPORARY`, this validation is not performed.

<Callout icon="📘" theme="info">
  This validation is performed only for full balance integration.
</Callout>

**Name:** MAX\_TRANSACTIONS\_FOR\_TEMPORARY\_CARD

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        MAX\_TRANSACTIONS\_IF\_TEMPORARY\_CARD\_APPROVED
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Card is temporary and the number of transactions is under the configured threshold.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        CARD\_NOT\_FOUND
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card not found, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        MAX\_TRANSACTIONS\_IF\_TEMPORARY\_CARD\_SKIPPED
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card is not temporary.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        MAX\_TRANSACTIONS\_IF\_TEMPORARY\_CARD\_EXCEEDED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Number of transactions performed using temporary card exceeded the configured threshold.
      </td>

      <td>
        CTE
      </td>

      <td>
        * *Visa:*\* 54
        * *Mastercard:*\* 54
        * *Tecban:*\* 54
        * *Rupay:*\* 54
        * *ELO:*\* 54
      </td>
    </tr>
  </tbody>
</Table>

**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:**

```json
{
        "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.

<Callout icon="📘" theme="info">
  This validation is performed only for full balance integration.
</Callout>

**Name:** CARD\_TRANSACTION\_LIMIT

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        LIMIT\_APPROVED
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Maximum transaction limit is greater than the amount of the authorization request.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        SKIPPED
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Card not found, so validation can’t be performed.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        LIMIT\_INSUFFICIENT\_FUNDS
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Transaction amount is greater than the maximum transaction limit configured for the card.
      </td>

      <td>
        810
      </td>

      <td>
        * *Visa:*\* 51
        * *Mastercard:*\* 51
        * *TecBan:*\* 51
        * *RuPay:*\* 51
        * *ELO:*\* 51
      </td>
    </tr>
  </tbody>
</Table>

**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:**

```json
{
    "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](https://developers.pismo.io/pismo-docs/reference/get-v1-account-limit) 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.

<Callout icon="📘" theme="info">
  This validation is performed only for full balance integration.
</Callout>

**Name:** LEDGER

**Possible statuses:** APPROVED, SKIPPED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        LEDGER\_APPROVED
      </td>

      <td>
        APPROVED
      </td>

      <td>
        All available limits were successfully validated and the authorization can proceed.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        SKIPPED
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        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.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        LEDGER\_INSUFFICIENT\_BALANCE
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Authorization request is greater than the account available limits.
      </td>

      <td>
        810
      </td>

      <td>
        * *Visa:*\* 51
        * *Mastercard:*\* 51
        * *TecBan:*\* 51
        * *RuPay:*\* 51
        * *ELO:*\* 51
      </td>
    </tr>

    <tr>
      <td>
        LEDGER\_EXCEEDS\_WITHDRAWAL\_LIMIT
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Authorization request is a withdrawal, and the amount is greater than the account available limits.
      </td>

      <td>
        810
      </td>

      <td>
        * *Visa:*\* 61
        * *Mastercard:*\* 61
        * *TecBan:*\* 61
        * *RuPay:*\* 61
        * *ELO:*\* 61
      </td>
    </tr>

    <tr>
      <td>
        LEDGER\_NOT\_ALLOWED\_OPERATION
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Account is blocked from receiving debits or credits.
      </td>

      <td>
        CND
      </td>

      <td>
        * *Visa:*\* 62
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 62
      </td>
    </tr>

    <tr>
      <td>
        LEDGER\_DUPLICATED\_TRACKING\_ID
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Internal error caused a duplicated tracking ID while calling Ledger.
      </td>

      <td>
        LUD
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>

    <tr>
      <td>
        LEDGER\_LIMIT\_UPDATE\_ERROR
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Unexpected error occurred while calling Ledger.
      </td>

      <td>
        LUE
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>

    <tr>
      <td>
        LEDGER\_TIMEOUT
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Timeout occurred while calling Ledger.
      </td>

      <td>
        LUT
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>
  </tbody>
</Table>

**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:**

```json
{
    "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"
                }
            }
        ]
    }
}
```

```json
{
    "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"
                }
            }
        ]
    }
}
```

```Text JSON
{
    "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
                        }
                    }
                }
            }
        ]
    }
}
```

<br />

# Flex controls validation

The Pismo Authorization platform calls the [Flex Controls API](https://developers.pismo.io/pismo-docs/reference/post-v1-customers-flex-controls) 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:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        RULES\_APPROVED
      </td>

      <td>
        APPROVED
      </td>

      <td>
        All rules were successfully evaluated and approved.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        SKIPPED
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        There was a preview denial in the authorization flow, so Rules validation will be called in dry run mode.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        RULES\_NOT\_ENABLED
      </td>

      <td>
        SKIPPED
      </td>

      <td>
        Flex controls evaluation not enabled for that program/account/card, so the API will not be called.
      </td>

      <td>
        N/A
      </td>

      <td>
        N/A
      </td>
    </tr>

    <tr>
      <td>
        RULES\_OPERATION\_NOT\_ALLOWED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Flex controls evaluation reported that some rules declined this request.
      </td>

      <td>
        The custom code configured in Flex Controls API for the evaluated rule. If there is no custom code configured, RED will be used.
      </td>

      <td>
        * *Visa:*\* 78
        * *Mastercard:*\* 05
        * *TecBan:*\* 05
        * *RuPay:*\* 05
        * *ELO:*\* 57
      </td>
    </tr>

    <tr>
      <td>
        RULES\_DO\_NOT\_HONOR
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Flex controls evaluation reported the request declined.
      </td>

      <td>
        RED
      </td>

      <td>
        * *Visa:*\* 78
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 57
      </td>
    </tr>

    <tr>
      <td>
        RULES\_INTERNAL\_ERROR
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Internal error occurred while calling Flex Controls API.
      </td>

      <td>
        RED
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>

    <tr>
      <td>
        RULES\_OPERATION\_NOT\_ALLOWED\_CREDIT\_VOUCHER
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Flex controls evaluation reported the request declined.
      </td>

      <td>
        RED
      </td>

      <td>
        * *Visa:*\* 59
        * *Mastercard:*\* 57
        * *TecBan:*\* 57
        * *RuPay:*\* 57
        * *ELO:*\* 57
      </td>
    </tr>
  </tbody>
</Table>

> 📘 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:**

```json
{
    "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
            }
        ]
    }
}
```

```json
{
    "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
            }
        ]
    }
}
```

<br />

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

<Callout icon="📘" theme="info">
  This validation is performed only for full balance integration.
</Callout>

**Name:** ANTI\_FRAUD

**Possible Statuses:** APPROVED, REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        ANTI\_FRAUD\_APPROVE
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Call to third-party endpoint was successful, and the request was approved.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        ANTI\_FRAUD\_FORCE\_APPROVE
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Call to third party endpoint was successful and forced the request to be approved by overriding the Pismo platform denial decision.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        ANTI\_FRAUD\_APPROVE\_BY\_DEFAULT
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Call to third-party endpoint has failed but it is configured to approve by default when unavailable and keep the Pismo platform decision.
      </td>

      <td>
        N/A
      </td>

      <td>
        ANTI\_FRAUD\_OVERRIDE\_REJECTION
      </td>
    </tr>

    <tr>
      <td>
        ANTI\_FRAUD\_OVERRIDE\_REJECTION
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Third-party endpoint has declined the request and overrode the Pismo platform response code.
      </td>

      <td>
        PFT
      </td>

      <td>
        Response Code returned in the response of the endpoint call.
      </td>
    </tr>

    <tr>
      <td>
        ANTI\_FRAUD\_REJECT
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Third party endpoint declined the request.
      </td>

      <td>
        PFT
      </td>

      <td>
        * *Visa:*\* 59
        * *Mastercard:*\* 63
        * *TecBan:*\* 57
        * *RuPay:*\* 63
        * *ELO:*\* 59
      </td>
    </tr>

    <tr>
      <td>
        ANTI\_FRAUD\_REFERRED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Third party endpoint declined the request and marked it as a referral.
      </td>

      <td>
        PFT
      </td>

      <td>
        * *Visa:*\* 59
        * *Mastercard:*\* 63
        * *TecBan:*\* 57
        * *RuPay:*\* 63
        * *ELO:*\* 59
      </td>
    </tr>

    <tr>
      <td>
        ANTI\_FRAUD\_OVERRIDE\_REFERRED
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Third party endpoint declined the request, marked it as a referral, and overrode the Pismo platform's response code.
      </td>

      <td>
        PFT
      </td>

      <td>
        Response Code returned in the response of the endpoint call.
      </td>
    </tr>

    <tr>
      <td>
        ANTI\_FRAUD\_UNAVAILABLE
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Call to third party endpoint failed, and the Pismo platform was not configured to approve by default when unavailable, so the request was declined.
      </td>

      <td>
        PFT
      </td>

      <td>
        * *Visa:*\* 59
        * *Mastercard:*\* 63
        * *TecBan:*\* 57
        * *RuPay:*\* 63
        * *ELO:*\* 59
      </td>
    </tr>
  </tbody>
</Table>

**Additional data:** Not yet mapped

**Payload example:**

```json
{
    "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.

<Callout icon="📘" theme="info">
  This validation is performed for both zero balance and full balance integration.
</Callout>

**Name:** UNKNOWN\_ERROR

**Possible Statuses:** REJECTED

**Possible reasons:**

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        UNKNOWN\_ERROR
      </td>

      <td>
        REJECTED
      </td>

      <td>
        Unexpected error occurred while processing authorization request.
      </td>

      <td>
        OP1
      </td>

      <td>
        * *Visa:*\* 05
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 05
      </td>
    </tr>
  </tbody>
</Table>

**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:**

```json
{
    "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](https://developers.pismo.io/pismo-docs/docs/authorization-events#card-network-authorization-return-event) 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.

<Table align={["left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        Error while connecting to the Authorization System API
      </td>

      <td>
        Unexpected error occurred when sending request to authorization system.
      </td>

      <td>
        ACE
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *Tecban:*\* 06
        * *Rupay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>

    <tr>
      <td>
        Error while connecting to the Distributor System API
      </td>

      <td>
        Unexpected error occurred when sending request to distributor system.
      </td>

      <td>
        DCE
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *Tecban:*\* 06
        * *Rupay:*\* 96
        * *ELO:*\* -
      </td>
    </tr>
  </tbody>
</Table>

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

<Callout icon="📘" theme="info">
  This validation is performed only for full balance integration.
</Callout>

**Name**: PARAMETER

**Possible Status**: APPROVED, REJECTED

**Possible Reasons**:

<Table align={["left","left","left","left","left"]}>
  <thead>
    <tr>
      <th>
        Reason
      </th>

      <th>
        Status
      </th>

      <th>
        Description
      </th>

      <th>
        Custom Code
      </th>

      <th>
        Response Code
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        PARAMETER\_FOUND
      </td>

      <td>
        APPROVED
      </td>

      <td>
        Parameters found.
      </td>

      <td>
        N/A
      </td>

      <td>
        00 (for all networks)
      </td>
    </tr>

    <tr>
      <td>
        PARAMETER\_GENERIC\_ERROR
      </td>

      <td>
        REJECTED
      </td>

      <td>
        An unexpected error has happened while fetching the parameters.
      </td>

      <td>
        PAE
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO*\*: 96
      </td>
    </tr>

    <tr>
      <td>
        PARAMETER\_TIMEOUT
      </td>

      <td>
        REJECTED
      </td>

      <td>
        A timeout occurred while fetching parameters.
      </td>

      <td>
        PAT
      </td>

      <td>
        * *Visa:*\* N0
        * *Mastercard:*\* 96
        * *TecBan:*\* 06
        * *RuPay:*\* 96
        * *ELO:*\* 96
      </td>
    </tr>
  </tbody>
</Table>

**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:**

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