Skip to content
Rapid Documentation

↑↓ navigate ↵ open Ctrl↵ new tab esc close

Overview

Rapid delivers alerts and events to the customer’s system through an HTTPS POST webhook. Your application exposes a URL, and Rapid sends requests to it every time there is an alert to notify.

The webhook is the universal delivery mechanism. Today two products use the channel:

  • Alert: chargeback_alert.received: a new alert arrived.
  • Dispute: dispute.fraud.revoke_access: a fraud dispute arrived and the card network requires cutting off the cardholder’s access.

There is a single URL; the event field (and the X-Webhook-Event header) says which event arrived. Any future product uses the same channel.

Internally, providers are identified by slugs in payloads and responses: ethoca_alerts (Mastercard) and verifi_rdr (Visa).

Flow in short

Section titled “Flow in short”
  1. You register your endpoint URL in the Rapid dashboard; Rapid generates the signing key and shows it only once
  2. When an alert is received and matched to your company, Rapid queues the delivery
  3. Rapid makes an HTTP POST to your URL with the event payload
  4. Your application validates the signature in the X-Webhook-Signature header, processes the event and returns 200 or 204
  5. If your application returns an error or does not respond, Rapid tries again (see Retries and logs)

Configuration

Section titled “Configuration”
  • Each company can have one active webhook at a time.
  • The signing key (secret) is generated by Rapid at registration, shown only once and used to validate the HMAC-SHA256 signature. Lost it? Generate another one in Settings › API (the previous one stops working immediately).
  • If the webhook is inactive, events are still stored and visible in the dashboard, but they are not delivered. An access revocation that was not delivered shows up as a pending item on the dispute, for manual handling.

Next steps

Section titled “Next steps”