This changelog provides an overview of the recent changes made to the Payabli APIs.

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:

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, address1Address1) 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:
    • customerCustomer
    • paypointLegalnamePaypointLegalname
    • paypointDbanamePaypointDbaname
    • paypointEntrynamePaypointEntryname
    • parentOrgNameParentOrgName
    • documentsRefDocumentsRef

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.

New field in the bankData object

We’ve added the accountId field to the bankData object. This field lets you add your own internal identifier for a bank account anywhere the bankData object is used. The accountId field accepts a string of up to 64 characters.

New payout status and summary fields

The response for GET Query/payouts/{entry}/{orgId} endpoint now includes two new Summary fields: totalOnHold and totalOnHoldAmount. These fields help understand how many transactions are on hold, and the total amount of the held payout transactions. We’ve also added a new payout status option with “Status”:4 corresponding to “PaymentStatus”: “OnHold”.

New webhooks for virtual cards

Added new webhook notifications for virtual cards:

New fields in boarding applications and templates

We’ve added several new fields to the boarding applications and templates APIs.

signDate field in boarding applications

We added a new field called signDate to the signerData object in boarding application endpoints. This field represents the date when the signer signed the application. The field accepts a date in YYYY-MM-DD or MM-DD-YYYY format. The signDate field is optional.

additionalData object in boarding templates and applications

We’ve added a new additionalData object to some objects in the boarding applications and templates APIs. You can use this object to store custom information related to the merchant’s business. The additionalData object is optional and can contain any key-value pairs that you want to include in the boarding application or template.

For example:

1{
2 "additionalData": {
3 "customField1": "value1",
4 "customField2": "value2"
5 }
6}

The additionalData object is available for the contacts, ownership, and signer objects and the general business information on /Templates and /Boarding endpoints.

New fields in webhook payloads

We added the externalPaypointID, Method, and entryPoint fields to the webhook payloads for these events:

Change programId field to issuerNetworkSettingsId in boarding endpoints

We changed the programId field to issuerNetworkSettingsId in the boarding endpoints. This field represents the ID of the issuer network settings associated with a payout service. This change was made to better reflect the purpose of the field and to improve consistency across our APIs.