API changelog

We’ve added a Case Management API for submitting and tracking bank account changes. Payabli models a bank account change as a case that moves through validation, automatic verification, review, and completion. Submit and validate a change, track its status, add notes, and manage attachments. Enterprise Partners can also action cases — assign, escalate, approve, and deny — while Platform Partners submit and track.

We’ve brought the webhook docs in line with the events the platform sends. The webhooks reference now documents all 113 supported notification events across Pay In, Pay Out, and Pay Ops. Each event has its own page with the full payload schema, field types, and an example. This replaces the standalone webhook payloads page, which is retired — its links redirect to the reference.

As part of an ongoing effort to better align the documentation with the API, we’ve corrected a boarding request field. This change affects the documentation only; the API already required this format.

As part of an ongoing effort to better align the documentation with the API, we’ve updated the vendor response schema. This change affects the documentation only, the API itself was already returning this data.

We’ve added a binCardType filter to the transactions query endpoints. Use it to narrow card transactions by card type, accepting CREDIT, DEBIT, or PREPAID (case-insensitive). The filter supports the eq, ne, in, and nin operators.

This applies to List transactions for a paypoint and List transactions for an organization.

We’ve added a new Pay Out webhook event, payout_transaction_duplicated, triggered when Payabli’s duplicate detection flags a payout transaction as a potential duplicate. The payload identifies the affected transactions (affectedIds, duplicateCount) along with the anomaly details (anomalyType, anomalyStatus, gateway, createdAt) and the paypoint and vendor.

When you use autoCapture, Payabli now emits a notification for every capture outcome, including internal validation failures that went unreported before. The capture-failure webhook events now include a Reason field describing why the capture didn’t succeed, alongside FundingSource and PaymentStatus.

For check payouts, Payabli now validates the vendor’s remit (mailing) address at authorization, before the payout is charged. If the address fails validation, Authorize a payout returns a 422 response and doesn’t charge the paypoint. Correct the address and re-authorize. Other payout methods (ACH, RTP, virtual card, wire, and managed payables) aren’t affected.

We’ve aligned the response reference and examples for the payout query endpoints with what the API returns. The reference now documents fields that were previously missing, corrects the Summary pageidentifier field name, and the examples reflect a real response.

As part of an ongoing effort to better align the documentation with the API, we’ve updated several Pay Out response schemas. These changes affect the documentation only, the API itself was already returning this data.

When you generate a payment link from an invoice, the optional page configuration blocks (logo, page, paymentMethods, review, messageBeforePaying, paymentButton, notes, contactUs, and settings) now behave differently when omitted. Previously, omitting a block hid that section. Now Payabli applies a default instead. Each omitted block is enabled at a fixed display order, so the generated page stays complete and branded. To hide a section, send it explicitly with enabled set to false. An explicit value is always honored and is never replaced by a default.

This entry covers the API changes released on June 15, 2026.

Pay In

Hide the save payment method checkbox on payment pages

We’ve added a showSaveMethod boolean to the paymentMethods section of a hosted payment page’s content. Set it to false to hide the “Save payment details for future use” checkbox on the page. It defaults to true, so existing payment pages keep showing the checkbox unless you change it.

As part of an ongoing effort to better align the documentation with the API, we’ve updated several Pay Out response schemas. These changes affect the documentation only, the API itself was already returning this data.

We’ve added new codes and updated the text for several existing codes in the Pay In unified response codes reference. These codes apply to Pay In transactions made with v2 of the API.

We’ve documented Card Account Updater, a service that automatically refreshes stored card credentials when cards expire, are reissued, or are closed. Twice per month, it checks stored cards that are expiring in the current or next month against the Visa Account Updater (VAU) and Mastercard Automatic Billing Updater (ABU) programs, then refreshes the stored token when an update comes back. This reduces recurring payment declines from stale card data.

We’ve updated the supported filter operators on the List vcards by paypoint and List vcards by org endpoints. Identifier filters now support numeric range comparisons, and string filters support starts-with and ends-with matching.

The sw (starts with) and ew (ends with) operators are new across the API. See the Filters and conditions reference for the full operator list.

We’ve documented two endpoints for retrieving virtual card transactions:

• List vcard transactions by paypoint (GET /Query/vcardsTransactions/{entry})
• List vcard transactions by org (GET /Query/vcardsTransactions/org/{orgId})

Each record returns virtual card and transaction details, with filters covering both transaction-level fields and the underlying card. See either endpoint’s API reference for the full field and filter list.

We added the Reject transaction status in the Payabli API. This new status is for transactions that were rejected by the issuing bank or card network after being authorized or settled. See Card rejection for more information. We also added new features across the API to allow users to filter for transactions with card rejections and see the amounts rejected.

The List subscriptions by paypoint and List subscriptions by organization endpoints now return the full stored payment method linked to each subscription as a new StoredMethod object. Both endpoints also accept a new idPmethod filter that narrows results by the linked stored method’s identifier. See either endpoint’s API reference for the full field list and operators.

The List subscriptions by paypoint and List subscriptions by organization endpoints now return a SubscriptionType field on each record and accept a new subscriptionType filter. The field distinguishes Regular subscriptions (fixed-amount recurring) from BalanceDriven subscriptions (amount tracks an outstanding balance), and returns null when no type is assigned. The filter supports eq, ne, in, and nin and accepts values case-insensitively. See either endpoint’s API reference for the full field list and operators.