> 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 This entry covers the API changes released on April 13, 2026. ## 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](/guides/pay-in-refunds-enhanced-flow-overview), 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](/guides/pay-in-refunds-enhanced-flow-overview) 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: | If your paypoints... | What to expect | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Already use Enhanced Refund Flow | The `expectedProcessingDateTime` value in `Initiated` responses may reflect a different nightly window. No code changes needed. | | Are newly enrolled in Enhanced Refund Flow | Refund responses may return `Initiated` (with `resultCode` 10 and an `expectedProcessingDateTime`) instead of an immediate `Approved` or `Declined`. The final outcome is delivered asynchronously via `RefundedPayment` or `DeclinedPayment` webhooks. | ### Preparing your integration If your paypoints are being newly enrolled in Enhanced Refund Flow, review the [integration tips](/guides/pay-in-refunds-enhanced-flow-overview#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](/developers/api-reference/vendor/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](/developers/api-reference/vendor/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](/developers/api-reference/bill/add-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](/developers/api-reference/vendor/get-vendor)**: Response now includes enrichment status and payment acceptance fields: `EnrichmentStatus`, `EnrichedBy`, `EnrichedAt`, `EnrichmentId`, `PaymentPortalUrl`, `CardAccepted`, and `AchAccepted`. ### Guides * [Vendor enrichment overview](/guides/pay-out-vendor-enrichment-overview) * [Enrich vendors with the API](/guides/pay-out-developer-vendor-enrichment-integrate) ## New `autoCapture` flag for authorization requests We added a new `autoCapture` boolean flag to the [Authorize payment](/developers/api-reference/moneyout/authorize-a-transaction-for-payout) 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](/guides/pay-out-developer-payouts-manage#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](/developers/api-reference/get-list-of-devices-for-a-paypoint)** (`GET /Query/devices/{entry}`): Returns a paginated list of cloud devices for a single paypoint. * **[List devices by organization](/developers/api-reference/get-list-of-devices-for-an-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](/developers/api-reference/query/get-list-of-virtual-cards-for-entrypoint) and [List vcards by org](/developers/api-reference/query/get-list-of-virtual-cards-for-organization) endpoints. The field identifies whether a record is a single-use virtual card or a ghost card: | Value | Card type | | ----- | ----------------------- | | `0` | Single-use virtual card | | `2` | 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](/guides/pay-ops-webhooks-payloads) for webhook payloads. ## New endpoint: verify bank account details We've added a new [verify bank account details](/developers/api-reference/management/verify-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 | Field | Type | Required | Description | | ------------------- | ------ | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `routingNumber` | string | Yes | Bank routing number to verify | | `accountNumber` | string | Yes | Bank account number to verify | | `accountType` | string | No | Account type, such as `Checking` or `Savings` | | `country` | string | No | ISO country code, such as `US` | | `accountHolderType` | string | Conditional | `personal` or `business`. Required when bank authentication is enabled for the paypoint's organization | | `holderName` | string | Conditional | Account holder's name. Personal accounts use the holder's full name; business accounts use the legal business name. Required when bank authentication is enabled | ### Response fields The `responseData` object includes these verification details: | Field | Type | Description | | ------------------------ | ------- | ----------------------------------------------------------------------------------------- | | `isValid` | boolean | Whether the bank account passed verification | | `verificationResponse` | string | Overall outcome, such as `Pass`, `Verified`, `Declined`, `NoData`, `Bypassed`, or `Error` | | `bankName` | string | Name of the bank associated with the routing number | | `reportedAccountType` | string | Account type reported by the verification network | | `responseCode` | string | Response code from the verification network | | `responseValue` | string | Network-specific response value (for example, `CA11` or `RT00`) | | `responseDescription` | string | Human-readable description of the outcome | | `accountAddedDate` | string | Date the account was first seen by the verification network | | `accountLastUpdatedDate` | string | Date the account record was last updated | | `accountClosedDate` | string | Date the account was closed, if applicable | ## 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](/guides/pay-ops-webhooks-payloads) 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](/guides/pay-ops-webhooks-payloads#holdingapplication) for exact fields.