How you receive them
Alert notifications are sent by thenotify step of your dispute-management workflow. Three things must be in place:
- Dispute alert notifications are enabled for your merchant account. They are off by default. Ask your Payrails contact to enable them.
- Your
dispute-managementworkflow has an event trigger for each alert event you want, followed by anotifystep with event typeexecutionActionCompleted. - A webhook endpoint is registered for the workspace, with the
dispute-managementworkflow and theexecutionActionCompletedevent enabled on it. Without one, thenotifystep runs but nothing is delivered.
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
executionActionCompletedand eventTrigger isexternal - action is empty. Alert notifications do not map to a payment action like
dispute, so do not filter on it - execution.workflowCode is
dispute-managementand execution.merchantReference isdispute-alert-followed by the alert ID - there’s an
alertblock in thepaymentCompositionobjectalert.idis the Payrails alert ID. It stays the same across all events for the alertalert.paymentIdis the Payrails payment the alert was matched to. Absent while the alert is unmatchedalert.programis the alert programme, for exampleEthoca,CDRN,RDR,SAFE,TC40alert.amountis the alerted amountalert.descriptorandalert.arnidentify the transaction on the card statement and the acquirer sidealert.cardBin,alert.cardLast4andalert.networkdescribe the cardalert.transactionDateis when the original transaction took placealert.statusis a Payrails alert status, see belowalert.outcomeis set once the alert has reached an outcomealert.occurredAtis 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).
Delivery notes
- Duplicates are possible.
AlertReceived,AlertExpiringandAlertExpiredare sent once per alert.AlertResolved,AlertDeclinedandAlertUpdatedcan be sent again on a retry. Treatalert.idtogether withalert.statusandalert.occurredAtas your idempotency key. - Events can arrive out of order. Use
alert.occurredAtto 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,AlertReceivedis sent late if it was skipped, followed byAlertUpdated. - 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.
execution.meta also carries amount, and paymentId when the alert was already matched when the execution started.
Dispute alert notification