Changelog

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.

Changes for July 21, 2025

We’ve released several updates to the API and documentation. These changes are scheduled to go live in Production on July 21, 2025.

New: Process card payments in Canada

We’ve added support for processing card payments in Canadian dollars (CAD). This solution extends our core card-not-present processing capabilities to Canada-based customers while providing the same level of SaaS partnership support and revenue-sharing flexibility we offer today. Contact the Payabli team to learn more about using this functionality.

To process a card payment in CAD via the API, use the same API endpoints as for US processing. The only difference is that you must specify the CAD currency in your requests. See Process card payments in Canada for more information.

API changes

• Removed method from the /Query/transferDetails endpoint response. This was a duplicate field, and Methodis the correct field to use.

• Added Currency to the Credentials object in the GET /Paypoint/details endpoints. This field indicates the default currency for a paypoint, and returns either USD or CAD, depending on the paypoint’s settings.

• We’ve added new fields to the boarding application data structures to capture sales representative information. These fields are:

  • RepCode: The code of the sales representative.
  • RepName: The name of the sales representative.
  • RepOffice: The office location of the sales representative.

  This change affects the following endpoints:

  • GET /Query/boarding/{orgId}: The response now includes the new sales rep fields, and the request now allows filtering by these fields.
  • PUT /Boarding/app/{appId} and POST /Boarding/app: The request now allows setting the rep fields.
  • All GET /Boarding/read/ endpoints: The responses now include the new rep fields.

New webhooks for payout subscriptions

We’ve added new webhook notifications for payout subscriptions:

• PayoutSubscriptionCreated: triggered when a payout subscription is created
• PayoutSubscriptionUpdated: triggered when a payout subscription is updated
• PayoutSubscriptionCanceled: triggered when a payout subscription is canceled
• PayoutSubscriptionCompleted: triggered when a payout subscription is completed
• PayoutSubscriptionReminder: triggered when a payout subscription is about to renew

Documentation updates

As part of an ongoing effort to better align the documentation with the API, we’ve updated the response schema for the GET /Paypoint details endpoints. These changes affect the documentation only The API itself hasn’t changed.

We aligned field casing and added missing fields in the Credentials object in response schema for GET /Paypoint/details endpoints. Note that this change doesn’t affect the Hosted Paypoint endpoints on the Paypoint route.

Old schema:

1
  credentials:
2
    properties:
3
      accountId: optional<string>
4
      cfeeFix: optional<double>
5
      cfeeFloat: optional<double>
6
      cfeeMax: optional<double>
7
      cfeeMin: optional<double>
8
      maxticket: optional<double>
9
      minticket: optional<double>
10
      mode: optional<integer>
11
      referenceId: optional<long>
12
      service: optional<string>

New schema:

1
    Credentials
2
      properties:
3
      Service: optional<string>
4
      Mode: optional<integer>
5
      MinTicket: optional<double>
6
      MaxTicket: optional<double>
7
      CfeeFix: optional<double>
8
      CfeeFloat: optional<double>
9
      CfeeMin: optional<double>
10
      CfeeMax: optional<double>
11
      AccountId: optional<string>
12
      ReferenceId: optional<long>
13
      acceptSameDayACH: optional<boolean> ## Not in use yet
14
      Currency: optional<string> ## Field added as part of the Canadian card processing update

Documentation updates for July 11, 2025

As part of an ongoing effort to better align the documentation with the API, we’ve updated several API references. These changes affect the documentation only. The API itself hasn’t changed.

MoneyIn API response schema updates

We’ve overhauled all MoneyIn API response schemas to align with what’s returned by the API. Key changes include:

• Field casing consistency: Aligned field casing across all response objects
• Required vs optional fields: Updated responses to appropriately mark which fields will always return a value (required) vs those that can return null to match actual API responses.

Affected endpoints

The following MoneyIn endpoints have updated documentation:

• /MoneyIn/authorize - Response field casing corrections
• /MoneyIn/capture - New specific response type with corrected field names
• /MoneyIn/getpaid - New specific response type with updated examples
• /MoneyIn/validate - Updated request requirements and response structure with corrected field names
• /MoneyIn/void/ - New specific response type with corrected field names
• /MoneyIn/reverse/ - Updated response structure with new roomId field
• GET /MoneyIn/refund/ - Updated response structure with corrected field names and casing fix for pageidentifier
• POST /MoneyIn/refund/ - Updated response structure with corrected field names and casing fix for pageidentifier

