This guide contains the full list of authorization rules used by the Pismo platform to validate requests. An authorization for platform operations builds a validation result map with the status of each validation. The validation result map contains a list of validation result objects. Each object contains information in the following fields.

Response and denial codes

Account retrieval

When the authorization request from the payment methods service is performed using a Pismo account ID, the platform validates whether that account ID is valid and exists in the database. If any error occurs, the request is declined.

Name: ACCOUNT

Possible statuses: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the account ID received in the request.

Fields: account_id

Payload example:

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

Account retrieval by bank account

When the payment methods authorization request is performed using the customer's bank, the platform validates whether that bank's information is valid and exists. If any error occurs or the account is not found based on the provided bank information, the request is declined.

Name: BANK_ACCOUNT

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the account ID returned by the external system.

Fields: account_id

Payload example:

{
	"name": "BANK_ACCOUNT",
	"status": "APPROVED",
	"reason": "BANK_ACCOUNT_FOUND",
	"description": "Bank account was found.",
	"additional_data": {
		"account_id": 9999
	}
}

Account retrieval by document number

When the payment methods authorization request is performed using a document number, the platform validates whether that document number is valid and exists. If any error occurs or the account is not found based on the provided document number, the request is declined.

Name: DOCUMENT_NUMBER

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the field indicating whether the document number is present.

Fields: document_number_present

Payload example:

{
    "name": "DOCUMENT_NUMBER",
    "status": "APPROVED",
    "reason": "DOCUMENT_NUMBER_FOUND",
    "description": "Account was found successfully based on document number.",
    "additional_data": {
        "document_number_present": true
    }
}

Account limits retrieval

Platform authorization retrieves the account limits information to process this authorization request and perform validations.

Name: ACCOUNT_LIMITS

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains current balances and limits.

Fields: available_credit_limit, available_total_installment_credit, available_withdrawal_credit, total_credit_limit, total_installment_credit_limit, withdrawal_credit_limit

Payload example:

{
    "name": "ACCOUNT_LIMITS",
    "status": "APPROVED",
    "reason": "ACCOUNT_LIMITS_FOUND",
    "description": "Account limits were found.",
    "additional_data": {
    	  "available_credit_limit": 87459.76,
        "available_total_installment_credit": 179.2,
        "available_withdrawal_credit": 4,
        "total_credit_limit": 0,
        "total_installment_credit_limit": 500,
        "withdrawal_credit_limit": 500
    }
}

Account status validation

Platform authorization performs the account status validation to verify whether the account is allowed to perform the request.

Name: ACCOUNT_STATUS

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "ACCOUNT_STATUS",
    "status": "REJECTED",
    "reason": "ACCOUNT_STATUS_NOT_PERMITTED",
    "description": "Account is blocked from receiving debits or credits. "
}

Account validation

Platform authorization validates if the account ID received from the payment methods request is valid.

Name: ACCOUNT_ID

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "ACCOUNT_ID",
    "status": "APPROVED",
    "reason": "ACCOUNT_ID_PERMITTED",
    "description": "Account ID is permitted."
}

Anti-fraud integration

Platform authorization integrates with an external anti-fraud system to have the issuer-specific rules evaluated by their system.

Name: ANTI_FRAUD

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the override flag when anti-fraud returns the response code or denial code to replace the authorization response, the force_approve flag when anti-fraud returns that the authorizer must force authorization approval even if any validation has been denied and the validation steps have been executed in the anti-fraud flow.

Fields: override, force_approve, executed_steps

Payload example:

{
    "name": "ANTI_FRAUD",
    "status": "APPROVED",
    "reason": "ANTI_FRAUD_APPROVED",
    "description": "Authorization passed anti-fraud evaluation.",
    "additional_data": {
      "override": "false",
      "force_approve": "false",
      "executed_steps": {}
    }
}

Authorization registration

Platform authorization registers the authorization information into the database. If something fails on this operation, the authorization may be declined.

Name: AUTHORIZATION

Possible status: APPROVED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "AUTHORIZATION",
    "status": "APPROVED",
    "reason": "AUTHORIZATION_CREATED",
    "description": "Authorization was created successfully.",
    "additional_data": {}
}

Authorization retrieval

Payment methods flow retrieves the original authorization on the cancellation flow to perform some validations against its current status and determine whether that request may proceed. If the authorization is retrieved successfully, the flow goes on but if an error happens, the cancellation request is declined.

