API changelog

Enhanced Refund Flow and expanded card processing infrastructure

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.

What’s changing

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:

• The nightly window is now variable. The nightly window, when Payabli performs settlement, ledger reconciliation, and transfer processing, depends on your paypoint’s infrastructure configuration. The timing may differ from the current 5–7 PM ET window. See the nightly window reference table for details.
• More paypoints will be enrolled in Enhanced Refund Flow. If your paypoints are newly enabled, refund and reversal API responses may begin returning an Initiated status where they previously returned Approved or Declined synchronously.

What this means for the API

The refund API contract isn’t changing. The same fields and statuses apply. However, depending on your situation, you may notice different behavior:

Preparing your integration

If your paypoints are being newly enrolled in Enhanced Refund Flow, review the integration tips:

• Handle Initiated as an interim refund status and await the final outcome via webhook
• Store the transId from the Initiated response for reconciliation
• Subscribe to RefundedPayment and DeclinedPayment webhook events
• Don’t retry partial refund requests after receiving an Initiated response, as this creates a second partial refund

Payabli will let you know directly if your paypoints are affected. To test Enhanced Refund Flow in Sandbox, contact the Payabli team.

AI-powered vendor enrichment

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.

New endpoint

• Enrich vendor (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).

Updated endpoints

• Create vendor: Now accepts an optional PDF invoice attachment. When provided, the invoice is scanned and extracted vendor details are merged into the request (empty-field-only, request body fields take precedence).
• Create bill: When the first attachment is a PDF, it triggers an invoice scan that populates vendor and bill fields from the extracted data.
• Get vendor: Response now includes enrichment status and payment acceptance fields: EnrichmentStatus, EnrichedBy, EnrichedAt, EnrichmentId, PaymentPortalUrl, CardAccepted, and AchAccepted.

Guides

• Vendor enrichment overview
• Enrich vendors with the API

New autoCapture flag for authorization requests

We 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.

Query cloud devices endpoints

We’ve added new query endpoints for listing cloud device records, following the same pattern as existing query endpoints for transactions, customers, and subscriptions.

New endpoints

• List devices by paypoint (GET /Query/devices/{entry}): Returns a paginated list of cloud devices for a single paypoint.
• List devices by organization (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.

New cardType field on vCard query endpoints

We’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.

Added entryPoint field to all Pay Out webhook payloads

We added the entryPoint field to all webhook payloads for Pay Out events. See the Webhook notification response reference for webhook payloads.

New endpoint: verify bank account details

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.

Request fields

Response fields

The responseData object includes these verification details:

Documentation changes for April 13, 2026

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.

Changed FileReceiveError webhook event name to FileReceivedError

Changed the Event field in the importFileError webhook from FileReceiveError to FileReceivedError. The webhook contains the same information.

Changed PolicyId field from a number to a string

Changed the PolicyId field from a number to a string in the following webhooks:

• CreatedApplication
• FailedBoardingApplication
• ApprovedApplication
• SubmittedApplication
• DeclinedApplication
• HoldingApplication
• BoardingApplication

See the Webhook notification response reference for webhook payloads.

Removed the UnderWritingApplication webhook event

We 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.