Changelog

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.

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.

Changes for October 6, 2025

API changes

Optional getPaid transaction details

POST /MoneyIn/getpaid: We added an optional includeDetails query parameter to return comprehensive transaction details in the response.

When includeDetails=true, the response now includes a transactionDetails object several important fields such as:

• Complete transaction metadata: Parent organization, paypoint information, gateway transaction IDs, batch details
• Detailed payment data: Masked account information, account type, expiration, holder name, BIN data, and payment breakdown
• Transaction processing details: Response codes, AVS and CVV responses, authorization codes
• Customer information: Complete billing and shipping address details, customer status, and custom identifiers

This enhancement allows you to retrieve relevant initial transaction information without making a separate API call, streamlining your integration and improving efficiency.

See the Pay In Transaction integration guide for a complete example of the transactionDetails object structure and usage.

BatchNumber field format changes

The naming convention for the BatchNumber field has been updated to improve consistency, traceability, and avoid identifier collisions.

Update details

We made this change for a few reasons:

• The previous format could lead to duplicate batch names if more than one batch was created for the same paypointId and serviceName on the same day.
• The date format in the previous convention wasn’t standardized, which could lead to confusion. It’s now standardized to yyyyMMdd.
• We needed to include a unique GUID to help ensure that each batch can be distinctly identified.

Now, the maximum possible length of batchNumber is 65 characters.

Previous format

  "batch_" + paypointId + "_" + serviceName + "_" + batchDate:MM-dd-yyyy

Example: batch_123_card_10-08-2025

New format

  paypointId + "_" + serviceName + "_" + batchDate:yyyyMMdd + "_" + Guid.NewGuid()

Example: 123_card_20251008_3f2504e0-4f89-11d3-9a0c-0305e82c3301

Required action

We recommend you update any integrations and systems that use batchNumber to support the new format.

Changes for September 15, 2025

API changes

Enhanced vCard-related response data

Added paypointId field to some vCard-related endpoint responses. This field provides the unique identifier for the paypoint associated with a vCard.

These endpoints have been updated:

• GET /MoneyOut/vcard/{cardToken}
• GET /query/vcards

Enhanced transfer query response data

GET /query/transfers: Added parentOrgEntryName to the response. This field provides the entryname for the parent organization associated with the transfer.

New error code

Added a new 5004 error code “Invalid Service Fee value” that occurs when a service fee is less than zero. See 5000 codes for more information.

Enhanced chargeback response data

GET /ChargeBacks/read/{Id}: Added the ReplyBy field to the response. This is the date and time by which a response to the chargeback must be submitted. This field helps track chargeback response deadlines and manage dispute timelines more effectively.

Webhook notification changes

We’ve updated how Payabli handles webhook notification retries, and we’ve added new API endpoints to help you monitor and retry sending webhooks on your own, without having to contact Payabli support.

Changed retry behavior

We’ve updated webhook notification retry logic to resend failed notifications up to 2 times in 5-minute intervals instead of 5 times in 5-minute intervals.

New endpoints to support notification log searching and retries

We’ve added comprehensive notification logging and retry functionality to help manage webhook delivery and troubleshoot notification issues.

• POST /v2/notificationlogs: Search notification logs with filtering and pagination. Filter by date range (max 30 days), event type, success status, organization, and paypoint.
• GET /v2/notificationlogs/{uuid}: Get detailed information for a specific notification log entry, including request/response headers and content.
• GET /v2/notificationlogs/{uuid}/retry: Retry sending a specific notification.
• POST /v2/notificationlogs/retry: Bulk retry multiple notifications (maximum 50 IDs per request).

These new endpoints help provide:

• Comprehensive logging: Track notification delivery attempts, response status, success/failure, and timing information
• Detailed debugging: Access request and response headers, content, and error details for failed notifications
• Flexible retry options: Retry individual notifications or process up to 50 notifications in bulk
• Permission-based access: Requires notifications_create or notifications_read permissions

Documentation updates

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

Enhanced chargeback query response documentation

GET /ChargeBacks/read/{Id}: Updated response schema documentation to accurately reflect the data structure returned by the API:

• Reorganized chargeback record fields to match actual API response structure
• Standardized field naming conventions (for example: id → Id, caseNumber → CaseNumber)
• Enhanced field documentation for better clarity
• Added comprehensive documentation for chargeback messages and additional metadata
• Updated examples to show realistic chargeback data with proper field values
• Added comprehensive sample responses demonstrating the full data structure
• Replaced placeholder values with actual data examples

We also enhanced chargeback records with additional organizational and integration data. These were already returned by the API, but weren’t documented yet:

• ParentOrgId: The ID of the parent organization
• ServiceGroup: Service group classification
• DisputeType: Type of dispute classification
• ProcessorName: Name of the payment processor
• messages: Array of chargeback-related messages with detailed message properties

Changes for September 8, 2025

Idempotency changes

For API requests, IdempotencyKey persistence has increased from 1 to 2 minutes. This allows more time to safely retry requests without risk of duplicate processing.

API changes

Enhanced transfer query filtering and response data

Query/transfers endpoints: Added new filtering options and response fields to provide better organization context and external system integration support.

