API changelog

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

Add an endpoint to authorize and capture a payout in one call

We’ve added POST /MoneyOut/payout, which authorizes a payout and captures it in the same request and returns the capture result. Use it when you need the capture outcome synchronously, instead of calling Authorize payout and then Capture payout separately.

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

We’ve added support for AXIUM semi-integrated card-present terminals. Activate an AXIUM terminal with the Payabli API, then charge cards in person — the terminal captures and encrypts card data at the point of sale. You order AXIUM terminals from Payabli.

To activate a terminal, generate a 6-digit activation code with the Generate device activation code endpoint and enter it on the device. Then run a card-present sale through Make a transaction with paymentMethod.method set to device.

Logo fields and per-device metrics on device query records

The device query endpoints now return four new fields on each record:

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.