The Payment methods configurations API provides advanced scalability and flexibility for payment methods. Highly customizable configuration options enable you to modify the Pismo platform’s default authorization behaviors to better serve different business needs and use cases and to improve processing times. This functionality supports multiple levels of configurations for authorization, payment, and transfer operations at different hierarchy levels.

There are three types of payment methods configurations:

• Platform configurations (also called configurations) are more general. This configuration type uses the Payment method configs endpoints.
• Acceptance configurations (also called acceptances) are more specific. This configuration type uses the Payment method acceptances endpoints and requires the processing code (PC) of the corresponding financial operation.
• Validation rules (also called rules) are specific configurations. This configuration type can be used in the requests of payment and transfer endpoints as well as in the platform configurations and acceptance configurations.

You can define any combination of platform configurations, acceptance configurations, and validation rules according to your business operation needs. The platform configuration fields can be different from the acceptance configuration fields.

• You define validation rules in the platform configurations and acceptance configurations in the rules request object.
• You define validation rules in the Create cash-in or cash-out and Create transfer endpoints in the validation_rules request object.

📘

For a specific financial operation identified by a processing code, you should create an acceptance configuration. For a general configuration, create a platform configuration.

Hierarchy

The Pismo platform hierarchy supports the Org, Program, Account, Acceptance, and Request configuration levels, in order from the most general to the most specific. The platform evaluates configurations in the following reversed order, from specific to general.

Request → Acceptance → Account → Program → Org

This means that the more specific levels take precedence over the more general ones.

• Request-level configurations supersede Acceptance-level configurations.
• Acceptance-level configurations supersede Account-level configurations.
• Account-level configurations supersede Program-level configurations.
• Program-level configurations supersede Org-level configurations.

If you have the same parameters configured at different levels, the platform only analyzes what it receives at the most specific level and ignores everything else. Here are a few examples:

• If you define the same parameter in both the Program and Org configuration levels, the Program-level parameter takes precedence.
• If you define the same parameter in both Account and Program configuration levels, the Account-level parameter takes precedence.
• If you define the same parameter in both a platform configuration and an acceptance configuration, the Acceptance-level parameter takes precedence.
• If you have configured validation rules in platform configurations or acceptance configurations in the rules field and then send validation rules through the cash-in/cash-out or transfer operation endpoint requests in the validation_rules field, the platform only analyzes what it receives in the requests and ignores everything else.
• If you have configured validation rules in both platform configurations and acceptance configurations, the platform only evaluates what it finds in the acceptance configurations and ignores platform configurations for the same parameters.

Configuration types

The Pismo platform uses separate configurations for authorization, payment, and transfer operations as follows:

• The authorization endpoints use configurations defined in the authorization object of the platform configurations and acceptance configurations endpoints.
• The cash-in/cash-out endpoints use configurations defined in the payment object of the platform configurations and acceptance configurations endpoints.
• The transfer endpoints use configurations defined in the transfer object of the platform configurations and acceptance configurations endpoints.

Platform configurations

Platform configurations provide the broadest level of payment methods configurations. As each Org, Program, and Account may need different forms of processing, platform configurations allow you to customize authorization flows according to your needs for each level of the Pismo platform hierarchy.

You define platform configurations in the platform configurations endpoints.

Acceptance configurations

Acceptance configurations provide a more specific level of payment method configurations and also require the processing code of the financial operation in every endpoint. This allows you to customize the authorization flow for each financial operation following the Pismo platform hierarchy.

The acceptance configuration fields can be different from the payment configuration fields. If the same parameters are defined in both acceptance configurations and platform configurations, the acceptance parameters take precedence.

You define acceptance configurations in the acceptance configurations endpoints.

Validation rules

Validation rules provide the most granular level of payment methods configurations. You can choose which validations to perform during the authorization flow at different hierarchy levels. This highly customizable approach offers the following advantages.

• Define custom validation characteristics that match your business needs.
• Improve processing time and performance by skipping unnecessary validations.
• Override the response and denial codes returned by the authorization flow to match the specifics of different systems to handle different responses in different ways.
• Force a validation if the operation has any impact on the account balance.

📘

Validation rules are different from validation results. Validation results are the results returned by each validation in the authorization process. For details, refer to Validation results array in the Payment methods guide.

There are two types of validation: those that make HTTP requests to another service and those that validate the data in the service itself.

Related topics

For detailed instructions and examples of configuring payment methods, refer to the Configure payment methods guide.

For an overview of payment methods, refer to the Payment methods guide.