Skip to main content
A dispute alert is an early warning from a prevention programme (Ethoca, CDRN, RDR, and similar) that a transaction is about to become a chargeback. Acting on the alert in time, usually with a refund, can stop the chargeback from being filed. Dispute alert notifications tell you when an alert is received, when it is about to expire, and how it ends. They are separate from dispute notifications, which cover chargebacks that have already been filed.

How you receive them

Alert notifications are sent by the notify step of your dispute-management workflow. Three things must be in place:
  1. Dispute alert notifications are enabled for your merchant account. They are off by default. Ask your Payrails contact to enable them.
  2. Your dispute-management workflow has an event trigger for each alert event you want, followed by a notify step with event type executionActionCompleted.
  3. A webhook endpoint is registered for the workspace, with the dispute-management workflow and the executionActionCompleted event enabled on it. Without one, the notify step runs but nothing is delivered.
The event triggers are: An alert can produce more than one event. For example, an alert created already resolved (RDR) sends AlertReceived followed by AlertResolved.

The notification

The important fields in the dispute alert notification include:
  • event is executionActionCompleted and eventTrigger is external
  • action is empty. Alert notifications do not map to a payment action like dispute, so do not filter on it
  • execution.workflowCode is dispute-management and execution.merchantReference is dispute-alert- followed by the alert ID
  • there’s an alert block in the paymentComposition object
    • alert.id is the Payrails alert ID. It stays the same across all events for the alert
    • alert.paymentId is the Payrails payment the alert was matched to. Absent while the alert is unmatched
    • alert.program is the alert programme, for example Ethoca, CDRN, RDR, SAFE, TC40
    • alert.amount is the alerted amount
    • alert.descriptor and alert.arn identify the transaction on the card statement and the acquirer side
    • alert.cardBin, alert.cardLast4 and alert.network describe the card
    • alert.transactionDate is when the original transaction took place
    • alert.status is a Payrails alert status, see below
    • alert.outcome is set once the alert has reached an outcome
    • alert.occurredAt is when the alert last changed. Use it to order events
alert.status can be one of the following: alert.outcome can be one of the following. It is omitted until an outcome exists. Currently supported alert providers are: Chargeblast (Ethoca, CDRN, RDR, SAFE, TC40 programmes).
SAFE (Mastercard) and TC40 (Visa) are fraud-reporting feeds. They are reported to you but no refund action is available.

Delivery notes

  • Duplicates are possible. AlertReceived, AlertExpiring and AlertExpired are sent once per alert. AlertResolved, AlertDeclined and AlertUpdated can be sent again on a retry. Treat alert.id together with alert.status and alert.occurredAt as your idempotency key.
  • Events can arrive out of order. Use alert.occurredAt to keep the latest state and ignore older ones.
  • Unmatched alerts. An alert that is not yet matched to a payment has no alert.paymentId. It is delivered only if your provider configuration is linked to a single workspace. Otherwise the notification is skipped. When the alert is later matched, AlertReceived is sent late if it was skipped, followed by AlertUpdated.
  • Delivery does not block processing. A failed delivery never blocks the alert from being processed. To read the current state of an alert, call the List dispute alerts endpoint.
A notification example: Fields that are not relevant to the alert are omitted in this example. execution.meta also carries amount, and paymentId when the alert was already matched when the execution started.
Dispute alert notification
Last modified on October 16, 2026