For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
Get support
HomeDocsAPI ReferenceRelease Notes
HomeDocsAPI ReferenceRelease Notes
  • Get Started
    • Overview
    • Setup
    • Tokenize
    • Process a Payment
    • Report Transactions
    • Validate & Deploy
  • Guides
      • Overview
      • Boarding Webhooks
Get support
LogoLogo
On this page
  • How Webhooks Work
  • Event Types
  • Merchant Boarding Status Events
  • Transaction Reporting Events (Guide coming soon)
  • Webhook Structure
  • Security Headers
  • Retry Policy
  • Getting Started
GuidesWebhooks

Webhooks Overview

Was this page helpful?
Previous

Boarding Webhooks

Next
Built with

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.