> 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 # API changelog This changelog provides an overview of the recent changes made to the Payabli APIs. ## October 27, 2026 # Documentation changes for October 27, 2026 As part of an ongoing effort to better align the documentation with the API, we've documented how RDC check capture handles amount mismatches. This change affects the documentation only; the API was already returning this data. ## Documented amount mismatch handling for RDC check capture When the `checkAmount` you send doesn't match the amount read from the check, the scan fails. The response has `success` set to `false`, `amountDiscrepancyDetected` set to `true`, and an error in the `errors` array. Payabli can configure an organization or paypoint to accept these scans instead. With this setting on, Payabli stores the check with the amount you sent. The response has `success` set to `true`, `amountDiscrepancyDetected` set to `true`, and a warning in the `messages` array. This affects the following endpoint: * [Capture check (RDC)](/developers/api-reference/moneyin/check-capture) See [Amount mismatches](/guides/pay-in-developer-checks-rdc#amount-mismatches) to learn more. ## October 22, 2026 # Documentation changes for October 22, 2026 As part of an ongoing effort to better align the documentation with the API, we've corrected the casing of two paypoint credential fields and corrected the organization details responses. These changes affect the documentation only; the API was already returning this data. ## Corrected ticket amount field casing on paypoint credentials Corrected the casing of the minimum and maximum ticket amount fields in the `Credentials` array from `MinTicket` and `MaxTicket` to `Minticket` and `Maxticket` (type `number`) for these endpoints: * [Get basic paypoint details](/developers/api-reference/paypoint/get-basic-paypoint-details) * [Get basic paypoint details by ID](/developers/api-reference/paypoint/get-paypoint-details-by-id) * [Get paypoint details](/developers/api-reference/paypoint/get-paypoint-details) ## Corrected field casing on organization details Corrected the casing of these organization fields, which the API returns in PascalCase: * `BillingInfo`, `Contacts`, `HasBilling`, `HasResidual`, `ReplyToEmail`, and `Services` * `OrgAddress`, `OrgCity`, `OrgCountry`, `OrgEntryName`, `OrgId`, `OrgLogo`, `OrgName`, `OrgParentId`, `OrgParentName`, `OrgState`, `OrgTimezone`, `OrgType`, `OrgWebsite`, and `OrgZip` * `ContactEmail`, `ContactName`, `ContactPhone`, and `ContactTitle` in the `Contacts` array This correction applies to these endpoints: * [Get organization](/developers/api-reference/organization/get-organization) * [Get basic details by name](/developers/api-reference/organization/get-basic-organization-details-by-entry-name) * [Get basic details by ID](/developers/api-reference/organization/get-basic-organization-details-by-id) * [List suborganizations by organization](/developers/api-reference/organization/get-list-of-organizations-for-entrypoint) ## Corrected nullability of organization billing fields Corrected the fields in `BillingInfo` to show that they can return `null`: `achAccount`, `achRouting`, `billingAddress`, `billingCity`, `billingCountry`, `billingState`, and `billingZip` (type `string`). This correction applies to these endpoints: * [Get organization](/developers/api-reference/organization/get-organization) * [List suborganizations by organization](/developers/api-reference/organization/get-list-of-organizations-for-entrypoint) ## Corrected the organization logo type Corrected `OrgLogo` from a file object to a `string` that contains the logo's URL, and documented `OrgFavicon` (type `string`), the URL of the organization's favicon. This correction applies to these endpoints: * [Get organization](/developers/api-reference/organization/get-organization) * [Get basic details by name](/developers/api-reference/organization/get-basic-organization-details-by-entry-name) * [Get basic details by ID](/developers/api-reference/organization/get-basic-organization-details-by-id) * [List suborganizations by organization](/developers/api-reference/organization/get-list-of-organizations-for-entrypoint) ## Corrected the response format for basic organization details Corrected the response for the basic organization details endpoints. The organization details are returned in `responseData`, alongside `isSuccess` and `responseText`. Also corrected the `entry` path parameter on Get basic details by name: it takes the organization's entry name (`OrgEntryName`), not a paypoint entrypoint. This correction applies to these endpoints: * [Get basic details by name](/developers/api-reference/organization/get-basic-organization-details-by-entry-name) * [Get basic details by ID](/developers/api-reference/organization/get-basic-organization-details-by-id) ## October 20, 2026 ## Payabli MCP server We've released the Payabli MCP server. It connects AI tools, such as Claude, Claude Code, and Cursor, to your organization's Payabli data. Sign in with your Payabli Portal credentials, then ask your AI tool about Pay In and Pay Out activity in plain language. For example, you can ask about transactions, disputes, payouts, bills, vendors, and your organization structure. The server reads data without changing it. It returns only the data that your Payabli user can already see, and it removes sensitive data, such as contact details, bank details, and full card numbers, from responses. To learn what data the server returns and how access works, see [Payabli MCP server overview](/guides/platform-mcp-server-overview). To add the server to your AI tool, see [Connect your AI tool to Payabli](/guides/platform-portal-mcp-server-connect). ## 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](/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. ## October 14, 2026 # Documentation changes for October 14, 2026 As part of an ongoing effort to better align the documentation with the API, we've corrected the payout subscription response schemas. These changes affect the documentation only. The API already returns this data. ## Corrected casing in payout subscription responses The get payout subscription response uses camelCase keys in the `vendor`, `vendor.contacts`, `billData`, and `paymentData` objects. The documentation showed PascalCase keys. For example, the API returns `vendorNumber`, not `VendorNumber`. We've corrected the schemas and the response example. The list payout subscriptions endpoints use PascalCase keys, except in `PaymentData`, which mixes camelCase and PascalCase. `PaymentData` now has its own schema that matches the API. This affects the following endpoints: * [Get payout subscription](/developers/api-reference/payout-subscription/get-payout-subscription) * [List payout subscriptions by paypoint](/developers/api-reference/payout-subscription/list-payout-subscriptions-for-entrypoint) * [List payout subscriptions by org](/developers/api-reference/payout-subscription/list-payout-subscriptions-for-organization) ## Documented additional fields on payout subscription responses Payout subscription responses now document these fields: * `sameDayAch`, `doNotCreateBills`, `allowDuplicatedBills`, `autoConvertSameDayAch`, and `subscriptionType` * `walletType` and `payorSignature` in `paymentData` * `orderId`, `orderIdAlternative`, `orderDescription`, `paymentDescription`, `groupNumber`, `source`, `payabliTransId`, `unbundled`, and `surchargeFee` in `paymentData.paymentDetails` * `vendorPortal` in `vendor`, in the get response only These fields appear on [Get payout subscription](/developers/api-reference/payout-subscription/get-payout-subscription) and on the list endpoints ([by paypoint](/developers/api-reference/payout-subscription/list-payout-subscriptions-for-entrypoint) and [by org](/developers/api-reference/payout-subscription/list-payout-subscriptions-for-organization)). The list endpoints use PascalCase for the top-level fields, such as `SameDayAch`. The get response always returns some of these fields as `null` or `0`, and their descriptions say so. ## Documented additional vendor fields Vendor records now document `VendorPortal`. Their stored payment methods now document `IsDefault`, and their billing data now documents `country`. This affects endpoints that return vendor records, including: * [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 organization](/developers/api-reference/vendor/get-list-of-vendors-for-organization) ## October 5, 2026 # Documentation changes for October 5, 2026 As part of an ongoing effort to better align the documentation with the API, we've corrected the TokenStorage response examples and schemas. These changes affect the documentation only; the API was already returning this data. ## Corrected `referenceId` in TokenStorage response examples The response examples showed `referenceId` as a transaction ID. When you save a payment method, `referenceId` and `methodReferenceId` both return the stored method ID, and `resultText` is `Added`. Use `referenceId` as the `storedMethodId`, because the response doesn't include `methodReferenceId` when you convert a temporary token to a permanent token. When you update or remove a payment method, `referenceId` returns the `methodId` from the request path. This affects the following endpoints: * [Save a payment method](/developers/api-reference/tokenstorage/save-a-payment-method-tokenize) * [Update a payment method](/developers/api-reference/tokenstorage/update-a-payment-method) * [Remove a payment method](/developers/api-reference/tokenstorage/remove-a-payment-method) See [Save a payment method with the API](/guides/platform-developer-tokenization-save-method) to learn more. ## Corrected customer fields on stored method responses The documentation described the `customers` object with payor request fields, but the API returns the customer record. We've documented `firstname`, `lastname`, `email`, `phone`, `address`, `address1`, `city`, `state`, `zip`, `country`, `shippingAddress`, `additionalFields`, `customerEvents`, and `customerPortal`. We've removed `firstName`, `lastName`, the `billing*` fields, `shippingAddress2`, and `additionalData`, which the API doesn't return. This affects the following endpoints: * [Get a payment method](/developers/api-reference/tokenstorage/get-a-payment-method) ## Documented additional fields on TokenStorage responses The TokenStorage responses now document fields the API already returns. Save a payment method returns `pageIdentifier` on successful requests, and `authCode`, `avsResponseText`, `cvvResponseText`, and `vendorId` on declined requests. Get a payment method returns `walletType`. This affects the following endpoints: * [Save a payment method](/developers/api-reference/tokenstorage/save-a-payment-method-tokenize) * [Get a payment method](/developers/api-reference/tokenstorage/get-a-payment-method) ## October 2, 2026 This entry covers changes released on October 2, 2026. ## New Apple Pay domain-verification files Payabli has issued new Apple Pay domain-verification files for sandbox and production. The earlier files stop validating after **October 15, 2026**. If you downloaded your domain-verification file before October 2, 2026, replace it with the new file before October 15 to avoid Apple Pay verification failures. Serve the new file at the same path as before: `/.well-known/apple-developer-merchantid-domain-association`. This change doesn't affect any API endpoints. See [Verify domain ownership](/guides/pay-in-developer-wallets-apple-pay-enable#verify-domain-ownership) for the download links and hosting steps. ## October 1, 2026 This entry covers the API documentation changes released on October 1, 2026. ## New amount fields in document scan results We've added `totalAmount` and `discount` to the OCR result schema for [OCR a file](/developers/api-reference/import/ocr-a-file) and [OCR a base64-encoded string](/developers/api-reference/import/ocr-a-base64-encoded-string). The API already returned both fields. We've also described `netAmount`, which is the subtotal of the document's line items before tax. `netAmount` isn't the amount due. When you create a bill from an OCR result, set the bill's `netAmount` from `totalAmount`. [Use the OCR engine](/guides/pay-ops-developer-ocr-use) now shows the full field mapping for bills. ### Response fields | Field | Type | Description | | ------------- | -------------- | ------------------------------------------------------------------------------- | | `netAmount` | number | Subtotal of the document's line items, before tax. | | `discount` | number or null | Discount on the document. Often `null` even when the document shows a discount. | | `totalAmount` | number | Total amount due on the document, after any discount and including tax. | ## Omitted payout service fees now fall back to the configured fee When the paypoint's ACH payout pricing allows fee overrides, a payout authorized without `paymentDetails.serviceFee` is now charged the configured fee. Before, these payouts were charged no fee. An explicit `0` still means no fee. When the pricing doesn't allow fee overrides, Payabli ignores `serviceFee` and charges the configured fee, which hasn't changed. We've updated the `paymentDetails.serviceFee` description in 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) Reissued payouts are now always charged the configured fee, because the reissue request doesn't accept a service fee. See [Reissue a payout transaction](/developers/api-reference/moneyout/reissue-a-payout-transaction) and [Reissue payouts with the API](/guides/pay-out-developer-payouts-reissue#service-fees). ## September 29, 2026 This entry covers the API changes released on September 29, 2026. ## New unified response codes We've added new decline and error codes to the [Pay In unified response codes reference](/guides/pay-in-unified-response-codes-reference), including a new section for 3-D Secure (3DS) authentication declines. These codes apply to Pay In transactions made with v2 of the API. ### 3-D Secure decline codes The `D2001`-`D2049` range is now reserved for 3DS-related declines. Codes `D2001` through `D2023` cover issuer declines and challenges, cardholder authentication failures, duplicate authentication values, and 3DS processing errors. All return HTTP status `402`. ### Other new response codes | Code | HTTP Status Code | Reason | | ------- | ---------------- | ----------------------------------------------- | | `D0328` | 402 | Invalid amount or currency | | `D0482` | 402 | Missing or incorrect wallet type | | `D0533` | 402 | Invalid MAC received | | `E5050` | 400 | Surcharge not allowed for card type | | `E5051` | 400 | Surcharge not allowed for non-US issued card | | `E5052` | 400 | Surcharge not allowed at this paypoint location | | `E5053` | 400 | Surcharge not allowed for payor's location | | `E5054` | 400 | Paypoint not registered for surcharging | | `E5055` | 400 | Surcharge not allowed with service fee | | `E5056` | 400 | Calculated surcharge amount mismatch | | `E7069` | 400 | Device busy | | `E9070` | 400 | Device timeout | | `E9075` | 400 | Transaction canceled by user | See the [Pay In unified response codes reference](/guides/pay-in-unified-response-codes-reference) for the full description and resolution text for every code. ## September 22, 2026 # Documentation changes for September 22, 2026 As part of an ongoing effort to better align the documentation with the API, we've corrected the notification log response schemas. These changes affect the documentation only; the API was already returning this data. ## Documented additional fields on notification log responses The notification log responses now document fields the API already returns. The search response documents `requestId`, `notificationType`, `organizationName`, `organizationLogo`, `organizationFavIcon`, `paypointName`, and `paypointLogo`. On the detail response, `webHeaders`, `responseHeaders`, and `responseContent` are now documented as always present. `webHeaders` and `responseHeaders` can return `null` — `responseHeaders` is `null` when the target sent no response. This affects: * [Search notification logs](/developers/api-reference/notification-logs/search-notification-logs-with-filtering-and-pagination) * [Get notification log](/developers/api-reference/notification-logs/get-notification-log) * [Retry notification](/developers/api-reference/notification-logs/retry-notification-log) ## Corrected the response status fields on notification log responses The documentation described a single `responseStatus` string holding the HTTP status code. The API actually returns the HTTP status code in `responseStatusCode` (an integer, `0` when the target sent no response) and a status message such as `OK`, `Dropped`, or `No response received from server.` in `responseStatus`. Both fields are now documented on the endpoints above. ## Corrected the retry response bodies The single-retry endpoint was documented as returning the full notification log entry, but it returns a short confirmation message such as `{"message": "Notification retry succeeded."}`. The bulk-retry endpoint returns a plain-text confirmation. This affects: * [Retry notification](/developers/api-reference/notification-logs/retry-notification-log) * [Bulk retry notifications](/developers/api-reference/notification-logs/bulk-retry-notification-logs) ## September 18, 2026 # Documentation changes for September 18, 2026 As part of an ongoing effort to better align the documentation with the API, we've corrected several response schemas. These changes affect the documentation only; the API was already returning this data. ## Corrected nullable fields on vendor responses Several `VendorQueryRecord` fields can return `null` and are now documented as nullable — including `Address1`, `Address2`, `City`, `State`, `Zip`, `Country`, `Contacts`, `BillingData`, `PaymentMethod`, `EnrollmentStatus`, `Summary`, the `remit*` and `payee*` fields, and the enrichment fields (`CardAccepted`, `AchAccepted`, `CheckAccepted`, `EnrichedBy`, `EnrichedAt`, `EnrichmentId`). The response's always-present fields are now marked required. This affects: * [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 organization](/developers/api-reference/vendor/get-list-of-vendors-for-organization) ## Corrected `additionalData` type on bill, vendor, payout, and user responses The `AdditionalData` field was documented as a string on several response fields, but the API returns an object. This affects the following endpoints: * [Get bill](/developers/api-reference/bill/get-bill) — `AdditionalData` * [Get vCard](/developers/api-reference/cards/get-vcard) — `associatedVendor.additionalData` * [List payouts by paypoint](/developers/api-reference/query/get-list-of-payouts-for-entrypoint) and [by organization](/developers/api-reference/query/get-list-of-payouts-for-organization) — `Bills[].AdditionalData` * [List payout subscriptions by paypoint](/developers/api-reference/payout-subscription/list-payout-subscriptions-for-entrypoint) and [by organization](/developers/api-reference/payout-subscription/list-payout-subscriptions-for-organization) — `BillData[].AdditionalData` * [List users by paypoint](/developers/api-reference/user/get-list-of-users-for-paypoint) and [by organization](/developers/api-reference/user/get-list-of-users-for-an-org) — `AdditionalData` The `AdditionalData` field was also changed from a string to an object for the following endpoints' request bodies: * [Add bill](/developers/api-reference/bill/add-bill) * [Update bill](/developers/api-reference/bill/update-bill) * [Create payout subscription](/developers/api-reference/payout-subscription/create-payout-subscription) request bodies. ## Corrected `BillDate`/`DueDate` format on bill responses `BillDate` and `DueDate` were documented as a date (`YYYY-MM-DD`), but the API always returns a full timestamp. We changed the documentation to reflect this. This affects the following endpoints: * [Get bill](/developers/api-reference/bill/get-bill) * [List bills by paypoint](/developers/api-reference/bill/get-list-of-bills-for-entrypoint) and [by organization](/developers/api-reference/bill/get-list-of-bills-for-organization) ## September 16, 2026 ## API changes for September 16, 2026 ### New `POST /v2/device/taptopay/activate/challenge` endpoint We added the [Generate Tap to Pay activation code](/developers/api-reference/device/activation-challenge) endpoint. Call it from your backend to issue the short-lived code a Tap to Pay device needs to complete activation. It requires the `pos_create` permission. See [Accept Tap to Pay payments](/guides/pay-in-developer-tap-to-pay) for the full integration guide. ## September 10, 2026 # Documentation changes for September 10, 2026 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. ## Corrected `additionalData` type on boarding owner records Corrected the type of the `additionalData` field from a string to an object on owner records (`ownerData` / `OwnerData` items) for these endpoints: * [List applications for an organization](/developers/api-reference/boarding/get-list-of-applications-for-an-organization) * [Get boarding application by ID](/developers/api-reference/boarding/get-boarding-application-by-id) * [List paypoints for an organization](/developers/api-reference/paypoint/get-list-of-paypoints-for-an-organization) * [Create merchant application](/developers/api-reference/boarding/create-boarding-application) * [Update app](/developers/api-reference/boarding/update-boarding-application) ## September 8, 2026 # API changes for September 8, 2026 ## 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](/developers/api-reference/moneyout/authorize-a-transaction-for-payout) and then [Capture payout](/developers/api-reference/moneyout/capture-an-authorized-payout-transaction) separately. A failed capture doesn't undo the authorization: it returns the capture error and leaves the payout authorized, so retry the capture with `GET /MoneyOut/capture/{referenceId}` rather than resubmitting. The endpoint ignores `autoCapture` in the request body, because it always captures inline. See [Authorize and capture a payout](/developers/api-reference/moneyout/authorize-and-capture-a-payout) and the [Manage payouts guide](/guides/pay-out-developer-payouts-manage#authorize-and-capture-in-one-call). ## Wire and RTP balance error codes split The balance check that runs at authorize time for wire and RTP payouts now returns two distinct error codes instead of one. Error `3729` (`Transaction amount exceeds available payout balance.`) still covers a requested amount greater than the available balance. The new error `3730` (`Payout balance information is unavailable for this paypoint.`) covers a paypoint without balance data, or balance data that can't be read. Before this change, that case also returned `3729`. Both codes return HTTP `400 Bad Request`. See [Send instant payouts](/guides/pay-out-developer-instant-payouts#error-handling) and the [API response codes reference](/developers/api-reference/api-responses). ## Filter chargebacks and returns by amount The chargebacks and returns query ([`GET /Query/chargebacks/{entry}`](/developers/api-reference/chargebacks/get-list-of-chargebacks-and-returned-transactions-for-an-entrypoint) and the `/org/{orgId}` variant) has two new amount filters. `amount` filters by the record's own amount (the top-level `netAmount` in the response), which differs from the existing `netAmount` filter (the original transaction's net) for partial disputes and reversals. `totalAmount` filters by the original transaction's gross, including service and pending fees (`transaction.totalAmount` in the response). Both accept the conditions `(gt, ge, lt, le, eq, ne)`, and you can sort by them with `sortBy=asc(amount)` or `desc(totalAmount)`. We've also registered `replyBy` as an alias for the `replyDate` filter. The response exposes the reply deadline as `replyBy`, but only `replyDate` worked as a filter name, so a `replyBy` filter used to return zero records with a `200` instead of matching. See the [Filters and Conditions Reference](/guides/pay-ops-reporting-overview#filters-and-conditions-reference) for filter syntax. ## Filter payouts by `orderId` The payouts query endpoints now accept an `orderId` filter, matching the filter already available on [`GET /Query/transactions/{entry}`](/developers/api-reference/query/get-list-of-transactions-for-an-entrypoint). Use it to look up a payout by the `orderId` you supplied on the original `MoneyOut` authorize request — for example, for an idempotency check after an `idempotencyKey` error. `orderId` accepts the `eq` and `ne` conditions and matches case-insensitively. The payout query response also now includes `orderId`, which is `null` for payouts that don't have one. This change affects the following endpoints: * [Get list of payouts for paypoint](/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) ## Partial payouts for bills (managed payables) You can now partially pay a bill through managed payables. On the [Authorize payout](/developers/api-reference/moneyout/authorize-a-transaction-for-payout) request, set `totalAmount` below the outstanding balance of the single bill you're paying. The partial amount lives on the payout, not on the bill. The bill moves to the new **Partially Paid** status (`75`) and stays selectable for further payment until it's fully paid. Bill responses, queries, and reports now include `paidAmount` and `outstandingBalance` (outstanding = `netAmount` − `paidAmount`). You can filter for partially paid bills with `?status=75`, and you can subscribe to a new `BillPartiallyPaid` webhook that fires on each partial payout. Paying more than the outstanding balance returns error `3448`, a request with more than one bill returns `3451`, and paying a bill that's already fully paid returns `3411`. Partial payouts are available on request for **managed payables only** — on-demand payout methods stay full-payment-only. Contact the Payabli team to turn on partial payouts for your account. See [Manage bills](/guides/pay-out-developer-bills-manage) and the [API response codes reference](/developers/api-reference/api-responses). ## Documentation updates As part of an ongoing effort to better align the documentation with the API, we've corrected a field name in the response reference. The API itself was already returning this data. This change affects the documentation only. ### `Summary.pageIdentifier` corrected to `pageidentifier` The reference documented the `Summary` object's pagination-token field as `pageIdentifier`, but the API has always returned it as **`pageidentifier`**. We've corrected the schema and examples to match. This affects the response reference for the following endpoints: * [List transactions for an entrypoint](/developers/api-reference/query/get-list-of-transactions-for-an-entrypoint) * [List transactions for an organization](/developers/api-reference/query/get-list-of-transactions-for-an-organization) * [List chargebacks and returned transactions for an entrypoint](/developers/api-reference/chargebacks/get-list-of-chargebacks-and-returned-transactions-for-an-entrypoint) * [List chargebacks and returned transactions for an organization](/developers/api-reference/chargebacks/get-list-of-chargebacks-and-returned-transactions-for-an-org) * [List customers for an entrypoint](/developers/api-reference/customer/get-list-of-customers-for-an-entrypoint) * [List customers for an organization](/developers/api-reference/customer/get-list-of-customers-for-an-organization) * [List devices for a paypoint](/developers/api-reference/get-list-of-devices-for-a-paypoint) * [List devices for an organization](/developers/api-reference/get-list-of-devices-for-an-organization) * [List organizations](/developers/api-reference/organization/get-list-of-organizations-for-entrypoint) * [List paypoints for an organization](/developers/api-reference/paypoint/get-list-of-paypoints-for-an-organization) * [List payout subscriptions for an entrypoint](/developers/api-reference/payout-subscription/list-payout-subscriptions-for-entrypoint) * [List payout subscriptions for an organization](/developers/api-reference/payout-subscription/list-payout-subscriptions-for-organization) * [Get reports generated in the last 60 days for an entrypoint](/developers/api-reference/notification/get-list-of-reports-generated-in-last-60-days-for-entrypoint) * [Get reports generated in the last 60 days for an organization](/developers/api-reference/notification/get-list-of-reports-generated-in-last-60-days-for-organization) * [List notifications for an entrypoint](/developers/api-reference/notification/get-list-of-notifications-for-an-entrypoint) * [List notifications for an organization](/developers/api-reference/notification/get-list-of-notifications-for-organization) * [List vendors for an entrypoint](/developers/api-reference/vendor/get-list-of-vendors-for-entrypoint) * [List vendors for an organization](/developers/api-reference/vendor/get-list-of-vendors-for-organization) * [List subscriptions for an entrypoint](/developers/api-reference/subscription/get-list-of-subscriptions-for-an-entrypoint) * [List subscriptions for an organization](/developers/api-reference/subscription/get-list-of-subscriptions-for-an-org) * [List users for an organization](/developers/api-reference/user/get-list-of-users-for-an-org) * [List users for a paypoint](/developers/api-reference/user/get-list-of-users-for-paypoint) * [List applications for an organization](/developers/api-reference/boarding/get-list-of-applications-for-an-organization) * [Get multi-product boarding applications for a paypoint](/developers/api-reference/boarding/get-multi-product-boarding-applications-by-paypoint) * [List boarding links for an organization](/developers/api-reference/boarding/get-list-of-boarding-links-for-organization) * [List invoices for an entrypoint](/developers/api-reference/invoice/get-list-of-invoices-for-an-entrypoint) * [List invoices for an organization](/developers/api-reference/invoice/get-list-of-invoices-for-an-organization) * [List items for an entrypoint](/developers/api-reference/lineitem/get-list-of-items-for-entrypoint) * [List templates for an organization](/developers/api-reference/templates/get-list-of-boarding-templates-for-organization) Server SDKs keep their existing `PageIdentifier` / `page_identifier` member name for this field, so there's no breaking change for SDK consumers. The casing mismatch made the field always deserialize to `null`. It now decodes correctly. ## August 28, 2026 ## Documentation changes for August 28, 2026 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. ### Added `Summary` field to Paypoint entry responses Paypoint entry responses have always included a `Summary` field: a business description from boarding. It's now documented as string, separate from the existing `summary` counts object. This new `Summary` field is present in the following endpoints: * [Get basic paypoint details](/developers/api-reference/paypoint/get-basic-paypoint-details) * [Get basic paypoint details by ID](/developers/api-reference/paypoint/get-paypoint-details-by-id) * [Get paypoint details](/developers/api-reference/paypoint/get-paypoint-details) ## August 21, 2026 ## Accept card-present payments with AXIUM devices 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](/developers/api-reference/device/generate-device-activation-code) and enter it on the device. Then run a card-present sale through [Make a transaction](/developers/api-reference/moneyinV2/make-a-transaction) with `paymentMethod.method` set to `device`. See the [AXIUM devices quickstart](/guides/pay-in-developer-devices-axium-quickstart) for the end-to-end flow, and [Manage AXIUM devices](/guides/pay-in-developer-devices-axium-manage) to register, list, and monitor terminals. ## August 10, 2026 # API changes for August 10, 2026 ## Logo fields and per-device metrics on device query records The device query endpoints now return four new fields on each record: | Field | Type | Description | | ------------------ | ------- | ----------------------------------------------------------------------------------- | | `paypointLogo` | string | URL of the paypoint's logo, or `null` when the paypoint has no logo. | | `parentOrgLogo` | string | URL of the parent organization's logo, or `null` when the organization has no logo. | | `transactionCount` | integer | Total number of transactions processed by the device. | | `volumeProcessed` | number | Total volume processed by the device, as the sum of net transaction amounts. | Payabli calculates `transactionCount` and `volumeProcessed` per device (by `deviceId`), not per paypoint. All four fields are also filterable through the `parameters` query string: use string operators for `paypointLogo` and `parentOrgLogo`, and numeric operators for `transactionCount` and `volumeProcessed`. ### Affected endpoints * [Get list of devices for a paypoint](/developers/api-reference/get-list-of-devices-for-a-paypoint) * [Get list of devices for an organization](/developers/api-reference/get-list-of-devices-for-an-organization) ## `referenceId` on payout authorization responses Payout authorization responses return `referenceId` in the `responseData` object — the ID you pass to the capture endpoint to settle the transaction. A declined authorization returns `null`, because no transaction is created. See [Authorize payout](/developers/api-reference/moneyout/authorize-a-transaction-for-payout) for the full API reference. ## `allowedActions` on payout query records We've added an `allowedActions` array to each record returned by the payouts query endpoints. It lists the operations currently permitted for a payout, derived on the server from the payout's status, so you no longer have to hardcode status-to-action logic on the client. The field is always present. Possible values are `capture`, `cancel`, and `reissue`, matching the corresponding MoneyOut endpoint verbs. It's empty for terminal statuses such as paid or canceled. Read `allowedActions` directly rather than inferring available actions from `PaymentStatus`. ```json {"allowedActions": ["capture", "cancel"]} ``` ### Affected endpoints * [Get list of payouts for paypoint](/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) ## July 28, 2026 ## Case Management API for bank account changes 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. The account and routing numbers you submit are write-only: they're tokenized and never returned in any response. See [Bank account changes](/guides/pay-ops-bank-account-changes-overview) for the lifecycle and permissions, and the [Case Management API reference](/developers/api-reference/bankChanges/create-bank-account-change) for each endpoint. ## Webhook reference now matches the product We've brought the webhook docs in line with the events the platform sends. The [webhooks reference](/developers/api-reference/webhooks-overview) 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. The event tables in the [notifications overview](/guides/pay-ops-notifications-webhooks-overview) now match the current event catalog. Each row gives the `eventType` value you subscribe with, what triggers the event, its name on the Portal's notification settings page, and a link to its payload. ## July 21, 2026 # Documentation changes for July 21, 2026 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. ## Corrected `onCreate` type on boarding application endpoints Corrected the type of the `onCreate` field from a string to an array of strings on the boarding create- and update-application endpoints. Sending the string form returns a `400` error; pass the value as an array, for example `["submitApplication"]`. * [Create boarding application](/developers/api-reference/boarding/create-boarding-application) * [Update boarding application](/developers/api-reference/boarding/update-boarding-application) ## July 20, 2026 # Documentation changes for July 20, 2026 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. ## Corrected `AdditionalData` type on vendor responses Changed the type of the `AdditionalData` field from `map>` to `map` in the `VendorQueryRecord` object. See [Get vendor](/developers/api-reference/vendor/get-vendor) and [Get list of vendors for entrypoint](/developers/api-reference/vendor/get-list-of-vendors-for-entrypoint) for the full API reference. _Showing the 20 most recent of 88 entries. Append `/llms.txt` to the changelog URL for the complete index._