Request schema updates

• /MoneyIn/validate: Added required fields cardexp, cardzip, and cardHolder to the payment method object, and made entryPoint required
• Various endpoints: Removed cardcvv requirement from validation requests where not needed

What this means for you

Our API docs now match what the API returns. The examples have also been updated with realistic data that reflects actual API responses.

Documentation updates for July 10, 2025

As part of an ongoing effort to better align the documentation with the API, we’ve updated several API references. These changes affect the documentation only. The API itself hasn’t changed.

VendorData response object changes

We’ve updated the VendorData object that’s returned in some responses to change AdditionalData to additionalData to align with what’s returned by the API.

Statistics APIs response schema updates

We’ve overhauled all Statistics APIs response schemas to align with what’s returned by the API.

Webhook payload schema updates

We’ve overhauled all webhook payload schemas to align with what’s returned by the API. See the updated payloads in Webhook notification response reference.

Global changes

The following changes apply to webhook payloads for all events except transfer events:

• Renamed the externalPaypointID field to ExternalPaypointId.
• Renamed the entryPoint field to EntryPoint.

Payment events

We’ve updated the webhook payloads for payment events.

WalletType

Added the WalletType field to the following webhook payloads:

• ApprovedPayment
• AuthorizedPayment
• DeclinedPayment
• VoidedPayment
• RefundedPayment
• OriginatedPayment
• SettledPayment
• ReceivedChargeBack

For response bodies with a Method value of wallet, the WalletType field will either have a value of apple_pay or google_pay. For response bodies with a Method value that isn’t wallet, the WalletType field will have a value of null.

transDate

Added the transDate field to the following webhook payloads:

• RecoveredTransaction
• HoldTransaction
• ReleasedTransaction

The transDate field contains the date of the transaction in MM/DD/YYYY format.

AccountType

Added the AccountType field to the AuthorizedPayment webhook payload. If the transaction is an ACH transfer, the AccountType field will contain the type of bank account used for the transaction. If the transaction is a card payment, the AccountType field will contain the brand of the card used for the transaction.

Subscription events

We’ve updated the webhook payloads for subscription events.

Changes

Added the Changes field to all subscription events. The Changes field contains the details of the subscription modifications. For SubscriptionUpdated, the Changes field will contain the list of modified fields in the subscription, such as "EndDate, Frequency, TotalAmount". For SubscriptionCreated, SubscriptionUpdated, and SubscriptionDeleted, the Changes field will contain the value "Created", "Updated", or "Deleted", respectively.

Billing events

We’ve updated the webhook payloads for bill and payout events.

CustomerName

Added the CustomerName field to webhook payloads for billing events. The CustomerName field contains the name of the customer being billed.

TransId

Added the TransId field to webhook payloads for billing events. The TransId field contains the ID of the transaction in the bill.

CustomerId

Changed the CustomerId field to contain the numeric identifier for the customer.

Transfer events

We’ve updated the webhook payloads for transfer events.

AvailableBalance

Added the AvailableBalance field to the TransferBalanceUnavailable webhook payload. The AvailableBalance field contains the available balance of the account.

Difference

Added the Difference field to the TransferBalanceUnavailable webhook payload. The Difference field contains the difference between the requested amount and the available balance.

AdjustedAmount

Added the AdjustedAmount field to the TransferAdjusted webhook payload. The AdjustedAmount field contains the adjusted amount of the transfer.

Fraud alert events

We’ve updated the webhook payloads for fraud alert events.

LastFourDigitsOfAccountNumber

Added the LastFourDigitsOfAccountNumber field to fraud alert webhook payloads. The LastFourDigitsOfAccountNumber field contains the last four digits of the account number of the fraud alert.

CardDeclineReason

Added the CardDeclineReason field to fraud alert webhook payloads. The CardDeclineReason field contains the reason why the card transaction was declined.

Application events

We’ve updated the webhook payloads for application events.

PolicyId

Added the PolicyId field to all webhook payloads for boarding applications. The PolicyId field contains the identifier for the policy of the application.

ApplicationToken

Added the ApplicationToken field to all webhook payloads for boarding applications. The ApplicationToken field contains the unique token for the application.

ExternalPaypointId

Added the ExternalPaypointId field to all webhook payloads for boarding applications. The ExternalPaypointId field contains the identifier for the paypoint of the application.

