API changelog

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.

Changes for November 10, 2025

API Changes

New DELETE /MoneyOut/cancel/{referenceId} endpoint

We changed the GET /MoneyOut/cancel/{referenceId} endpoint to a DELETE request to better align with RESTful conventions for resource deletion. The GET /MoneyOut/cancel/{referenceId} endpoint is now deprecated. See Cancel payout for more information.

Updated failure response for POST /PaymentMethodDomain/{domainId}/verify

When verifying a payment method domain, the API sends a failure response with a 200 HTTP response code when the request is processed but the verification fails. We updated the failure response when verifying a payment method domain to better reflect a failure status:

• isSuccess field is now false instead of true
• responseText field is now "Failed" instead of "Success"
• HTTP response code remains 200

New TraceNumber field in PayoutPaid webhook notification

We added a new TraceNumber field to the PayoutPaid webhook notification payload. The TraceNumber field represents the number of the vendor’s ACH credit for a payout transaction.

New AchTraceNumber filter/sort for querying payouts

We added a new AchTraceNumber filter and sort option to the following endpoints:

• GET /Query/payouts/{entry}
• GET /Query/payouts/org/{orgId}

AchTraceNumber filters payouts by ACH trace number. The AchTraceNumber filter accepts the eq and neq conditions. See Filters and Conditions reference for more information.

New ipAddress filter/sort for querying transactions

We added a new ipAddress filter and sort option to the following endpoints:

• GET /Query/transactions/{entry}
• GET /Query/transactions/org/{orgId}

ipAddress filters transactions by the IP address associated with the transaction. The ipAddress filter accepts the eq and neq conditions. See Filters and Conditions reference for more information.

Changes for October 22, 2025

API changes

New splitAmount field in transfer responses

We added a new splitAmount field to transfer-related responses. This field represents the sum of each splitFundingAmount of each record in the transfer, providing better visibility into split funding allocations without requiring additional API calls.

Affected endpoints

• GET /MoneyOut/get-transfers: Added splitAmount to the Summary object in the response
• GET /MoneyOut/get-transfer-detail: Added splitAmount to the Summary object in the response
• GET /MoneyOut/get-transfer-by-id: Added splitAmount to the individual transfer record in the response

What changed

• Added splitAmount as an optional double field in transfer summary and detail responses
• The field will be null if the transfer has no split funding configuration
• The value represents the total of all splitFundingAmount values across all records in the transfer

Example response (GET /MoneyOut/get-transfers)

1
{
2
  "Summary": {
3
    "transferAmount": 935.00,
4
    "splitAmount": 650.22,
5
    "totalNetAmountTransfer": 935.00,
6
    "serviceFees": 30.00
7
  }
8
}

Example response (GET /MoneyOut/get-transfer-by-id)

1
{
2
  "transferAmount": 1004.00,
3
  "splitAmount": 650.22,
4
  "netTransferAmount": 1004.00
5
}

New wallet fields in statistics responses

We added the new inWalletTransactions and inWalletVolume fields to paypoint and organization statistics responses. Only the GET /Statistic/basic/{mode}/{freq}/{level}/{entryId} endpoint is affected.

What changed

• Added inWalletTransactions as an integer field representing the total number of transactions made with wallets in a paypoint or organization
• Added inWalletVolume as a double field representing the total volume of transactions made with wallets in a paypoint or organization

Example response

1
[
2
  {
3
    "statX": "2023-03",
4
    "inTransactions": 150,
5
    "inTransactionsVolume": 25000.5,
6
    "inWalletTransactions": 10,
7
    "inWalletVolume": 1000.5
8
  }
9
]

Changes for October 21, 2025

CaptureAll transaction limit documentation

POST /MoneyOut/captureAll: We clarified the documentation to specify that the maximum number of transactions that can be captured in a single request is 500.

This limit helps ensure optimal performance and reliability when processing bulk payout captures. If you need to capture more than 500 transactions, split them across multiple API calls.