New filter options

Added support for filtering transfers by parent organization and external system identifiers:

• parentOrgName (ct, nct, ne, eq): Filter transfers by parent organization name
• parentOrgId (ct, nct, ne, eq): Filter transfers by parent organization ID
• externalPaypointID (ct, nct): Filter transfers by external paypoint identifier

New response fields

Enhanced transfer records with additional organizational and integration data:

• parentOrgName: The parent organization name
• parentOrgId: The parent organization ID
• parentOrgLogo: The parent organization logo URL
• externalPaypointId: The external paypoint ID for integration tracking

Transfer details query summary enhancements

/Query/transferDetails/ response: Added netBatchAmount to the response to help make the batch amount calculations more clear. The net batch amount is the gross batch amount minus any returns, refunds, billing and fees items, chargebacks, adjustments, and third party payments.

Changes for August 27, 2025

API changes

New Pay In capture functionality

We’ve updated our Pay In capture functionality to provide more flexibility and better support for partial captures. The GET capture endpoint will be sunset on November 24, 2025.

• Added POST /MoneyIn/capture/{transId}: Introduced a new POST endpoint for capturing authorized transactions with enhanced functionality:
  • Partial capture support: Capture amounts as low as 85% of the original authorization
  • Flexible service fee adjustments: Adjust service fees proportionally or as needed when capturing partial amounts
  • JSON request body: More structured and flexible than URL parameters
  • Enhanced validation: Better error handling and validation for capture amounts
• Deprecated GET /MoneyIn/capture/{transId}/{amount}: This endpoint is deprecated and will be removed on November 24, 2025. The GET endpoint only supports capturing the exact authorized amount and can’t handle partial captures or service fee adjustments. All integrations should migrate to the new POST endpoint.

The new POST endpoint provides all the functionality of the GET endpoint plus additional capabilities for partial captures and service fee adjustments.

For full migration guidance and examples, see our updated Authorize and capture transactions guide, which includes:

• Step-by-step migration instructions
• Side-by-side examples of old vs. new endpoint usage
• Real-world scenarios for partial captures
• Best practices for handling captures below the 85% threshold

New EventsData field in batch query responses

Query/batches endpoints: Added new EventsData field to batch records to provide detailed event history for each batch.

• New field: EventsData - Array of events associated with each batch
• Event details include:
  • description: Human-readable event description (for example: “Created”, “Closed”)
  • eventTime: Timestamp when the event occurred
  • refData: Reference data related to the event
  • extraData: Additional contextual information
  • source: Source of the event (for example: “api”, “worker”)

This enhancement provides visibility into batch lifecycle events, enabling better tracking of batch processing states and history.

Documentation updates

As part of an ongoing effort to better align the documentation with the API, we’ve updated the Query/batches response schemas. These changes affect the documentation only, the API itself was already returning this data.

Enhanced batch query response documentation

Query/batches endpoints: Updated response schema documentation to accurately reflect the data structure returned by the API:

Improved field organization

• Reorganized batch record fields to match actual API response structure
• Standardized field types to use appropriate nullable types
• Enhanced field documentation for better clarity

Transfer object documentation

• Added comprehensive documentation for the existing Transfer object in batch records
• Documented all financial breakdown fields including gross amounts, fees, adjustments, and net funded amounts
• Created dedicated QueryBatchesTransfer type definition for better schema organization

Enhanced examples

• Updated examples to show realistic batch data with proper field values
• Added comprehensive sample responses demonstrating the full data structure
• Replaced placeholder values with actual data examples

Changes for August 18, 2025

We’ve released several updates to the API and documentation. These changes are scheduled to go live in Sandbox on August 6, 2025, and in Production on August 11, 2025.

API changes

New endpoints

• GET /Query/transfers/org/{orgId}: Retrieve a list of transfers for an organization. Use filters to limit results. This endpoint supports the same filtering capabilities as the /Query/transfers/{entry} endpoint that lists transfers for a specific paypoint.

Enhanced filtering and data

• /Query/transfers endpoints: Added support for new filter parameters:

  • transferId (in, nin, eq, ne)
  • bankAccountNumber (ct, nct, ne, eq)
  • bankRoutingNumber (ct, nct, ne, eq)
  • batchCurrency (in, nin, ne, eq)

• Enhanced BinData object: Added new fields to provide more detailed card information:

  • binCardIsRegulated: Indicates whether the card is regulated
  • binCardUseCategory: The use category of the card
  • binCardIssuerCountryCodeA3: Three-letter country code for the card issuer

These fields enhance the BinData object used in multiple response schemas, providing more context about the card used in transactions.

• /Query/Transfer: Added new fields to transfer objects:

  • batchCurrency: The currency of the batch
  • batchRecords: Number of records in the batch
  • paypointEntryName: Entry name for the paypoint
  • paypointLegalName: Legal name of the paypoint
  • paypointDbaName: DBA name of the paypoint
  • paypointLogo: Logo URL for the paypoint
  • bankAccount: Bank account information including account and routing numbers

