October 2026 release notes

October 2026 introduces intelligent boarding in beta. It also adds card-present device details, extends Same Day ACH statement descriptors to Pay Out funding debits, and adds check-number control to Pay Out check payouts.

Filter these notes by pillar, surface, or change type to show only what applies to you.

Pay In

These are the Pay In changes in the October 2026 release.

Card-present device improvements

You can now see more about the devices behind card-present transactions. Before, transaction records, notifications, and device lists didn’t show how a card was read or whether a device was ready. Now:

• Transaction records show how the device read the card, the EMV authorization data, and the device’s details. You can also filter transactions by entry mode.
• Pay In payment notifications (except originated payments) and transaction notifications (on hold, released, recovered, and rejected) include the device’s serial number and the card’s entry mode.
• Device lists show whether each device can accept a transaction now (online, busy, or offline), plus its app and Android versions.
• Failed device transactions record a timeout or device cancellation event.

Action required: None.

Learn more: API changelog · Manage AXIUM devices

Add invoice data when you update a subscription

You can now link, change, or remove a subscription’s invoice data after you create it. Before, only creating a subscription accepted invoiceData. Now, updating a subscription accepts it too. The object you send replaces the existing invoice data, and null removes it.

Action required: None.

Learn more: API changelog · Update a subscription

Pay Out

These are the Pay Out changes in the October 2026 release.

Separate statement descriptor for Same Day ACH funding debits

You can now request a separate bank statement descriptor for Same Day ACH funding debits from the paypoint, distinct from the one used for standard ACH. Before, every ACH funding debit used the same descriptor regardless of speed. Now, when a funding debit goes out as Same Day ACH, it uses the Same Day ACH descriptor if you’ve set one. Standard-speed debits keep using the standard descriptor.

Action required: Only if you want a distinct Same Day ACH descriptor: contact the Payabli team to set one up.

Learn more: Payment descriptors

Check number control for check payouts

You can now set the check number when you reissue a payout as a new check. Before, reissuing to a new check reused the same check number or assigned one automatically, with no way to enter your own or look up the next available one. Now, the reissue endpoint (POST /MoneyOut/reissue) accepts an optional checkNumber that Payabli validates and persists on the reissued check. A new GET /MoneyOut/nextCheckNumber/{paypointId}/{accountId} endpoint suggests the next number for the funding account. It returns the highest check number on the account’s check payouts plus one, or 1 if the account has no check history. Canceled check payouts don’t count.

Action required: None.

Learn more: API changelog · Get the next check number · Reissue a payout transaction

Ghost card cancellation

You can now cancel a ghost card through the API and issue the vendor a new one. Each vendor can have only one active ghost card per paypoint. Before, creating a second card for the same vendor failed with an unclear error. Now, DELETE /MoneyOutCard/GhostCard/{cardToken} cancels the card and frees the vendor’s slot. The cancellation is a soft delete: Payabli keeps the card record and its transaction history. Creating a ghost card for a vendor that already has an active one now fails with error 7067, which tells you to cancel the existing card first.

Action required: Only if you want to cancel ghost cards through the API: your OAuth credentials need the new vcard_delete permission.

Learn more: API changelog · Cancel ghost card · Manage ghost cards with the API

Vendor numbers are unique within the paypoint

Each vendor number now identifies one vendor in the paypoint, so payouts no longer create duplicate vendors. Before, two vendors in the same paypoint could share a vendor number if their location codes were different. A payout request that named an inactive vendor by vendorNumber also created a new active vendor with the same number. Now:

• Creating or updating a vendor fails with error 3436 if another vendor in the paypoint already uses the vendor number, even under a different location code. Vendor import rejects those lines. Inactive vendors keep their number, and deleted vendors release theirs.
• Requests to authorize a payout, authorize and capture a payout, create a payout subscription, or save a payment method for a vendor fail with error 3409 when vendorData.vendorNumber matches an inactive vendor.
• Bill import matches vendors by vendor number only, and rejects lines for inactive vendors.

Action required: Yes, if your integration reuses a vendor number across location codes, or pays inactive vendors by vendorNumber. Give each vendor a unique number and reactivate an inactive vendor before you pay it.

Learn more: API changelog · Manage vendors with the API · API response codes

See every payout that paid a bill

You can now see every payout that paid a bill. Before, bill records showed only one payout in Transaction, so a bill paid by several partial payouts didn’t show the others. Now, bill records include a transactions list with the ID and payment ID of each payout. Canceled payouts aren’t included.

Action required: None.

Learn more: API changelog · Get bill · Partially pay a bill

Filter transfers by payout

You can now find every transfer linked to a payout. Before, you couldn’t filter Pay Out transfer queries by payout. Now, the paymentId filter returns the payout’s transfer and any related refund, stale check refund, and billing fee transfers.

Action required: None.

Learn more: API changelog · Get list of outbound transfers for a paypoint

Flag vendors for 1099 tax reporting

You can now record whether a 1099 tax form is issued to a vendor. In the Payabli Portal, select Issue 1099 form when you add or edit a vendor. In the API, create and update vendor requests accept an optional issue1099 field, vendor records return Issue1099, and vendor and bill imports accept an optional issue1099 column. Existing vendors start with the flag turned off.

Action required: None.

Learn more: API changelog · Manage vendors with the API · Flag a vendor for 1099 reporting

Pay Ops

These are the Pay Ops changes in the October 2026 release.

Intelligent boarding (beta)

You can now board merchants with intelligent boarding, Payabli’s new boarding API. It’s in beta. Before, a legacy boarding application held the business, its owners, its bank accounts, and its services in one object. Now, businesses, people, paypoints, payment methods, and applications are each their own record. You create the business and its paypoint, request services with an application, validate the application, and submit it. You can also upload required documents through the API.

Action required: To opt in, reach out to your Payabli contact. If you use legacy boarding, plan your migration: legacy boarding is deprecated and will be sunset in Q2 2027.

Learn more: API changelog · Intelligent boarding overview · Board a new business · Migrate from legacy boarding

Boarding skills for coding agents

Payabli Agent Skills now cover intelligent boarding. Two new skills guide your coding agent through the work: payabli-boarding boards a merchant with the intelligent boarding API, and payabli-boarding-migration moves an integration off legacy boarding. The getting-started skill now points to both.

Action required: None. To get the new skills, update your installed Payabli skills.

Learn more: Use Payabli Agent Skills · Intelligent boarding overview

Webhook CustomerId no longer contains a name

Webhook payloads now always send an ID in CustomerId. Before, when the payor wasn’t a customer under the transaction’s paypoint, payment, dispute, and ACH return webhooks could send the payor’s name in CustomerId. Some webhook receivers rejected these payloads. Now, CustomerId is the payor’s customer ID, or "0" when the payor isn’t a customer under the paypoint.

Action required: None.

Learn more: API changelog · Notifications and reports overview