Name: AUTHORIZATION_RETRIEVAL

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "AUTHORIZATION_RETRIEVAL",
    "status": "APPROVED",
    "reason": "AUTHORIZATION_RETRIEVAL_SUCCESSFUL",
    "description": "Authorization was retrieved successfully."
}

Balances configuration retrieval

Payment methods flow integrates with the Balances configuration API to determine which account balances should be impacted by the Ledger in a given authorization. This functionality allows you to create dynamic rules to impact the balance, offering additional flexibility. All rules are associated with a processing code.

Name: BALANCES_CONFIG

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains balance impact information returned by the Balances configuration API, which is used to impact the Ledger.

Fields: impact, consider, amount, amount_consider, reset_limit

Payload example:

{
	"name": "BALANCES_CONFIG",
	"status": "APPROVED",
	"reason": "BALANCES_CONFIG_FOUND",
	"description": "Balances configuration was found.",
	"additional_data": {
		"amount": "contract_amount",
		"amount_consider": "principal_amount",
		"consider": [
			"AvailableCreditLimit",
			"OverLimit"
		],
		"impact": [
			"AvailableCreditLimit"
		],
		"reset_limit": "last_installment"
	}
}

Card retrieval

When the authorization request from the payment methods service is performed using a card (PAN), the platform validates whether that card number is valid and exists in the database. If any error occurs, the request is declined.

Name: CARD

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the card hash related to the card number received

Fields: card_hash

Payload example:

{
    "name": "CARD",
    "status": "APPROVED",
    "reason": "CARD_FOUND",
    "description": "Card was found.",
    "additional_data": {
        "card_hash": "99999999fOt10YS1QK8V3J6poQ/r1gOsfZZZZzzzzzZkxyiabfxRBPVfSzMlKAlXIs777777777tOwntil9k+A=="
    }
}

Card ARQC validation

When the authorization request from the payment methods service is performed using a card (PAN) and contains the cryptogram (chip) information, the platform validates this Cryptogram information against the HSM to verify whether it is valid.

Name: ARQC

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the field that indicates whether the cryptogram data is present. When declined by HSM, contains the error code. When validation is skipped, contains the cause.

Fields: arqc_presence, code, cause

Payload example:

{
    "name": "CARD_ARQC",
    "status": "SKIPPED",
    "reason": "CARD_ARQC_SKIPPED",
    "description": "ARQC validation was skipped.",
    "additional_data": {
        "arqc_presence": false,
        "cause": "Authorization has no cardholder verification method.",
        "code": ""
    }
}

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 received in the request with the ones registered in the database from previous authorizations. If the counter is not duplicated and is within an allowed range (configured by the issuer), the request is validated.

Name: CARD_ATC

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the current ATC, the list of previous ATCs, and both min and max offset allowed parameters.

Fields: current_atc,previous_atc, min_offset_parameter, max_offset_parameter

Payload example:

{
    "name": "CARD_ATC",
    "status": "APPROVED",
    "reason": "CARD_ATC_WITHIN_ALLOWED_RANGE",
    "description": "ATC is within allowed range.",
    "additional_data": {
        "current_atc": "10",
        "previous_atc": "[9,8,7,5,1]",
        "min_offset_parameter": "5",
        "max_offset_parameter": "15"
    }
}

Card authorization mode validation

When authorization request from the payment methods service uses a card, the Pismo platform validates if the authorization mode (credit/debit) matches the card mode. Credit cards can only operate on credit mode and debit cards can only operate on debit mode. Combo or multi application cards can operate on both modes but the mode received on the authorization request must be enabled on the card.

Name: CARD_AUTHORIZATION_MODE

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the authorization mode.

Fields: authorization_mode

Payload example:

{
    "name": "CARD_AUTHORIZATION_MODE",
    "status": "APPROVED",
    "reason": "CARD_AUTHORIZATION_MODE_VALID",
    "description": "Card has authorization mode enabled.",
    "additional_data": {
        "authorization_mode": "CREDIT"
    }
}

Card CVV validation

When the authorization request from the payment methods service is performed using a card (PAN) and contains a CVV (track1 or track2 data), this CVV information is validated against the HSM to verify whether it is valid.

Name: CARD_CVV

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains two fields indicating the track1 and track2 data presence and, when declined by HSM, contains the error code. When validation is skipped, contains the cause.

