Webhooks Overview

Webhooks provide real-time notifications about events within the Run Developer ecosystem. They allow your application to receive instant updates when boarding merchants and running transactions.

How Webhooks Work

When an event occurs in the Run Payments system, we send an HTTP POST request to the configured webhook endpoints. These requests contain detailed information about the event, allowing your application to respond immediately.

Event Types

Run Payments sends webhooks for the following events:

Merchant Boarding Status Events

  • merchant.new - New merchant created
  • merchant.sent_for_signature - Documents sent for signature
  • merchant.signed - Documents signed
  • merchant.in_underwriting - Application in underwriting
  • merchant.boarded - Merchant successfully boarded
  • merchant.live - Merchant account is live
  • merchant.cancelled - Application cancelled
  • merchant.declined - Application declined
  • boarding.varcomplete - VAR Information Completed

Transaction Reporting Events (Guide coming soon)

  • transaction.entered - New transaction entered
  • transaction.decline - Transaction declined
  • transaction.refund - Transaction fully refunded
  • transaction.partialrefund - Transaction partially refunded
  • transaction.reject - Transaction rejected
  • chargeback.entered - New chargeback reported
  • funding.entered - New funding information available
  • statement.entered - New statement available for download

Webhook Structure

All webhooks follow a consistent structure:

1{
2 "event_type": "transaction.entered",
3 "source_id": 12345,
4 "timestamp": "2024-01-15T10:30:00.000Z",
5 "payload": {
6 // Event-specific data
7 },
8 "metadata": {
9 "webhook_id": "wh_abc123def456",
10 "attempt": 1,
11 "idempotency_key": "transaction-entered-12345-20240115103000"
12 }
13}

Security Headers

Every webhook request also includes security headers:

  • Content-Type: application/json
  • X-Webhook-Signature-256: sha256=<hmac_signature>
  • X-Idempotency-Key: <unique_key>

Retry Policy

Failed webhook deliveries are automatically retried according to this schedule:

AttemptDelayTotal Time Since First
1Immediate0 seconds
25 seconds5 seconds
35 minutes5 minutes 5 seconds
430 minutes35 minutes 5 seconds
52 hours2 hours 35 minutes
65 hours7 hours 35 minutes
710 hours17 hours 35 minutes
810 hours27 hours 35 minutes

Maximum Attempts: 8 total (1 initial + 7 retries)

Getting Started

  1. Configure Endpoints: Share webhook endpoints with your Integration Delivery lead.
  2. Implement Handlers: Create endpoint handlers in your application.
  3. Verify Signatures: Always verify webhook signatures for security.
  4. Handle Idempotency: Use the idempotency key to prevent duplicate processing.
  5. Test Thoroughly: Test all event types and error scenarios.

Next Steps