Merchant events

We’ve updated the webhook payloads for merchant events.

Service

Added the Service field to the ActivatedMerchant and UpdatedMerchant webhook payloads. The Service field contains the service type of the merchant.

ProcessorId

Added the ProcessorId field to the ActivatedMerchant and UpdatedMerchant webhook payloads. The ProcessorId field contains the identifier for the payment processor.

AccountId

Added the AccountId field to the ActivatedMerchant and UpdatedMerchant webhook payloads. The AccountId field contains the account identifier for the merchant.

AppID

Added the AppID field to the UpdatedMerchant webhook payload. The AppID field contains the identifier for the boarding application of the merchant.

Documentation updates for July 8, 2025

As part of an ongoing effort to better align the documentation with the API, we’ve updated several API references. These changes affect the documentation only. The API itself hasn’t changed.

All /Bill endpoints

We’ve updated the /Bill endpoints response schemas to add complete field coverage and proper structure alignment to match the actual API response format. We made the following changes:

• Updated the bill-related /Query response structure to wrap summary fields under a Summary object to match the actual API response format.
• Added missing fields to bill record schemas: Discount, DocumentsRef, EndDate, EntityID, LotNumber, ParentOrgId, paylinkId, and TotalAmount.
• Added managed payment method to reflect all supported payment types.
• Updated field casing throughout bill-related response schemas (for example, address1 → Address1) to match the actual API responses.
• Added standard response fields (pageIdentifier, roomId, responseCode, isSuccess, responseText) to all bill operation endpoints for consistency.
• Enhanced examples with more comprehensive sample data including transaction details, vendor information, and bill event histories to better reflect real-world API responses.

Bill-related file operation endpoints We’ve updated file-related endpoint documentation to properly reflect response structures:

• Updated getAttachedFromBill response documentation to accurately describe both binary file and Base64-encoded object response formats.
• Added standard response fields to file operation endpoints for consistency with other API responses.

Vendor data response schema changes

We’ve updated the vendor data response schemas to ensure complete field coverage and proper casing alignment:

• Updated to include all vendor fields with proper casing to match actual API responses.
• Added missing vendor fields including CreatedDate, LastUpdated, customField1, customField2, ParentOrgId, ParentOrgName, and various paypoint-related fields.
• Enhanced vendor examples with complete billing data, contact information, and additional metadata to better represent actual API responses.

Documentation updates

As part of an ongoing effort to better align the documentation with the API, we’ve updated several API references. These changes affect the documentation only. The API itself hasn’t changed.

All /Customer endpoints

We’ve updated the /Customer endpoints response schemas to add complete field coverage and proper ordering to match the actual API response structure. We made the following changes:

• Added the missing ParentOrgId field to request and response schemas.
• Added the missing pageIdentifier field to request and response schemas.
• Reordered the fields to match the exact sequence returned in API responses.
• Improved the examples with richer sample data for complex nested objects like customer summaries, stored payment methods, and subscription details to better reflect real-world API responses.

New signer fields for boarding apps

We’ve added new fields to the signer object in the boarding apps. These fields are designed to help you better manage and track your signers during the onboarding process.

The new fields include:

• pciAttestation: A boolean indicating whether the signer has completed the PCI attestation.
• attestationDate: The date when the PCI attestation was completed.
• signDate: The date when the signer signed the agreement.

Documentation updates

As part of an ongoing effort to better align the documentation with the API, we’ve updated several API references. These changes affect the documentation only. The API itself hasn’t changed.

GET /Query/invoices/ endpoint

We’ve updated response schema and examples.

• Added missing fields to the schema:
  • ParentOrgId
  • pageIdentifier
• Reordered the fields in the example and schema to accurately reflect what’s returned by the API.

GET /Invoice/{idInvoice} endpoint

We’ve updated response schema and examples.

• Reordered the fields in the example and schema to accurately reflect what’s returned by the API.
• Updated field casing to accurately reflect what’s returned by the API:
  • customer → Customer
  • paypointLegalname → PaypointLegalname
  • paypointDbaname → PaypointDbaname
  • paypointEntryname → PaypointEntryname
  • parentOrgName → ParentOrgName
  • documentsRef → DocumentsRef

New discount field for payouts

We’ve added a new discount field to the /MoneyOut/authorize endpoint in the API. This field represents any vendor discounts applied to the payout. This field is optional, and is returned in payout transaction detail and query responses.