This changelog provides an overview of the recent changes made to the Payabli APIs.
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.
BatchId type on payout detailsCorrected the type of the BatchId field from string to number on the GET /MoneyOut/details/:transId endpoint response.
See Get payout details for more information.
SettlementStatusName and EntityId to payout detailsAdded documentation for two fields on the GET /MoneyOut/details/:transId endpoint response:
SettlementStatusName (nullable string, the name of the settlement status)EntityId (nullable string, the entity’s ID in Payabli).See Get payout details for more information.
Contacts type on vendor recordsCorrected the type of the Contacts field on vendor records from a single object to an array of objects. This affects the following endpoints:
This entry covers the API changes released on June 1, 2026.
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 also added descriptions to the existing D1000, D1001, D1002, and D1003 codes and clarified their resolution steps.
We revised the description, resolution, or both for these existing codes:
See the Pay In unified response codes reference for the full description and resolution text for every code.
This entry covers the API changes released on May 11, 2026.
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.
Subscribe to the new CardUpdaterComplete notification event to receive each paypoint run’s results by email (CSV) or webhook. See Card Account Updater for the result code reference and setup, and the Notifications overview for the event.
Contact your Payabli representative to enable Card Account Updater on one or more paypoints, or across your entire organization.
We’ve updated the supported filter operators on the List vcards by paypoint and List vcards by org endpoints. Identifier filters now support numeric range comparisons, and string filters support starts-with and ends-with matching.
The sw (starts with) and ew (ends with) operators are new across the API. See the Filters and conditions reference for the full operator list.
All other filters and response fields are unchanged.
We’ve documented two endpoints for retrieving virtual card transactions:
GET /Query/vcardsTransactions/{entry})GET /Query/vcardsTransactions/org/{orgId})Each record returns virtual card and transaction details, with filters covering both transaction-level fields and the underlying card. See either endpoint’s API reference for the full field and filter list.
We added the Reject transaction status in the Payabli API.
This new status is for transactions that were rejected by the issuing bank or card network after being authorized or settled.
See Card rejection for more information.
We also added new features across the API to allow users to filter for transactions with card rejections and see the amounts rejected.
Reject transaction statusThe Reject transaction status has a value of -4.
This status indicates that a transaction was rejected by the issuing bank or card network after being authorized or settled.
When querying transactions with the List transactions for paypoint or List transactions for org endpoints, a value of -4 is returned in the TransStatus field for transactions that were rejected.
See the Money in transaction status reference for the full list of transaction statuses and their meanings.
Reject value for operation filterThe operation filter on the List transactions for paypoint and List transactions for org endpoints now supports the Reject value.
Use this value to filter for transactions that were rejected by the issuing bank or card network after being authorized or settled.
See the Filters and conditions reference to learn more about using filters to query transactions.
cardRejectedAmount fields on transfer details endpointWe added two new cardRejectedAmount fields to the Get transfer details endpoint.
The cardRejectAmount field in the Summary object reflects the total amount of all transactions in the transfer that were rejected by the issuing bank or card network after being authorized or settled.
The cardRejectAmount field in each Record object reflects the amount of that specific transaction that was rejected.
See the endpoint’s API reference for the full response shape.
StoredMethod field and idPmethod filter on subscription queriesThe List subscriptions by paypoint and List subscriptions by organization endpoints now return the full stored payment method linked to each subscription as a new StoredMethod object. Both endpoints also accept a new idPmethod filter that narrows results by the linked stored method’s identifier. See either endpoint’s API reference for the full field list and operators.
SubscriptionType field and filter on subscription queriesThe List subscriptions by paypoint and List subscriptions by organization endpoints now return a SubscriptionType field on each record and accept a new subscriptionType filter. The field distinguishes Regular subscriptions (fixed-amount recurring) from BalanceDriven subscriptions (amount tracks an outstanding balance), and returns null when no type is assigned. The filter supports eq, ne, in, and nin and accepts values case-insensitively. See either endpoint’s API reference for the full field list and operators.
subscriptionType request parameter and balance-driven subscriptionsThe Create subscription endpoint now accepts a new optional subscriptionType parameter with two values: Regular (the default — a standard fixed-amount recurring subscription) and BalanceDriven. A balance-driven subscription charges the payor’s outstanding balance at run time instead of a fixed amount. Each scheduled run reads the live balance and charges that amount; a zero balance is skipped, not charged.
subscriptionType can’t be changed after the subscription is created.
The Get subscription endpoint now also returns SubscriptionType on the single-subscription response.
scheduleDetails.frequency on the Create subscription and Update subscription endpoints accepts three new values:
firstofmonthfifteenthofmonthendofmonthThese cadences are valid for both Regular and BalanceDriven subscriptions. BalanceDriven subscriptions only accept these three values.
For BalanceDriven subscriptions:
scheduleDetails.startDate is calculated automatically from the chosen frequency. Any value you supply is ignored.scheduleDetails.endDate doesn’t apply — these subscriptions run until cancelled.totalAmount is stored on the schedule. The amount is determined at each run.splitCount field on transaction query responsesThe List transactions for paypoint and List transactions for org endpoints now return a splitCount integer on each transaction record. The value reflects the number of split funding instructions associated with the transaction, matching the length of splitFundingInstructions in the same record.
Date on check event on payout transactionsWe’ve added a new Date on check entry to the Events array on payout transaction records. This event surfaces the exact date the check printer recorded for the check, which is the value most banks expect in a Positive Pay file.
The date is embedded directly in the TransEvent string in M/D/YYYY H:MM:SS AM/PM format. For example: Date on check: 5/11/2026 8:42:22 AM. Strip the Date on check: prefix from the TransEvent value, trim any leading space, and convert the date to the format your bank requires.
For payouts issued before May 11, 2026, the Date on check event isn’t present. Continue using the EventTime of the Captured event as a fallback.
See Integrate Positive Pay for the recommended extraction pattern, and the Get payout details endpoint for the full response shape.
remitEmail filter on vendor query endpointsThe List vendors by paypoint and List vendors by organization endpoints now accept a remitEmail filter that narrows results by the vendor’s remittance email. The filter is case-insensitive and supports the ct, nct, eq, and ne operators, matching the existing email filter.
/ is now allowed in vendor and remittance addressesWe’ve added / to the set of characters allowed in Pay Out vendor street and remittance address fields. This supports common US fractional-house-number formats like 2524 1/2 S Dunsmuir Ave.
The full allowed character set is now letters, numbers, spaces, and . , # ' - & /.
This affects the address fields on Create vendor, Update vendor, and any other endpoint that accepts vendor address data.
This entry covers the API changes released on April 13, 2026.
As part of ongoing infrastructure investments, we’re expanding our card processing rails to deliver greater reliability, stability, and redundancy. As paypoints are enabled on the new infrastructure, some will be newly enrolled in Enhanced Refund Flow, and some that already use Enhanced Refund Flow may see changes to settlement timing.
Enhanced Refund Flow queues card refunds that are submitted during the nightly settlement window or before a transaction has fully settled. This prevents refund declines and protects ledger balances. Two things are changing:
Initiated status where they previously returned Approved or Declined synchronously.The refund API contract isn’t changing. The same fields and statuses apply. However, depending on your situation, you may notice different behavior:
If your paypoints are being newly enrolled in Enhanced Refund Flow, review the integration tips:
Initiated as an interim refund status and await the final outcome via webhooktransId from the Initiated response for reconciliationRefundedPayment and DeclinedPayment webhook eventsInitiated response, as this creates a second partial refundPayabli will let you know directly if your paypoints are affected. To test Enhanced Refund Flow in Sandbox, contact the Payabli team.
We’ve added AI-powered vendor enrichment to automate the collection of vendor payment acceptance info and contact information. This opt-in feature reduces manual vendor research and helps maximize virtual card adoption.
Contact Payabli to enable it for your organization.
POST /Vendor/enrich/{entry}): Triggers invoice scanning, web search, or both for an existing vendor. Supports auto-apply mode (writes extracted data to the vendor record) and review mode (returns raw results for manual confirmation).attachment. When provided, the invoice is scanned and extracted vendor details are merged into the request (empty-field-only, request body fields take precedence).EnrichmentStatus, EnrichedBy, EnrichedAt, EnrichmentId, PaymentPortalUrl, CardAccepted, and AchAccepted.autoCapture flag for authorization requestsWe added a new autoCapture boolean flag to the Authorize payment endpoint.
When the autoCapture flag is set to true, the payout is automatically captured after a successful authorization.
If the payout is authorized with the autoCapture flag set to true, you don’t need to capture the payout.
See Authorize a payout request for more information.
We’ve added new query endpoints for listing cloud device records, following the same pattern as existing query endpoints for transactions, customers, and subscriptions.
GET /Query/devices/{entry}): Returns a paginated list of cloud devices for a single paypoint.GET /Query/devices/org/{orgId}): Returns a paginated list of cloud devices across all paypoints in an organization.Both endpoints support the standard query filters, sorting, and pagination. Filter by device status, type, OS, make, model, serial number, health check timestamps, and paypoint or organization fields.
cardType field on vCard query endpointsWe’ve added a cardType field to the response for the List vcards by paypoint and List vcards by org endpoints.
The field identifies whether a record is a single-use virtual card or a ghost card:
Both endpoints also accept a new cardType filter, which supports equality only. For example, cardType=2 returns only ghost cards.
entryPoint field to all Pay Out webhook payloadsWe added the entryPoint field to all webhook payloads for Pay Out events.
See the Webhook notification response reference for webhook payloads.
We’ve added a new verify bank account details endpoint that verifies a bank account and returns detailed results from the verification network. The endpoint returns rich data, including bank name, account status, response codes, and account dates, to support detailed decision-making and troubleshooting.
The responseData object includes these verification details:
As part of an ongoing effort to better align the documentation with the API, we’ve updated webhook payload schemas. These changes affect the documentation only, the API itself was already accepting this data.
FileReceiveError webhook event name to FileReceivedErrorChanged the Event field in the importFileError webhook from FileReceiveError to FileReceivedError.
The webhook contains the same information.
PolicyId field from a number to a stringChanged the PolicyId field from a number to a string in the following webhooks:
CreatedApplicationFailedBoardingApplicationApprovedApplicationSubmittedApplicationDeclinedApplicationHoldingApplicationBoardingApplicationSee the Webhook notification response reference for webhook payloads.
UnderWritingApplication webhook eventWe removed the UnderWritingApplication webhook.
The HoldingApplication webhook contains the same information as UnderWritingApplication and can be used in the same use cases.
See the HoldingApplication schema for exact fields.
As part of an ongoing effort to improve API documentation coverage, we’ve added complete API reference documentation and an integration guide for ghost card endpoints. These endpoints were already available in the API.
Added full request and response documentation for the following endpoints:
Added Manage ghost cards with the API, a guide covering how to create ghost cards with configurable spending limits and update card statuses.
As part of an ongoing effort to improve API documentation coverage, we’ve added complete API reference documentation and an integration guide for payout subscription endpoints. These endpoints were already available in the API.
Added full request and response documentation for the following endpoints:
Added Manage payout subscriptions with the API, a guide covering how to create, pause, update, and delete recurring vendor payouts. The guide includes request examples for ACH and vCard payment methods.
achHolder in TokenStorageThe Save a payment method and Update a payment method endpoints now validate the achHolder field. The API returns a 400 Bad Request if the value doesn’t meet the following rules:
^[A-Za-z0-9\s\-'.]+$Requests with special characters like ~!@#$%^&*() in achHolder are now rejected.
We’ve added three fields to the credentials object in the GET /Paypoint/{entry} response. These boolean fields expose the paypoint’s service fee configuration:
GreaterValueAllowed — Whether a customer fee greater than the configured service fee is allowed.AbsorbDifference — Whether the paypoint absorbs the difference between the configured service fee and the actual fee charged to the customer.AllowOverride — Whether the configured service fee can be overridden at the transaction level.StatementEmail to paypoint details responseThe GET /Paypoint/{entry} endpoint response now includes a StatementEmail object in the Paypoint data. This object lets you see how billing statement emails are configured for a paypoint.
The StatementEmail object contains:
Sender: The email address that statements are sent from. Always uses a Payabli domain. If null, noreply@payabli.com is used.Recipients: A list of email addresses that receive billing statements.The field is null if statement email hasn’t been configured for the paypoint.
See Get paypoint details for the full response schema.
accountIdWhen you create or update a bank account in the bankData object without providing an accountId, Payabli now generates one automatically. The generated format is acct-{first_digit}xxxxx{last_4_digits}, based on the accountNumber field. The mask always uses five x characters regardless of account number length. For example, account number 123456789 produces acct-1xxxxx6789.
If a generated accountId would duplicate an existing one within the same service at the paypoint, the system appends a numeric suffix to keep it unique (for example, acct-1xxxxx6789-2).
The bank account’s accountId is also used as the identifier for its associated payment connector. This means the accountId you see in the paypoint’s credentials array matches the accountId of the linked bank account.
When you provide a custom accountId, Payabli doesn’t autogenerate one.
You can now reissue a payout transaction with a different payment method using the new Reissue payout endpoint.
Use POST /MoneyOut/reissue when a payout can’t be completed with the original payment method. For example, if a virtual card expires before a vendor redeems it, or an ACH payment is returned by the bank, you can reissue the payout as a check, ACH, or virtual card.
The original transaction must be in Processing or Processed status. The endpoint creates a new transaction and links it to the original through the event history. The original transaction gets a “Reissued” event, and the new transaction includes a reference back to the original.
For details on which payment methods you can reissue to and how the process works, see Reissue payouts with the API.
We’ve updated the tooling that generates our Postman collection. The collection now uses path-based folder grouping, which changes some folder names and merges a few small folders into their parent.
Folder names are now PascalCase without spaces:
Two small folders have been merged into their parent path group:
This is a Postman collection structure change only. No API endpoints, request formats, or response formats have changed. All 231 endpoints are still present in the collection. If you use Postman environment variables or saved requests that reference folder names, you may need to update those references.
Remote Deposit Capture (RDC) documentation enhancements
We’ve improved the documentation for Remote Deposit Capture (RDC) transactions.
achCode documentationAdded BOC (Back Office Conversion) as a documented value for the achCode field in the POST /MoneyIn/getpaid request. BOC is used to convert paper checks received in-person at a point-of-sale or staffed payment location into electronic ACH debits. Only consumer checks are eligible — business, government, and mailed checks aren’t supported.
checkUniqueId to paymentDetails documentationAdded the checkUniqueId field to the paymentDetails object in the POST /MoneyIn/getpaid request. This field is required for RDC transactions where achCode is BOC. Use the id value from the check processing response.
Added a BOC example to the POST /MoneyIn/getpaid endpoint showing a complete RDC payment request, including checkUniqueId, achCode: BOC, and totalAmount in dot-decimal notation.
ReportedDepositDate field to FundedPayment webhook payloadWe added the ReportedDepositDate field to the FundedPayment webhook payload.
This field represents the date when the payment was reported as deposited.
We’ve added the bankName field to transfer-related query endpoints. This field returns the name of the bank associated with the transfer’s bank account.
The following endpoints now include bankName in their responses:
As part of an ongoing effort to better align the documentation with the API, we’ve added missing documentation for three Pay Out query endpoints that retrieve outbound transfer data.
GET /Query/transfersOut/org/:orgId
Query outbound transfers for an organization. Returns a paginated list of transfers with summary information including transfer amounts, status, and associated paypoint details.
See Get list of outbound transfers for an organization for more information.
GET /Query/transfersOut/:entry
Query outbound transfers for a specific paypoint. Returns the same transfer data scoped to a single paypoint.
See Get list of outbound transfers for a paypoint for more information.
GET /Query/transferDetailsOut/:entry/:transferId
Query detailed information for a specific outbound transfer, including individual transaction records, vendor information, bills, and payment data.
See Get outbound transfer details for more information.