Fields: track1_presence, track2_presence, code, cause

Payload example:

{
    "name": "CARD_CVV",
    "status": "SKIPPED",
    "reason": "CARD_CVV_SKIPPED",
    "description": "CVV validation was skipped.",
    "additional_data": {
        "track1_presence": false,
        "track2_presence": false,
        "cause": "Authorization has no cardholder verification method.",
        "code": ""
    }
}

Card CVV2 validation

When the authorization request from the payment methods service is performed using a card (PAN) and contains a CVV2, the platform validates this CVV2 information against the HSM to verify whether it is valid. The platform also validates the entered expiration date during this flow since it is used on the CVV2 calculation and must be correct.

Name: CARD_CVV2

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the field indicating the CVV2 data presence, the entered expiration date, and, when declined by HSM, it contains the error code. When validation is skipped, contains the cause.

Fields: cvv2_presence, entered_expiration_date, code, cause

Payload example:

{
    "name": "CARD_CVV2",
    "status": "SKIPPED",
    "reason": "CARD_CVV2_SKIPPED",
    "description": "CVV2 validation was skipped.",
    "additional_data": {
        "cvv2_presence": false,
        "entered_expiration_date": "2806",
        "cause": "Authorization has no cardholder verification method.",
        "code": ""
    }
}

Card entered expiration date validation

When the authorization request from the payment methods service is performed using a card and cardholder provides the expiration date, the platform validates whether the entered expiration date matches the card’s expiration date.

Name: CARD_ENTERED_EXPIRATION_DATE

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the entered expiration date and the card’s expiration date.

Fields: entered_expiration_date, card_expiration_date

Payload example:

{
    "name": "CARD_ENTERED_EXPIRATION_DATE",
    "status": "APPROVED",
    "reason": "CARD_ENTERED_EXPIRATION_DATE_VALID",
    "description": "Entered expiration date matches card expiration date.",
    "additional_data": {
        "card_expiration_date": "2806",
        "entered_expiration_date": "2806"
    }
}

Card expired date validation

When the authorization request from the payment methods service is performed using a card, the platform validates whether the card is expired.

Name: CARD_EXPIRATION_DATE

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the card’s expiration date.

Fields: card_expiration_date

Payload example:

{
    "name": "CARD_EXPIRATION_DATE",
    "status": "APPROVED",
    "reason": "CARD_NOT_EXPIRED",
    "description": "Card is not expired.",
    "additional_data": {
        "card_expiration_date": "2806"
    }
}

Card password tries validation

The Pismo platform validates and counts the number of incorrect password tries by the cardholder. If those tries reach a configured threshold, the card is blocked and new requests are allowed even if the password is correct. This threshold is configured by the issuer on the Pismo platform.

Password tries error counter is only reset when the cardholder enters the correct password in a new authorization request before reaching the blocking threshold. Requests that don't use the password, such as e-commerce or contactless, even though approved, do not reset the counter. After reaching the threshold, even the requests without password are declined.

Name: CARD_PASSWORD_TRIES

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the current password tries count and the configured threshold.

Fields: current_password_tries, password_tries_allowed

Payload example:

{
    "name": "CARD_PASSWORD_TRIES",
    "status": "APPROVED",
    "reason": "CARD_PASSWORD_TRIES_ALLOWED",
    "description": "Password tries are within configured threshold.",
    "additional_data": {
        "current_password_tries": 0,
        "password_tries_allowed": 3
    }
}

Card PIN validation

When the authorization request from the payment methods service is performed using a card (PAN) and contains a PIN block, the platform validates this PIN block information against the HSM.

Name: CARD_PIN

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the field that indicates whether the PIN block data is present. When declined by HSM, contains the error code. When validation is skipped, contains the cause.

Fields: pin_presence, code, cause

Payload example:

{
    "name": "CARD_PIN",
    "status": "SKIPPED",
    "reason": "CARD_PIN_SKIPPED",
    "description": "PIN validation was skipped.",
    "additional_data": {
        "pin_presence": false,
        "cause": "Authorization has no cardholder verification method.",
        "code": ""
    }
}

Card status validation

When the authorization request from the payment methods service is performed using a card, the platform validates whether the card has a blocked status.

Name: CARD_STATUS

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the card status.

Fields: card_status

Payload example:

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

Currency validation

Platform authorization has to perform a validation to determine the currency associated with the account ID of the authorization. The currency can be associated with the account or program level.

