Skip to main content
Workflow actions often call external providers. Those calls can take time or fail, so Payrails sends a notification to your server when each action finishes. Configure your server for receiving notifications before you continue. Every notification uses the same envelope:
  • event: Type of event that happened.
  • time: Date and time of the event.
  • details: Event-specific details.
  • workspaceId: Workspace identifier.
  • eventTrigger: Reason the event was triggered. One of api, action, or external.

Event types

The following events trigger notifications during a workflow.

Structure of the details object

The details object has a small set of top-level envelope fields. Most payment-specific fields — operationType, operationResult, authorizationCode, acquirerReference, providerReference, paymentInstrument, threeDS, and others — sit inside each entry of the paymentComposition array.
The actionId in each notification matches the one returned in the response to the action you performed on the execution.

Top-level details fields

execution details

The execution.providerReference field is deprecated. Use paymentComposition[i].providerReference instead.

paymentComposition details

Each entry in paymentComposition represents one payment attempt within the execution.

Acquirer field availability

The acquirer fields acquirerReference, retrievalReference, acquirerMID, acquirerAccountCode, acquirerCountryCode, accountFundingTransaction, and authorizationCode are populated only when the provider returns them. Coverage varies by provider. If a field your integration needs is missing and the provider does return it, contact your Payrails representative.

paymentInstrument structure

The paymentInstrument object describes the instrument used for the operation. For cards, paymentInstrument.data contains: The binLookup object contains:

tokens structure

Each entry in paymentInstrument.tokens[] describes a token associated with the instrument.

Provider-specific details

To process a requested action, Payrails calls the external provider in its expected format and maps the response to a unified result. Payrails extracts and maps the most important fields to unified fields and result codes. Two fields preserve the provider context:
  • operationProviderReference — identifier of the operation in the provider’s system.
  • operationResultProviderDetails — provider fields used to derive operationResult. Populated on failures.
The following extract shows how Payrails reached the InsufficientBalance result based on three fields from Hyperpay’s response. The message field contains the provider’s human-readable description of the decline reason.
Payrails
The keys in additionalData are JSON Paths to fields in the provider response. Hyperpay’s response looked like this:
Hyperpay
To include more provider-specific fields in your notifications, contact your Payrails representative to add them to providerResponseAdditionalFields inside each paymentComposition entry. For the full raw request and response sent to a provider, use the Get Payment Operation Logs endpoint.

errors details

Notifications describe errors at two levels:
  • The top-level errors array describes the overall action result.
  • The errors array inside each paymentComposition entry describes the errors for that specific payment attempt. This separation matters most for workflows that generate multiple payments per execution.
For the structure of each error item, see error structure.

Examples

Success

Success

Failure

Failure
Last modified on September 30, 2026