Changelog

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.

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.