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.

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.

New API reference pages

Added full request and response documentation for the following endpoints:

• POST /MoneyOutCard/GhostCard/{entry}: Create ghost card
• PATCH /MoneyOutCard/card/{entry}: Update card status

New integration guide

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.

New API reference pages

Added full request and response documentation for the following endpoints:

• POST /PayoutSubscription: Create payout subscription
• GET /PayoutSubscription/{subId}: Get payout subscription
• PUT /PayoutSubscription/{subId}: Update payout subscription
• DELETE /PayoutSubscription/{subId}: Delete payout subscription
• GET /Query/payoutsubscriptions/{entry}: List payout subscriptions by paypoint
• GET /Query/payoutsubscriptions/org/{orgId}: List payout subscriptions by organization

New integration guide

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.

Input validation for achHolder in TokenStorage

The 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:

• Allowed characters: Letters, numbers, spaces, hyphens, apostrophes, and periods
• Length: 2–100 characters
• Pattern: ^[A-Za-z0-9\s\-'.]+$

Requests with special characters like ~!@#$%^&*() in achHolder are now rejected.

Service fee configuration fields added to paypoint credentials

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.

Added StatementEmail to paypoint details response

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

Autogenerate bank account accountId

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

Affected endpoints

• Create merchant application
• Update merchant application
• Create vendor
• Update vendor

Reissue payout transactions

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.

Updated Postman collection structure

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 name changes

Folder names are now PascalCase without spaces:

Merged folders

Two small folders have been merged into their parent path group:

• Hosted Payment Pages (3 endpoints) is now part of Paypoint
• Ocr (2 endpoints) is now part of Import

No API changes

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.

We’ve improved the documentation for Remote Deposit Capture (RDC) transactions.

Added BOC to achCode documentation

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

Added checkUniqueId to paymentDetails documentation

Added 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 BOC request example

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.

Webhook enhancements

Added ReportedDepositDate field to FundedPayment webhook payload

We added the ReportedDepositDate field to the FundedPayment webhook payload. This field represents the date when the payment was reported as deposited.

bankName added to transfers query endpoints

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:

• Get list of transfers for an organization
• Get list of transfers for a paypoint

Documentation: outbound transfer query endpoints

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.

Fixed date fields in invoice query response

We updated the the API response for the GET /Query/invoices/:entry and GET /Query/invoices/org/:orgId endpoints. The following date fields are now returned as date strings in the "YYYY-MM-DD" format:

• invoiceDate
• invoiceDueDate
• invoiceEndDate

Previously, these fields were returned as datetime strings with a zero value for the time component (example: "2025-12-30T00:00:00"). This change ensures the API response aligns with the documentation. The documentation has not been updated. See List invoices by paypoint for more information.

As part of an ongoing effort to better align the documentation with the API, we’ve updated the add boarding application request schema. These changes affect the documentation only, the API itself was already accepting this data.

Added onCreate field documentation

Added the onCreate field to the request body for POST /Boarding/app/. This field allows you to specify an action to take when the application is created. The only currently supported option is submitApplication. Use this when you have collected eSignature elsewhere or are adding additional locations for an applicant, or when you want to submit an application via API with one call without using the hosted boarding UI or embedded boarding components.

We’re introducing unified response codes for Pay In transactions to provide consistent, standardized codes across all payment processors. This makes it easier to understand transaction outcomes and handle responses programmatically, regardless of which processor is being used.

Payabli’s unified response codes standardize transaction outcomes into three clear categories:

• A codes (A0000-A0099): Approved transactions
• D codes (D0100-D2999): Declined transactions
• E codes (E3000-E9999): Error conditions

Each unified response code includes:

• code: The standardized response code
• reason: Human-readable reason
• explanation: Detailed explanation of what happened
• action: Recommended next steps

We’ve added a comprehensive Pay In unified response codes reference page that documents all unified response codes with their reasons, detailed explanations, and recommended actions. This reference includes codes for approvals, declines, and errors across various payment processors.

New v2 transaction APIs

To support unified response codes, we’ve released v2 versions of some of our core Pay In transaction endpoints. These enhanced endpoints provide:

• Unified response codes with clear approval (A), decline (D), and error (E) categories
• Transaction details automatically included in the response, eliminating the need for a separate call to the get transaction details endpoint.
• Enhanced error messages with explanations and recommended actions

The following v2 endpoints are now available:

• POST /v2/MoneyIn/getpaid: Make a transaction (authorize and capture)
• POST /v2/MoneyIn/authorize: Authorize a card transaction
• POST /v2/MoneyIn/capture/{transId}: Capture an authorized transaction
• POST /v2/MoneyIn/refund/{transId}/{amount}: Refund a settled transaction
• POST /v2/MoneyIn/void/{transId}: Void a transaction

See Pay In transaction APIs v2 for complete documentation on these new endpoints and migration guidance.

V1 transaction API enhancements

We’ve enhanced two v1 transaction-related endpoints to include unified response codes and improved response data.

GET /MoneyIn/GetPaid (Get transaction details)

The get transaction details endpoint response now includes:

• resultCode: Payabli’s unified response code (for example, “A0000”, “D0200”)
• resultCodeText: Human-readable description of the unified response code

POST /MoneyIn/getpaid (Make a transaction)

We’ve enhanced the existing v1 /MoneyIn/getpaid endpoint to include unified response codes alongside transaction details.

When you set the includeDetails query parameter to true, the response now includes:

• resultCode: Payabli’s unified response code (for example, “A0000”, “D0200”)
• resultCodeText: Human-readable description of the unified response code

This enhancement allows you to access unified response codes without migrating to v2 endpoints. The v1 endpoint continues to work exactly as before when includeDetails is set to false.

Query endpoints

Several Pay In query endpoints now include unified response codes in the ResponseData object for each transaction record:

• GET /Query/ListBatchDetails: List batch transaction details
• GET /Query/ListBatchDetailsOrg: List batch transaction details for an organization
• GET /Query/ListBatches: List batches
• GET /Query/ListBatchesOrg: List batches for an organization
• GET /Query/GetTransDetail: Get transaction details

Each transaction record’s ResponseData now includes resultCode and resultCodeText fields alongside the legacy response code fields.

Webhook payload enhancements

We’ve enhanced webhook payloads to include unified response codes alongside legacy processor response codes. These changes provide better consistency and clarity when handling transaction results across different payment processors.

The following four fields have been added to payment notification webhook payloads:

The following webhook notifications now include response code fields:

• ApprovedPayment
• AuthorizedPayment
• VoidedPayment
• RefundedPayment
• DeclinedPayment
• RejectedPayment

See the updated payloads in Webhook notification response reference.