Name: CURRENCY

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the currency numeric and alphanumeric codes.

Fields: code, numeric_code

Payload example:

{
    "name": "CURRENCY",
    "status": "APPROVED",
    "reason": "CURRENCY FOUNT",
    "description": "Currency was found.",
    "additional_data": {
	"code": "USD",
	"numeric_code": "840"
    }
}

External calculation

If configured, the authorization request from the payment methods service calls an external endpoint to have the amounts of the authorization calculated by an external system. If any error occurs, the authorization is declined.

Name: EXTERNAL_CALCULATION

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the list of validation errors when the external system responds with an unexpected response format or missing required fields.

Fields: response_status_code, error_1, error_2, error_n

Payload example:

{
    "name": "EXTERNAL_CALCULATION",
    "status": "APPROVED",
    "reason": "EXTERNAL_CALCULATION_SUCCESSFUL",
    "description": "External calculation was performed successfully."
}

Flex controls evaluation

Platform authorization evaluates flex controls for the operation.

Name: FLEX_CONTROLS

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "FLEX_CONTROLS",
    "status": "APPROVED",
    "reason": "FLEX_CONTROLS_APPROVED",
    "description": "Authorization passed flex control evaluation."
}

Ledger integration

Platform authorization integrates with Ledger API to evaluate impact on account limits for this operation.

Name: LEDGER

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the force flag when calling the ledger force flow and ignore_status when impacting the ledger normal flow without validating the account status.

Fields: force, ignore_status

Payload example:

{
    "name": "LEDGER",
    "status": "APPROVED",
    "reason": "LEDGER_APPROVED",
    "description": "Ledger was impacted successfully.",
    "additional_data": {
    	"force": true
    	}
    }
}

Merchant validation

To complete an authorization request, the authorization request from the payment methods service calls the merchants API to validate if the merchant can authorize transactions, which is when their status is ACTIVE or APPROVED.

Name: MERCHANT

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the merchant external ID (external_id provided by the customer, not the Pismo internal ID) and status.

Fields: merchant_external_id (external ID provided by the customer, not Pismo internal ID), status, marketplace_id

Payload example:

{
    "name": "MERCHANT",
    "status": "APPROVED",
    "reason": "MERCHANT_VALID_STATUS",
    "description": "Merchant has valid status.",
    "additional_data": {
        "merchant_external_id": "FL-123456",
        "status": "ACTIVE",
        "marketplace_id": "102030"
    }
}

Payment methods configuration retrieval

For every authorization request from the payment methods service, the platform retrieves the configurations related to the account/program/organization performing the request. If anything unexpected happens during this flow, the request may be declined.

Name: CONFIG

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "CONFIG",
    "status": "APPROVED",
    "reason": "CONFIG_FOUND",
    "description": "Payment methods configuration was found."
}

Payment methods acceptances retrieval

For every authorization request from the payment methods service, the platform retrieves the acceptances related to the account, program, and organization and processing code performing the request. If anything unexpected happens during this flow, the request may be declined.

Name: ACCEPTANCE

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "ACCEPTANCE",
    "status": "APPROVED",
    "reason": "ACCEPTANCE_FOUND",
    "description": "Payment methods acceptances were found."
}

Payment methods integrity

Payment methods flow saves an integrity message to process the integrity validation of the flow later. If this operation fails to register the integrity message, the request is declined.

Name: PAYMENT_METHODS_INTEGRITY

Possible status: APPROVED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "PAYMENT_METHODS_INTEGRITY",
    "status": "APPROVED",
    "reason": "PAYMENT_METHODS_INTEGRITY_CREATED",
    "description": "Payment methods integrity message was created successfully."
}

Payment methods persistence

Payment methods flow saves the request and response information in the persistence record to guarantee integrity of the flow. If this operation fails to register the information into the database, the request is declined.

Name: PAYMENT_METHODS_PERSISTENCE

Possible status: APPROVED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "PAYMENT_METHODS_PERSISTENCE",
    "status": "APPROVED",
    "reason": "PAYMENT_METHODS_PERSISTENCE_CREATED",
    "description": "Payment methods persistence record was created successfully."
}

Operation amount calculation

Platform authorization calls the Rates API to calculate the contract amount including taxes and fees on this authorization. If any error occurs, the request is declined.

