Changelog
Sub-processorsAbout PismoContact us
Back to All

2 October 2026

25 days ago by [email protected]

Changes between 4 September and 2 October 2026

Core platform - Payments

Docs

The following new guides document a new type of program for commercial credit cards that enables multiple accounts to use a shared credit structure.

Core platform - Rates and fees

Docs

A new guide, Price Table strategy calculation, is now available. The PRICE_TABLE strategy is a fee calculation method that generates installment plans with compound interest, fees, and Imposto sobre Operações Financeiras (IOF - Brazilian tax) calculations. This new guide describes the various configurations and calculation process for the PRICE_TABLE calculation method.

Docs

A new guide, Equal installments strategy, is now available. The Equal Installments strategy is a calculation method used to calculate loans, financing agreements, or installment purchases where the customer pays a fixed installment amount throughout the contract. This calculation method is often used with simulations. This new guide describes the various configurations and calculation process for the Equal installments calculation method.

Card issuing - Network integration

New

A new API, Clearing rules engine, provides a set of external endpoints that allow you to configure which clearing events should be automatically processed by the Pismo platform and which should be routed to the dead letter queue (DLQ). The DLQ is the queue for all pending transactions waiting to be cleared. The new Clearing rules engine guide is now also available.

Card issuing - Statements

Docs

A new guide, Transaction classification model, is now available. This guide explains how processing codes, transaction types, program transaction types, and transaction categories are used to classify transactions and how the Pismo platform processes them based on that classification.

Client webhooks

Docs

The Client anti-fraud webhook for banking transaction was updated in the Client webhooks guide to include a more exhaustive list of endpoints that call the webhook.

Flex controls

Docs

The Flexible transaction controls guide was rewritten for clarity and to conform to documentation standards. It now includes clarifications in the overview and in the note about Pix transactions, additional details about flex control types, and links to two new guides:

General

Docs

The Core objects guides was rewritten to provide additional details about entities, streamline concept definitions, refer to the API reference documentation for field specifics, and to adhere to documentation standards overall.

Migrations

Docs

In the Migrate accounts endpoint, the requirements for due_date_id, program_id, and overdue account migrations were clarified.

Docs

Support for Migrate PCI cards data using encrypted PAN values was added through the new key_id, encrypted_pan, and iv fields. In addition, PAN requirements were updated so you can provide either a clear PAN (pan) or encrypted_pan data, helping support PCI-compliant migration workflows.

Docs

The documented value for the authorization_status field within the Migrate authorizations endpoint was corrected to align with Pismo documentation standards and business practices.

Docs

The description of the update_limit field within the Migrate authorizations endpoint was corrected. This new description reflects the proper field type and provides guidance on when to use it.

Docs

The description of the open_due_date field in the Migrate accounts endpoint was updated to clarify that for overdue accounts, this field must equal the due date of the earliest unpaid statement that originated the delinquency. Additional guidance was also added around the pre-go-live behavior when payments or qualifying credits are identified.

Docs

The payload structure of the migration object in the Migrate accounts endpoint was updated to be nested within the applicant object.

Payments

Updated

The authorization_id field is now returned in the success 200 and 201 responses of the following endpoints.

Updated

Account validation for hold funds and force operations in the Payment methods API was updated. The account_id is now required to be sent in the request body to match the gateway-asserted x-account-id header whenever account validation is enabled. This helps strengthen account-level authorization controls and reduce the risk of requests being processed for an unintended account within the same organization.

The affected components include the following endpoints in the Payment methods API.

Docs

The 200 and 201 status response of the Create cash-in or cash-out endpoint now correctly includes the amount field that was previously missing in documentation.

Docs

The 202 response of the Confirm pre-authorized cash-in or cash-out and Confirm pre-authorized transfer endpoints now explains that the empty body in this response is expected and that the confirmation outcome is delivered through the Platform authorization created event with the CONFIRMATION category.

Rates and fees

Docs

Reference documentation for the Create fee model endpoint was updated to change the 200 response to 201 to match the implementation.

Security

Updated

The process for configuring the Mutual Transport Layer Security (mTLS) has changed. The new process is described in the Identity connectivity with mTLS guide.

Events

Updated

In the two Accrual event processed events (one under Interest-bearing deposit accounts, one under Savings account product), the data format for estimated_settlement_date and accrual_date was changed from date‑time to date to resolve an inconsistency in the response payload returned to clients.