• /Query/Batches and /Query/batchDetails response schema enhancements: Added new fields and modified some fields for enhanced batch reporting:

  • AchHolderType: ACH account holder type
  • AchSecCode: ACH SEC code
  • ChargebackId: Chargeback identifier
  • CfeeTransactions: C-fee transaction details
  • DeviceId: Device identifier
  • EntryPageid: Entry page identifier
  • FeeAmount: Fee amount
  • OrgId: Organization identifier
  • PaymentSettlementStatus: Payment settlement status
  • PayorId: Payor identifier
  • PendingFeeAmount: Pending fee amount
  • RefundId: Refund identifier
  • RetrievalId: Retrieval identifier
  • ReturnedId: Returned transaction identifier
  • splitFundingInstructions: Split funding instruction details
  • TotalAmount: Total transaction amount

Several Query endpoints: Added risk management fields to various Query endpoints, including:

• RiskFlagged
• RiskFlaggedOn
• RiskStatus
• RiskReason
• RiskAction
• RiskActionCode

Enhanced payout authorization

• /MoneyOut/authorize: Added support for storedMethodId in the payment method object. This enhancement introduces a new vault-based approach for managing ACH payment methods, allowing vendors to have multiple stored ACH accounts.

Previous behavior

Before this enhancement, ACH payment details were stored directly in the vendor object as billingData, meaning each vendor could only have one ACH payment method. The system always used that single ACH account for payments.

Example request:

1
{
2
  "entryPoint": "48acde49",
3
  "source": "api",
4
  "paymentMethod": {
5
    "method": "ach"
6
  },
7
  "paymentDetails": {
8
    "totalAmount": 150.00
9
  },
10
  "vendorData": {
11
    "vendorNumber": "ACME-12345",
12
    "billingData": {
13
      "bankName": "Wells Fargo Bank",
14
      "routingAccount": "121000248",
15
      "accountNumber": "1234567890",
16
      "typeAccount": "Checking",
17
      "bankAccountHolderName": "ACME Construction LLC"
18
    }
19
  }
20
}

New behavior

With the new enhancement, vendors can have multiple ACH payment methods stored in a vault. The storedMethodId field allows you to specify which ACH account to use for the payout. See the Payouts with saved ACH payment methods section for more details on how to use this new feature.

New PayOutReturned webhook event

We’ve add the new PayOutReturned webhook event. The PayOutReturned event triggers when a payout is returned. See PayOutReturned for more information.

Updated time format in webhook payloads

We’ve updated the transTime field in the following webhook payloads to a 24-hour format:

• RecoveredTransaction
• ReleasedTransaction
• HoldTransaction

We’ve updated the createdAt field in the following webhook payloads to a 24-hour format:

• ActivatedMerchant
• UpdatedMerchant

Transaction status descriptions in some /Query endpoint exports

We’ve added transaction status descriptions to the exports of several /Query endpoints. These descriptions provide more context about the status of payment transactions. See transaction status descriptions in Pay In statuses for a full reference.

• /Query/transactions and /Query/transactionDetails: Added TransStatusDescription field to provide a human-readable description of the transaction status.
• /Query/batchDetails and /Query/batches: Added PaymentTransStatusDescription field to provide a human-readable description of the payment transaction status.

Export functionality updates

We’ve introduced new export capabilities across Query endpoints, allowing you to export data in CSV or XLSX formats directly from the API. This replaces the Export endpoints, streamlining the process of obtaining data in a file format.

What’s changing

Instead of using separate Export endpoints, you can now add the exportFormat query parameter to existing Query endpoints:

• Supported formats: csv or xlsx
• Response type: File download (instead of JSON)

Migration example

Before (deprecated):

  GET /Export/transactions/csv/12345

After (new method):

  GET /Query/transactions/12345?exportFormat=csv

Endpoints by resource

Bills

Boarding Applications

Invoices

Batch Details

Batches

Outbound Batches

Chargebacks

Customers

Organizations

Payouts

Paypoints

Settlements

Subscriptions

Transactions

Transfers

Transfer Details

Vendors

Virtual Cards

Important notes

• The deprecated Export endpoints will continue to work but are no longer being enhanced or maintained
• All Query endpoints listed above support both csv and xlsx export formats
• When using the exportFormat parameter, the response will be a file download instead of JSON

Documentation updates

As part of an ongoing effort to better align the documentation with the API, we’ve updated several response schemas. These changes affect the documentation only—the API itself hasn’t changed in most cases.

• BinData documentation updates and corrections: Updated field descriptions for better clarity and formatting, including:

  • Improved documentation for binCardBrand, binCardCategory, and binMatchedLength
  • Type corrections for binCardIssuerCountryNumber and binMatchedLength (changed from double to string)

• Example updates: Refreshed examples across multiple endpoints to use proper schema references instead of placeholder [object Object] values.

• Payout query: The payout transaction query response had a complete restructuring with major additions. These fields were added:

  • BatchId
  • ScheduleId (In development)
  • SettlementStatus
  • IsSameDayACH (In development)
  • HasVcardTransactions (In development)
  • PayoutProgram (In development)
  • ParentOrgId Many existing field names had their casing standardized (for example: paypointDbaname → PaypointDbaname) to match what is returned by the API.