Name: RATES

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "RATES",
    "status": "APPROVED",
    "reason": "RATES_APPROVED",
    "description": "Rates calculation was performed."
}

Original authorization retrieval

Platform authorization retrieves the original authorization and performs validations.

Name: ORIGINAL_AUTHORIZATION

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "ORIGINAL_AUTHORIZATION",
    "status": "APPROVED",
    "reason": "ORIGINAL_AUTHORIZATION_APPROVED",
    "description": "Original authorization validation was approved."
}

Platform authentication

Payment methods flow supports external integration to have the request authenticated against an external provider. If authentication is enabled and the information related to this is sent into the request payload, Payment methods API calls the external provider to validate this information. The result of this validation is attached to the validation result map on this entry.

If the platform does not authenticate and decline the request, it does not add an entry to the validation result map, since the flow is stopped and the request receives the 401 - Unauthorized HTTP response.

Name: PLATFORM_AUTHENTICATION

Possible status: APPROVED, SKIPPED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "PLATFORM_AUTHENTICATION",
    "status": "APPROVED",
    "reason": "PLATFORM_AUTHENTICATION_SUCCESSFUL",
    "description": "Request was authenticated successfully."
}

Platform authorization

To complete an authorization request, the authorization request from the payment methods service calls the platform authorization flow that performs all platform validations, such as ledger, rates, flex controls, and anti-fraud. If an error occurs during this call, the request is declined.

Name: PLATFORM_AUTHORIZATION

Possible status: APPROVED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "PLATFORM_AUTHORIZATION",
    "status": "REJECTED",
    "reason": "PLATFORM_AUTHORIZATION_ERROR",
    "description": "Platform authorization call returned an error."
}

Processing code mapping

Payment methods flow integrates processing code API to map the correct processing code to the authorization. This allows you to create mapping rules where the processing code received may be changed into a new one to have a specific mapping for each necessary scenario.

Name: PROCESSING_CODE_MAPPER

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the original processing code received on the request and the mapped processing code that is returned after mapping (this may be the same processing code as the received one if no rule is configured).

Fields: original_processing_code, mapped_processing_code

Payload example:

{
    "name": "PROCESSING_CODE_MAPPER",
    "status": "APPROVED",
    "reason": "PROCESSING_CODE_MAPPED",
    "description": "Processing code was mapped successfully.",
    "additional_data": {
        "original_processing_code": "00",
        "mapped_processing_code": "003000"
    }
}

Processing code type validation

Platform authorization validates whether the processing code has a valid balance impact type of credit, debit, or zero balance. If it is an invalid type, the request is declined.

Name: PROCESSING_CODE_TYPE

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "PROCESSING_CODE_TYPE",
    "status": "APPROVED",
    "reason": "PROCESSING_CODE_TYPE_VALID",
    "description": "Processing code has a valid balance impact type."
}

Processing code validation

Platform authorization validates if the processing code is valid.

Name: PROCESSING_CODE

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "PROCESSING_CODE",
    "status": "APPROVED",
    "reason": "PROCESSING_CODE_FOUND",
    "description": "Processing code was found."
}

Program parameters retrieval

To perform card password tries and card ATC validations, the platform needs to retrieve program parameters. If something goes wrong with this retrieval, the authorization may be denied.

Name: PROGRAM_PARAMETER

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Contains the program ID related to this request.

Fields: program_id

Payload example:

{
    "name": "PROGRAM_PARAMETER",
    "status": "APPROVED",
    "reason": "PROGRAM_PARAMETER_FOUND",
    "description": "Program parameters were found successfully.",
    "additional_data": {
        "program_id": 99
    }
}

Program retrieval

Platform authorization retrieves the program information to process this authorization request and make some validations.

Name: PROGRAM

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "PROGRAM",
    "status": "APPROVED",
    "reason": "PROGRAM_FOUND",
    "description": "Program was found."
}

Remaining cancellation balance

Platform authorization retrieves the remaining cancellation balance and performs validations.

Name: REMAINING_CANCELLATION_BALANCE

Possible status: APPROVED, SKIPPED, REJECTED

Possible reasons:

Additional data: Not mapped yet.

Payload example:

{
    "name": "REMAINING_CANCELLATION_BALANCE",
    "status": "APPROVED",
    "reason": "ORIGINAL_AUTHORIZATION_APPROVED",
    "description": "Remaining cancellation balance for this authorization was approved."
}