Banking operations

Updated

A metadata field was added to the following endpoints to standardize metadata structure at the root level for improved tracking and event correlation.

Updated

A new field release_datetime was added to the following endpoints, indicating when the remaining held funds are automatically released to the account.

Updated

A 409 Conflict error was added to the responses of the following endpoints. These errors now include clearer messages, such as "Product is already detached" and "Interest processing code already has a divergent balance‑config" to provide more context about the conflicts returned.

Updated

The PAYOUT option in interest_capitalization_mode now requires a fully resolved payout_account. When PAYOUT is sent without a payout account, the Pismo platform returns error EIBACC0379: interest_capitalization_mode PAYOUT requires a fully resolved payout_account. This update affects the following endpoints.

Updated

A new external_account_id field is now included in the response of the Update payout account for deposit account endpoint.

Updated

A 409 Conflict: Account already exists but could not be attached, status is not "NORMAL" error was added to the response payload of the Open deposit account endpoint. This error is generated when you open a deposit account with an external_account_id that already exists.

Updated

The external_account_id field was added to the response of the following endpoints to provide the client’s custom account ID.

Updated

The account_id field was removed from the body parameters of the Calculate average balance endpoint because it repeats the function already covered by the path parameter accountId.

Updated

In the Interest-bearing accounts API, the following 400BadRequest error codes were removed. The examples that exposed maturity_period and effective_date validation codes on endpoints that do not accept those fields were removed as well.

  • EIBACC0305
  • EIBACC0306
  • EIBACC0307
  • EIBACC0319
  • EIBACC0320
  • EIBACC0321

The affected API/endpoints are:

Updated

The FIXED enum option was added in the benchmark field returned in the 200 response of the following endpoints. • Get account interest • Get interest plan • Get account interest • List Org interest plans

Updated

The division_code field was added to body parameters of the Deposit money and Create balance endpoints.

Updated

The 403 Forbidden error was added as a possible response for the following endpoints.

Updated

The tax_withholding.tax_rules.threshold_amount field was added to the following endpoints.

Docs

The “Banking - Interest management (B3)” section in the API reference was renamed to “Banking - Interest management for B3-listed products”.

The endpoints in this section were renamed as follows.

Docs

The interest_by_tiers.tiers.amount and interest_by_tiers.tiers.margin_rate fields were made nullable in the following endpoints in the request body parameters and 200 response (as indicated).

Docs

The titles and descriptions of the indicated fields in the following events were updated. Note that some of the events under [Interest management] and [Interest engine] have the same titles.

Interest management

Interest engine

Docs

The description of the interest_capitalization_mode field in the Attach deposit to account and Attach deposit product to program endpoints were updated.

Docs

The attached_at field was renamed to attachment_date in the response of the following endpoints. This fixes the mismatch between the documentation and the actual response payload, which already returns attachment_date.

Docs

The description of the accrual_model field was updated, which defines how daily interest is calculated, using either net daily balance change (DEPOSIT_BASIS) or the daily closing balance (BALANCE_BASIS). When the field is omitted, the value is derived from the interest plan’s interest_base_model, which defaults to CLOSING-BALANCE and therefore produces BALANCE_BASIS, while any explicit mismatch returns HTTP 400 EIBACC0365. This update is reflected in the following endpoints.

Transaction banking

Updated

The following error codes were removed. Both error codes were previously documented as placeholders in the codebase and were never returned in production.

  • WPMT0032: Validation rules conflict with internal accounts program
  • WPMT0020: Scheduling a payment crediting your own account isn't allowed

These error codes were removed from the following endpoints.

Updated

The error codes WEAM0029 and WMLP1020 were removed from the following endpoints. These codes were originally used when the Pismo platform rejected earmark payments with back value dates, but back‑dated earmark payments are now supported by default.

Updated

The exclusiveMinimum: 0 was changed to minimum: 0 on the following fields because these fields are confirmed to accept zero as a valid value. The following endpoints are impacted by this change.

Updated

A note was added to the administrative_division_id field in the following endpoints stating that it points to the holiday calendar, and that the administrative division is deprecated and replaced by holiday calendar while both use the same underlying data structure for backward compatibility.

Updated

