Webhook Event Types and Payload Reference

Every webhook event Accelebit dispatches corresponds to a state transition in the payment lifecycle. By subscribing to the right events, you can track a payment from creation through capture — or through failure — and react accordingly in your integration.

Payment events

Event	Description	When it fires
`payment.created`	A new payment has been created.	Immediately after `POST /v1/payments` inserts the transaction record.
`payment.authorized`	Payment was authorized by the provider.	After the upstream provider confirms authorization (Everest flow).
`payment.requires_3ds`	3D Secure authentication is required.	When the provider returns a 3DS challenge for the customer to complete.
`payment.requires_consent`	Auto-debit consent is required.	Everest-specific: after authorization, when consent must be confirmed before capture.
`payment.captured`	Payment was successfully captured. Funds will be settled.	After the full payment flow completes successfully. This is the primary success event.
`payment.failed`	Payment failed or was declined.	When the payment is declined by the issuer, provider, or when consent is rejected.

Refund events

Event	Description	When it fires
`refund.created`	A refund has been initiated.	After `POST /v1/refunds` creates the refund record.

Event payload examples

Each event shares the same top-level structure — event, data, and timestamp — but the contents of data vary by event type. Expand any event below to see its full payload.

payment.created

Fired immediately after a new payment record is inserted.

{
  "event": "payment.created",
  "data": {
    "merchantId": "merchant_abc123",
    "customerId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "amount": 5500,
    "currency": "EUR",
    "paymentMethod": "card"
  },
  "timestamp": "2026-04-09T12:00:00.000Z"
}

payment.captured

Fired when the payment completes successfully and funds are queued for settlement. This is the primary success event to act on.

{
  "event": "payment.captured",
  "data": {
    "merchantId": "merchant_abc123",
    "providerId": "everest",
    "providerTxId": "EVR-1234567890",
    "status": "captured"
  },
  "timestamp": "2026-04-09T12:01:00.000Z"
}

payment.failed

Fired when a payment is declined by the issuer, rejected by the provider, or when consent is denied.

{
  "event": "payment.failed",
  "data": {
    "merchantId": "merchant_abc123",
    "providerId": "everest",
    "errorCode": "CARD_DECLINED",
    "errorMessage": "The card was declined by the issuing bank"
  },
  "timestamp": "2026-04-09T12:01:00.000Z"
}

payment.requires_3ds

Fired when the provider returns a 3D Secure challenge that the customer must complete before the payment can proceed.

{
  "event": "payment.requires_3ds",
  "data": {
    "merchantId": "merchant_abc123",
    "providerId": "everest",
    "providerTxId": "EVR-1234567890",
    "status": "pending_3ds"
  },
  "timestamp": "2026-04-09T12:00:30.000Z"
}

payment.authorized

Fired after the upstream provider confirms authorization. This event is specific to the Everest flow and precedes the consent step.

{
  "event": "payment.authorized",
  "data": {
    "merchantId": "merchant_abc123",
    "providerId": "everest",
    "providerTxId": "EVR-1234567890",
    "status": "authorized"
  },
  "timestamp": "2026-04-09T12:00:30.000Z"
}

Fired after authorization when Everest requires the customer to confirm auto-debit consent before the payment can be captured.

{
  "event": "payment.requires_consent",
  "data": {
    "merchantId": "merchant_abc123",
    "providerId": "everest",
    "status": "pending_consent"
  },
  "timestamp": "2026-04-09T12:00:31.000Z"
}

refund.created

Fired after a refund record is created. The refund amount is in minor units.

{
  "event": "refund.created",
  "data": {
    "merchantId": "merchant_abc123",
    "transactionId": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
    "refundId": "b2c3d4e5-f6a7-8901-bcde-f23456789012",
    "amount": 5500,
    "currency": "EUR"
  },
  "timestamp": "2026-04-09T14:00:00.000Z"
}

Payment lifecycle

The events your integration receives depend on the payment flow. Use the sequences below to understand what to expect for each scenario. Happy path — standard card payment:

payment.created → payment.captured

With 3D Secure authentication:

payment.created → payment.requires_3ds → payment.captured

With Everest authorization and consent:

payment.created → payment.authorized → payment.requires_consent → payment.captured

Failed payment:

payment.created → payment.failed

Webhook amounts are in minor units (cents). Divide by 100 for EUR, GBP, USD, and most currencies. See the API response for the decimal string representation.

Get Started

Guides

Webhooks

Webhook Event Types and Payload Reference

Payment events

Refund events

Event payload examples

Payment lifecycle

​Payment events

​Refund events

​Event payload examples

​Payment lifecycle

Payment events

Refund events

Event payload examples

Payment lifecycle