> This is Payabli documentation. For a complete page index, fetch https://docs.payabli.com/llms.txt — append .md to any page URL for lightweight markdown. For section-level indexes, query parameters, and other AI-optimized access methods, see https://docs.payabli.com/ai-agents.md

## 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](/developers/api-reference/businesses/create-a-business).
* **People:** Create, list, get, update, and search people. See [Create a person](/developers/api-reference/people/create-a-person) and [Search people](/developers/api-reference/search-people).
* **Paypoints:** Create, list, get, and update paypoints. See [Create a paypoint](/developers/api-reference/paypoints/create-a-paypoint).
* **Payment methods:** Create, list, get, update, and deactivate a business's payment methods. See [Create payment methods](/developers/api-reference/payment-methods/create-payment-methods).
* **Templates:** List, get, and archive templates, and get a template version. See [List templates](/developers/api-reference/boarding-templates/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](/developers/api-reference/applications/create-an-application), [Validate an application](/developers/api-reference/applications/validate-an-application), and [Submit an application](/developers/api-reference/applications/submit-an-application).

Legacy boarding is deprecated and will be sunset in Q2 2027. See [Migrate from legacy boarding](/guides/pay-ops-developer-boarding-legacy-migrate), the [intelligent boarding overview](/guides/pay-ops-boarding-object-model-overview), and [Board a new business](/guides/pay-ops-developer-boarding-new-entity-paypoint).

## 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](/developers/api-reference/moneyout/get-the-next-check-number), [Reissue a payout transaction](/developers/api-reference/moneyout/reissue-a-payout-transaction), and the [API response codes reference](/developers/api-reference/api-responses).

## 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:

* [Get list of payouts for entrypoint](/developers/api-reference/query/get-list-of-payouts-for-entrypoint)
* [Get list of payouts for organization](/developers/api-reference/query/get-list-of-payouts-for-organization)
* [Cancel a payout transaction](/developers/api-reference/moneyout/cancel-a-payout-transaction)
* [Reissue a payout transaction](/developers/api-reference/moneyout/reissue-a-payout-transaction)

See [Manage payouts with the API](/guides/pay-out-developer-payouts-manage#cancel-a-payout-transaction) and [Reissue payouts with the API](/guides/pay-out-developer-payouts-reissue).

## 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](/developers/api-reference/query/get-list-of-transactions-for-an-entrypoint), [Get list of transactions for an organization](/developers/api-reference/query/get-list-of-transactions-for-an-organization), and [Get details for a processed transaction](/developers/api-reference/moneyin/get-details-for-a-processed-transaction). They also appear on the transaction records in [chargeback](/developers/api-reference/chargebacks/get-list-of-chargebacks-and-returned-transactions-for-an-entrypoint) and [customer](/developers/api-reference/customer/get-customer-record) 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](/guides/pay-in-transevents-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](/developers/api-reference/webhooks-overview).
* **Device query records:** [List devices by paypoint](/developers/api-reference/get-list-of-devices-for-a-paypoint) and [List devices by organization](/developers/api-reference/get-list-of-devices-for-an-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](/guides/pay-in-developer-devices-axium-manage#list-devices-for-a-paypoint).

## 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](/developers/api-reference/cards/cancel-ghost-card), [Manage ghost cards with the API](/guides/pay-out-developer-ghost-cards-manage), and the [API response codes reference](/developers/api-reference/api-responses).

## 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](/developers/api-reference/vendor/update-vendor), then resend the request.

This change affects these endpoints:

* [Authorize a payout](/developers/api-reference/moneyout/authorize-a-transaction-for-payout)
* [Authorize and capture a payout](/developers/api-reference/moneyout/authorize-and-capture-a-payout)
* [Create payout subscription](/developers/api-reference/payout-subscription/create-payout-subscription)
* [Save a payment method](/developers/api-reference/tokenstorage/save-a-payment-method-tokenize), when the request includes `vendorData`

See [Vendor status](/guides/pay-out-developer-vendors-manage#vendor-status) and the [API response codes reference](/developers/api-reference/api-responses).

## 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](/developers/api-reference/vendor/create-vendor) and [Update vendor](/developers/api-reference/vendor/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](/guides/pay-out-developer-vendors-manage#field-requirements-and-validation) and the [API response codes reference](/developers/api-reference/api-responses).

## Vendor and bill imports match vendors by vendor number

[Import vendors](/developers/api-reference/vendor/import-vendor) 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](/developers/api-reference/bill/import-list-of-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](/guides/pay-out-developer-vendors-manage#import-vendors) and [Import bills](/guides/pay-out-developer-bills-manage#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](/developers/api-reference/vendor/create-vendor) and [Update vendor](/developers/api-reference/vendor/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](/developers/api-reference/vendor/get-vendor), [List vendors by paypoint](/developers/api-reference/vendor/get-list-of-vendors-for-entrypoint), [List vendors by org](/developers/api-reference/vendor/get-list-of-vendors-for-organization), and the vendor in bill, payout, payout subscription, transfer, and virtual card responses. [Get payout subscription](/developers/api-reference/payout-subscription/get-payout-subscription) and [Get a payment method](/developers/api-reference/tokenstorage/get-a-payment-method) return it as `issue1099`, in camel case like the other vendor fields in those responses.

[Import vendors](/developers/api-reference/vendor/import-vendor) and [Import bills](/developers/api-reference/bill/import-list-of-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](/guides/pay-out-developer-vendors-manage).

## 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](/developers/api-reference/query/get-list-of-transfers-out-for-entrypoint) and [Get list of outbound transfers for an organization](/developers/api-reference/query/get-list-of-transfers-out-for-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](/guides/pay-out-developer-bills-manage#partially-pay-a-bill) 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`:

* [Get bill](/developers/api-reference/bill/get-bill)
* [Get list of bills for an entrypoint](/developers/api-reference/bill/get-list-of-bills-for-entrypoint)
* [Get list of bills for an organization](/developers/api-reference/bill/get-list-of-bills-for-organization)

## Add invoice data when you update a subscription

[Update subscription](/developers/api-reference/subscription/update-subscription) (`PUT /Subscription/{subId}`) now accepts `invoiceData`, the same invoice object that [Create subscription](/developers/api-reference/subscription/create-a-subscription-or-scheduled-payment) 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](/guides/pay-in-developer-subscriptions-manage#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:

* Pay In: [Payment Authorized](/developers/webhooks/payin-payment-authorized), [Payment Declined](/developers/webhooks/payin-payment-declined), [Payment Funded](/developers/webhooks/payin-payment-funded), [Payment Originated](/developers/webhooks/payin-payment-originated), [Payment Refunded](/developers/webhooks/payin-payment-refunded), [Payment Settled](/developers/webhooks/payin-payment-settled), [Payment Voided](/developers/webhooks/payin-payment-voided), and Payment Rejected (`RejectedPayment`)
* Pay Ops: [Chargeback Received](/developers/webhooks/payops-chargeback-received), [Chargeback Updated](/developers/webhooks/payops-chargeback-updated), [Chargeback Reversal Received](/developers/webhooks/payops-chargeback-reversal), [Pre-Arbitration Received](/developers/webhooks/payops-prearbitration-received), [Retrieval Request Received](/developers/webhooks/payops-retrieval-received), and [ACH Return Received](/developers/webhooks/payops-ach-return-received)

[Payment Approved](/developers/webhooks/payin-payment-approved) already sent `"0"` in this case.