This changelog provides an overview of the recent changes made to the Payabli APIs.
This entry covers the API changes released on June 15, 2026.
We’ve added a showSaveMethod boolean to the paymentMethods section of a hosted payment page’s content. Set it to false to hide the “Save payment details for future use” checkbox on the page. It defaults to true, so existing payment pages keep showing the checkbox unless you change it.
The field is available on the payment page endpoints: Create a payment page, Update a payment page, Get payment page details, and Get all payment page details.
The v2 refund endpoints now support refunding split-funded transactions. Refund a settled transaction and Partially refund a settled transaction accept an optional request body with split instructions. Omit the body for a standard refund, or include refundDetails.splitRefunding to refund across the original split recipients. Split refunds now return the unified v2 response format, matching the legacy Refund a settled transaction with instructions endpoint.
Settlement query responses now enrich each item in splitFundingInstructions with the batch and transfer that paid out the split. This applies to Get list of settled transactions for an entrypoint and for an organization.
Each split instruction now carries three additional fields, alongside the existing recipientEntryPoint, AccountId, Description, and Amount. batchNumber and transferId are null when the batch or transfer isn’t yet available:
We’ve deprecated the legacy Pay In transaction lifecycle endpoints. They still work for transactions originally created with the legacy endpoints, but new integrations should use the v2 endpoints, which return the unified response format. Transactions created with a legacy endpoint must be managed with the legacy lifecycle endpoints, and transactions created with a v2 endpoint must be managed with the v2 endpoints. The two sets aren’t interchangeable.
To refund a split-funded transaction, use the Refund a settled transaction endpoint with split instructions in the request body. This replaces the legacy Refund a settled transaction with split instructions endpoint.
We’ve added wire transfer and Real-Time Payments (RTP) as instant payout rails for vendor disbursements. Set paymentMethod.method to "wire" or "rtp" on the Authorize payout endpoint, using the same achHolder, achRouting, achAccount, and achAccountType fields as ACH. Both rails are US domestic only and irrevocable: once captured, a wire or RTP payout can’t be cancelled or reissued.
Instant payouts draw against the paypoint’s available payout balance, which Payabli validates at authorize time for wire and RTP. Two balance-specific errors return error code 3729 with HTTP 400 Bad Request: one when Payabli can’t read the balance, and one when the amount exceeds the available balance.
See Send instant payouts for the full workflow, balance requirements, and lifecycle differences from ACH.
We’ve added the Deposit funds endpoint (POST /Funding/depositFunds) for adding funds to a paypoint’s available payout balance. Deposited funds enter a pending state and become available for instant payouts once confirmed through FBO reconciliation.
The Get basic statistics endpoint (GET /Statistic/basic) now returns four fields that break out outbound RTP and wire activity: outRTPTransactions, outRTPVolume, outWireTransactions, and outWireVolume. Each follows the existing per-rail count and volume pattern and returns 0 when there’s no activity on that rail.
We’ve updated the HTTP status codes the Capture payout and Authorize payout endpoints return when a risk policy acts on a transaction. Both previously returned 400, which incorrectly implied the request itself was invalid.
In both cases the body still carries isSuccess: false and the responseData detail block. 400 is now reserved for structurally invalid requests. Update any integration that treats a 400 on these endpoints as an outright failure, so a held transaction isn’t mistaken for a rejected one. See Manage payouts for details.
Capturing payout statusPayouts now report a transient Capturing status (12) while a capture is in progress, between Authorized (11) and Captured (1). See Pay Out statuses and Manage payouts.
RefundAmountWe’ve added a RefundAmount field to all Pay Out transaction webhooks.
If a vendor partially refunds a transaction, this field contains the amount left of the original transaction after the refund.
Example: If the original transaction was for $100.00, and the vendor issues a partial refund of $30.00, this field has a value of $70.00.
Vendor enrichment now includes an AI outreach call as a third stage. When invoice scanning and web search can’t determine how a vendor wants to be paid, Payabli can schedule an AI agent to call the vendor and collect their preferred payment method and contact email.
We’ve added two endpoints:
POST /Vendor/enrich/schedule_call/{entry}) schedules a call to a vendor.GET /Vendor/{vendorId}/enrichment/call-status) returns the latest call activity for a vendor.The enrich vendor endpoint also accepts a new scheduleCallIfNeeded parameter that triggers the call automatically when the earlier stages return insufficient data.
Outreach calling is in beta and is opt-in. Contact your Payabli representative to enable it, provision a phone number, and discuss pricing. See Vendor enrichment for behavior and Enrich vendors with the API for integration details.
vendorIdWe’ve added a vendorId field to the responseData on the Pay Out Authorize, Capture, and Cancel payout responses. vendorId returns the Payabli vendor ID for the payout, the same value as the existing customerId field, which is unchanged and continues to work. Use vendorId for clearer Pay Out semantics.
type and methodWe’ve added type and method fields to the Pay Out transfer report, returned by Get list of outbound transfers for a paypoint and for an organization.
You can also filter the report by these values with two new filters, detailType and detailMethod. Both support the eq, ne, in, nin, ct, and nct operators. See the reporting engine reference for filter syntax.
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.