Skip to navigation
Platform changelogs

API changelog

October 19, 2026

Intelligent boarding API (beta)

We’ve added the intelligent boarding API, in beta. It replaces legacy boarding (/Boarding/*) with a separate record for each business, person, paypoint, payment method, and application. To opt in, reach out to your Payabli contact.

The new endpoints, grouped by record:

  • Businesses: Create, list, get, update, and deactivate businesses, manage their addresses, and link people to them. See Create a business.
  • People: Create, list, get, update, and search people. See Create a person and Search people.
  • Paypoints: Create, list, get, and update paypoints. See Create a paypoint.
  • Payment methods: Create, list, get, update, and deactivate a business’s payment methods. See Create payment methods.
  • Templates: List, get, and archive templates, and get a template version. See List templates.
  • Applications: Create, list, get, update, validate, submit, and withdraw applications. Upload and manage application documents, provide requested documents or information, and read status history and enablement progress. See Create an application, Validate an application, and Submit an application.

Legacy boarding is deprecated and will be sunset in Q2 2027. See Migrate from legacy boarding, the intelligent boarding overview, and Board a new business.

Suggest and set check numbers for check payouts

We’ve added GET /MoneyOut/nextCheckNumber/{paypointId}/{accountId}, which suggests the next check number for check payouts from the funding account that accountId identifies. Payabli 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. When the account ID isn’t valid for the paypoint, this endpoint returns HTTP 400 Bad Request with the new error 3758 (The account id value provided is invalid).

The reissue endpoint (POST /MoneyOut/reissue) now accepts an optional checkNumber, so you can set a specific number on a reissued check.

We’ve also corrected the checkNumber limit on the authorize and reissue endpoints: a check number can have up to 8 digits, not a value up to 500,000,000. Longer values return error 3727, and non-numeric values return 3728.

See Get the next check number, Reissue a payout transaction, and the API response codes reference.

Cancel and reissue returned ACH payouts

You can now reissue an ACH payout with a Returned status (-2), and you can cancel some returned ACH payouts. In payout query responses, a returned ACH payout’s allowedActions array includes reissue, and also cancel when the payout can be canceled. When you cancel a returned ACH payout, its Status changes to -7 (Refunded) instead of 0 (Canceled). Returned check and virtual card payouts can’t be canceled or reissued.

This change affects the following endpoints:

See Manage payouts with the API and Reissue payouts with the API.

Card-present device improvements

We’ve added device details to transaction records, notifications, and device queries:

  • Transaction records now include DeviceEntryMode, EmvAuthData, and DeviceData.

    • DeviceEntryMode is how the device read the card: Chip, Contactless, Swipe, Manual, Fallback, or None. It’s null for non-device transactions and for device transactions that never reached the processor.
    • EmvAuthData holds the EMV data sent with the authorization request (RequestEmvData) and returned in the response (ResponseEmvData). It’s null when neither value is present, such as for swiped cards.
    • DeviceData holds the registered device’s type, operating system, friendly name, serial number, make, model, MAC address, and status. It’s null when the transaction has no device or the device isn’t registered to the paypoint.

    These fields are returned by Get list of transactions for an entrypoint, Get list of transactions for an organization, and Get details for a processed transaction. They also appear on the transaction records in chargeback and customer responses. Filter transaction queries by entry mode with DeviceEntryMode, for example DeviceEntryMode(in)=Chip|Contactless.

  • Transaction events: Failed device transactions now record a Device Timeout or Cancellation received from device event. See the Pay In TransEvent reference.

  • Webhook notifications: Pay In payment notifications (except originated payments) and transaction notifications (on hold, released, recovered, and rejected) now include the device’s SerialNumber and the card’s EntryMode. Both are empty for non-device payments. See the webhooks overview.

  • Device query records: List devices by paypoint and List devices by organization now return operationalStatus, appVersion, and osVersion. operationalStatus shows whether the device can accept a transaction now: online, busy (running another command), or offline. Check it before you send a transaction to a device. It’s separate from deviceStatus, which is the device’s lifecycle status. appVersion and osVersion can be null. See Manage AXIUM devices.

Cancel ghost cards

We’ve added DELETE /MoneyOutCard/GhostCard/{cardToken}, which cancels a ghost card and frees the vendor’s slot so you can issue them a new one. The cancellation is a soft delete: Payabli keeps the card record and its transaction history. This endpoint requires the vcard_delete permission.

We’ve also added these error codes:

  • 7065: The card isn’t a ghost card.
  • 7066: The card was already canceled with this endpoint.
  • 7067: The vendor already has an active ghost card. Creating a ghost card now returns this error when the vendor has one. Canceled and expired cards don’t count toward this limit.

See Cancel ghost card, Manage ghost cards with the API, and the API response codes reference.

Payout and payment method requests fail when the vendor number matches an inactive vendor

When a payout or payment method request’s vendorData.vendorNumber matches an inactive vendor in the paypoint, the request now fails with error 3409 (Vendor is Inactive). Before, Payabli created a new active vendor with the same vendor number. To use the vendor, reactivate it with Update vendor, then resend the request.

This change affects these endpoints:

See Vendor status and the API response codes reference.

Vendor numbers are unique across location codes

A vendor’s vendorNumber must now be unique within the paypoint, regardless of locationCode. Before, two vendors in the same paypoint could share a vendor number if their location codes were different. Inactive vendors keep their vendor number, so a new vendor can’t reuse it. Deleted vendors (vendorStatus -99) release theirs.

Create vendor and Update vendor return error 3436 (Duplicated vendor under entry) when another vendor in the paypoint already uses the vendor number, even if that vendor has a different location code.

See Field requirements and validation and the API response codes reference.

Vendor and bill imports match vendors by vendor number

Import vendors now rejects a line with the error Duplicated vendor under entry when another vendor in the paypoint already uses its vendor number, even if the line has a different location code.

Import bills now matches each line to an existing vendor by vendor number only, ignoring location code. If the matched vendor is inactive, the import rejects the line with the error Vendor Inactive.

See Import vendors and Import bills.

Flag vendors for 1099 tax reporting

Vendor records now have a 1099 flag that shows whether a 1099 tax form is issued to the vendor. Create vendor and Update vendor accept an optional issue1099 boolean. When you create a vendor without issue1099, the flag is false. When you update a vendor without it, the flag keeps its current value.

Vendor objects in responses now include Issue1099. This includes Get vendor, List vendors by paypoint, List vendors by org, and the vendor in bill, payout, payout subscription, transfer, and virtual card responses. Get payout subscription and Get a payment method return it as issue1099, in camel case like the other vendor fields in those responses.

Import vendors and Import bills accept an optional issue1099 column with true or false. A blank value is false. In a bill import, the column applies only to vendors that the import creates.

See Manage vendors with the API.

Filter Pay Out transfers by paymentId

You can now filter Pay Out transfer queries by a payout’s payment ID with the paymentId filter, which supports the eq, ne, in, and nin operators. For example, paymentId(eq)=01M34MJAYD054M4NCCK9J0D96R returns every transfer linked to that payout: the payout transfer, any refund and stale check refund transfers, and the billing fee transfer. An unknown payment ID returns an empty list.

See Get list of outbound transfers for a paypoint and Get list of outbound transfers for an organization.

See every payout that paid a bill

Bill records now include transactions, a list of every payout that paid the bill. Before, a bill showed only one payout in Transaction, even when several partial payouts paid it. Each entry has the payout’s idOut (integer) and paymentId (string or null). Canceled payouts aren’t included. The value is null when the bill has no payouts, and an empty array when every payout on the bill was canceled. If partial payments aren’t enabled, a bill whose only payout was canceled returns null instead.

The field name is camelCase, though the rest of the bill record uses PascalCase.

These endpoints return transactions:

Add invoice data when you update a subscription

Update subscription (PUT /Subscription/{subId}) now accepts invoiceData, the same invoice object that Create subscription accepts. Use it to link an invoice to an existing subscription or autopay, or to change or remove one.

An invoiceData object replaces the subscription’s existing invoice data entirely, so include every field you want to keep. Send "invoiceData": null to remove the invoice data. If you leave invoiceData out of the request, the subscription’s invoice data doesn’t change. The update response is unchanged. See Update a subscription for details.

CustomerId in webhook payloads no longer contains a name

The CustomerId field in payment, dispute, and ACH return webhook payloads is now always the payor’s customer ID. When the payor isn’t a customer under the transaction’s paypoint, CustomerId is "0". Before this change, CustomerId could contain the payor’s name in this case, which caused some webhook receivers to reject the payload.

This change affects these webhooks:

Payment Approved already sent "0" in this case.