Processing codes identify financial operations on the Pismo platform. For example, 00 is a purchase, 01 is a withdrawal, and so on. Processing codes are defined at the organization level, and can be used for all organization programs and accounts. An organization is created with a number of standard processing codes automatically available to it.

For transactions, processing codes are mapped to transaction types to create transaction flows . Refer to standard processing code to transaction type mapping for more information.

📘

You can also use Pismo Control Center to view and create processing codes and transaction types, including reversals. For details, refer to Processing codes and transaction types.

For other domains, like balance configurations, flex controls, fees and rules, and rule models, processing codes are used to indicate what operations to apply controls or fees to.

To find processing codes assigned to your organization, call the List processing codes endpoint.

Processing codes are objects with the following key fields (not a complete list):

As shown. each processing code has either anAUTHORIZATION or REVERSALtype. You need to specify a reversal processing code for every authorization processing code.

Full and partial reversals of an authorization processing code can be either equal or different ones as per the business requirements. Only authorization processing codes should be passed to Pismo authorization systems (Payment methods, Network authorization, P2P),

During cancellation, the authorization system uses the original processing code to perform the cancellation, the opposite financial impact is then applied (reversing the operation at authorization level) and the reversal processing codes associated with the operation are used to define the transactions that should be posted along with any accounting entries that need to be done.

Standard processing codes

Processing codes can be either standard or custom. Standard processing codes are related to platform default operations like instant payments processing (Pix, UPI), credit cycle flow (interest accruals posting, taxes and fees), transaction banking (hold funds, release funds) and so on. Standard processing codes are available to all customers at organization creation time. Since all organizations use these processing codes, customizations are not allowed.

Network processing codes, used for processing Visa, Mastercard, RuPay, ELO, and other card networks, are also considered standard processing codes.

Custom processing codes

You can configure your own custom processing code with the Create processing code endpoint. For a custom processing code, you must configure its reversal and partial reversal processing codes, and all required configurations.

For transactions, once a custom processing code is created, it needs to be mapped to a transaction type to create a transaction flow. Refer to Payments configurations for more information. This guide has a tutorial on creating your own transaction flows.

A custom processing code is created with a PENDINGstatus . Initially, its use is not allowed in authorizations. Once the transaction flow for a custom processing code is completely configured, its status changes to SUCCESSand it is ready for use. All standard processing codes have a SUCCESS status.

📘

New authorization system

Life cycle (status) will take effect on the platform after the platform's authorization system is migrated to use the new processing code domain. All current processing codes created before the migration of the processing code database on January 2, 2025 remains ready for usage. New processing codes created after this date should follow the flow to have its status updated to SUCCESS. Denial of requests with processing codes with status PENDING will take effect later and will be announced by the authorization teams.

Default reversal processing codes

Every AUTHORIZATION processing code is required to have a reversal and a partial reversal processing code. When creating a new processing code , customers must specify the reversal processing code. Partial reversal code is optional but, if not present, a default value is assigned based on the balance Impact.

There is currently no established standard for implementing a “cancel a cancellation”—this approach introduces unnecessary complexity and risk to transaction integrity. For this reason, we strongly advise against configuring or relying on such functionality. Instead, the recommended best practice is to treat the initial cancellation as final. If a reversal is required, the client should initiate a new authorization rather than attempting to cancel the cancellation. This ensures consistency, reduces operational overhead, and aligns with expected platform behavior.

Default partial reversal processing codes

Pismo also defines generic reversal processing codes available to customers to use as standard processing codes. Those ones can be linked to a processing code when the customer doesn’t want to create or use a specific reversal processing code for the one being created. Since the endpoint requires the reversal one, the request must contain one of them so that the correct link is made. Below we show the list of standard processing codes for reversals:

Default reversal processing codes

Changing processing codes during authorization with rule models

You can use rule models to change a card network processing code during authorization. For example, you may want to use a custom processing code if the merchant is Apple. Rule models are created for an organization and can be applied to an organization, program, or account. The Pismo platform has a Rule model API you can use to implement this feature.

Sample payload to create rule model:

This rule model assigns the custom processing code MYPC03 to the authorization if the merchant is Apple and it's a domestic transaction. If it's an international transaction, then 003100 is assigned as the processing code.