API changelog

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.

Remote Deposit Capture (RDC) documentation enhancements

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.

API changes for January 26, 2026

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.

Documentation changes for December 30, 2025

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.

Unified response codes for Pay In transactions

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.

Documentation changes for December 12, 2025

Documentation updates

As part of an ongoing effort to better align the documentation with the API, we’ve updated the transaction query response schema. These changes affect the documentation only—the API itself was already returning this data.

Updated SettlementDate field documentation

Added additional context for the SettlementDate field in the responses for GET /Query/settlements/org/:orgId and GET /Query/settlements/:entry. When the SettlementStatus of a transaction is -1, -5, or -6 (Exception, Held, or Released) the value of SettlementDate is null.

Documentation changes for November 26, 2025

Updated documentation for statistics endpoint

We updated the documentation for the GET /Statistic/basic/{mode}/{freq}/{level}/{entryId} endpoint to better reflect the complete response structure with comprehensive Pay In and Pay Out statistics.

The documentation now includes detailed descriptions for all response fields:

General:

• statX - The time window based on the mode and frequency used for the query

Pay Out statistics:

• Metrics for active and new vendors
• Transaction counts by payment method (pCard, vCard, ACH, check, Managed Payables)
• Volume metrics for all outbound (payout) transaction types

Pay In statistics:

• Metrics for active and new customers
• Transaction counts by payment method (card, ACH, check, cash, wallet)
• Chargeback and return metrics
• Volume metrics for all inbound transaction types

See Get Basic statistics for more information.

API changes for November 24, 2025

Updated RefundedPayment webhook to include new field RefundingTransactionId

We updated the RefundedPayment webhook notification payload to include a new field RefundingTransactionId. The RefundingTransactionId field represents the unique identifier of the transaction is being refunded.

See the RefundedPayment webhook body for more information.