The 400 error code WCAC0005: division_code is a required field was removed from the Get transaction banking account information endpoint, because this error doesn’t apply.

Updated

The error codes WEAM0029 and WMLP1020 were removed from the following endpoints. These codes were previously returned when earmark payments with back value dates were rejected, but back‑dated earmark payments are now supported by default.

Authorization

Updated

Five missing fields were added to the Simulate authorization reference documentation: arqc_present, track1_present, track2_present, password_present, and cvv_present.

Dispute

Docs

An accompanying explainer video was added to the Visa dispute use case guide. The video introduces dispute handling on the Pismo platform, summarizes the dispute state machine, and provides a walkthrough of a real-world Visa fraud dispute.

Statements

Docs

The last sentence in the Installment advancements section of the Installment advancements guide was updated for clarity. The names of the links in the list at the end of that section were confusing because they gave the impression that they should link directly to the endpoint APIs, when they actually linked to sections of the same guide. Renamed the links to match the names of the sections they link to.

Docs

The description of the DELINQUENT_ACCOUNT_CLOSURE_DAYS parameter in the table in the Multivalue program parameters guide was updated.

Docs

The Recurring charges guide was updated in the following ways.

  • Added the Annual recurring charge section.
  • Changed the titles of all the “Example” subsections to make them more specific. For example, the “Example 1” subsection of “Examples for recurring charge plans” had its title changed to “Recurring charge plan example 1”.
  • Recurring charge plan example 3 was rewritten for clarity.

Docs

The description of the tracking_id body parameter field in the Create installment advancement endpoint was clarified.

Lending

Updated

The Get loan product and Update loan product endpoints now include the ability to indicate when a loan product has enabled backdating. You can configure the number of days for limiting the backdate window with the backdating_enabled and max_backdating_window_days fields.

Updated

The Register repayment endpoint was updated to include a backdating_reason field. When the repayment_date is earlier than the processing date, you can provide a reason as an audit label. The enum values available are:

  • RAIL_DELAY: Payment was made on time, but the payment rail or bank file reporting it reached Pismo later.
  • SYSTEM_ERROR: A technical failure or outage delayed recording a payment that was actually made earlier.
  • OPS_CORRECTION: An operations team is correcting the recorded date of a payment (back-office correction).
  • RETRY_WINDOW: Payment was originally initiated within the expected timeframe but was temporarily unsuccessful (for example, transient bank, network, or processing failure) and subsequently reprocessed. The payment is backdated to reflect the original intended payment date.
  • REINSTATEMENT: A previously reversed, cancelled, returned, or otherwise invalidated payment is being reinstated and recorded using its original effective payment date to restore the loan to the correct historical state.
  • MISAPPLIED_PAYMENT_CORRECTION: A payment applied to the wrong loan or installment is being corrected and re-applied using its true effective payment date.
  • OTHER: Generic catch-all for a legitimate backdating reason not covered by the specific values above.

Updated

The Create loan product and Update loan product endpoints were updated to require present_value_discount (processing code) when bring_to_present_value_on_delinquency is true. This setting ensures the platform brings future installments to present value before cancellation when closing due to delinquency.

Docs

More detail was added to the Create processing codes section of the Create loan products guide for Booking and Repayment processing codes.

Docs

The following statuses were previously shown in error and were now removed from the Get loan, List loans, and List account loans endpoints.

  • SCHEDULED
  • PROCESSING
  • PAID
  • PARTIALLY_PAID
  • PAST_DUE
  • NOT_PAID

Marketplace

Docs

Added documentation for HTTP 409 Conflict responses on the Create marketplace creditor operations endpoint. This response updates duplicate creditor operation handling from a generic 500 Internal Server Error to a business-specific conflict response when submitted creditor operations already exist for one or more specified merchants.

Deprecated

The following endpoints were decommissioned and removed from the Developers Portal and added to the API endpoints removed list.

  • List marketplace merchants V1
  • List marketplace merchants V2
  • Link merchant and marketplace
  • Delete merchant and marketplace link
  • Get marketplace V1
  • Update marketplace
  • Create marketplace V1
  • Create marketplace V2

Control Center

Updated

The dual approval feature was updated in Control Center. You can now request Pismo to enable dual approval for editing an address.

Docs

The Account configurations guide was updated to align with Pismo documentation and style standards.