Events

Events provide a complete audit trail of everything that happens in your RevKeen account. Every action -- from customer creation to payment processing -- generates an event that you can view, filter, and react to via webhooks.

What is an event?

An event is a record of something that happened in your account. Each event includes:

What happened -- The event type (e.g., payment.succeeded)
When it happened -- Timestamp
What was affected -- Related entities (customer, invoice, etc.)
Event data -- Snapshot of the object at event time

Viewing events in the dashboard

Navigate to Sales > Events to view the event stream. Events are displayed in reverse chronological order.

Event stream columns

Column	Description
Event Type	What happened (e.g., `payment.succeeded`)
Object	Affected entity (customer, invoice, etc.)
Time	When the event occurred
Webhook Status	Delivery status to your webhooks

Filtering events

Use filters to find specific events:

Event type -- Filter by category or specific type
Date range -- Events within a time period
Related object -- Events for a specific customer, invoice, etc.
Webhook status -- Delivered, failed, or pending

Event details

Click any event to view full details:

Event ID -- Unique identifier
Timestamp -- Exact time of occurrence
Event data -- Full payload (JSON)
Related objects -- Links to customer, invoice, etc.
Webhook deliveries -- Status of each webhook attempt

Events by object

View events for a specific object:

Open any customer, invoice, subscription, etc.
Click the Events tab
See all events related to that object

Event catalogue

These are the events you can subscribe a webhook endpoint to. For guidance on choosing events for a workflow, see the webhook event guide.

RevKeen publishes 58 webhook events. This list is generated from the public API specification; each event links to its payload schema.

Checkout events

Event type	Description
`checkout.session.completed`	Sent when a checkout session is successfully completed. Action required: Fulfill the customer's order.
`checkout.session.expired`	Sent when an open or pending checkout session is expired with `POST /v2/checkout-sessions/id/expire`. A session that only reaches its expiry time without being paid does not send this event.

Invoice events

Event type	Description
`invoice.created`	Sent when a new invoice is created, either manually or from a subscription renewal.
`invoice.paid`	Sent when an invoice is fully paid. Action required: Fulfill the order or activate the subscription.
`invoice.overdue`	Sent when an invoice becomes overdue. Consider sending payment reminders.

Credit note events

Event type	Description
`credit_note.created`	Sent when a credit note is created for an invoice.
`credit_note.issued`	Sent when a credit note is issued (finalized) and its PDF is generated.
`credit_note.voided`	Sent when a credit note is voided (accounting reversal).

Order events

Event type	Description
`order.created`	Sent when a new order is created.
`order.paid`	Sent when an order is fully paid. Action required: Begin fulfillment.
`order.fulfilled`	Sent when an order is marked as fulfilled.

Subscription events

Event type	Description
`subscription.created`	Sent when a new subscription is created (before activation).
`subscription.activated`	Sent when a subscription becomes active after successful payment. Action required: Grant access to your service.
`subscription.canceled`	Sent when a subscription is canceled. Access continues until the end of the billing period.
`subscription.renewed`	Sent when a subscription successfully renews. A new invoice has been created and paid.
`subscription.paused`	Sent when a subscription is paused immediately: by you through the API or the dashboard, or by the customer in the portal. A pause scheduled for the end of the period is not announced when it takes effect. Renewals stop until it is resumed; nothing already issued is voided or recalled. `data.object` is the subscription: `id`, `subscription_id`, `customer_id`, `status` (`paused`), `previous_status` and `effective_date`. Action required: decide whether the customer keeps access while the subscription is paused. Fetch the subscription for its current state.
`subscription.resumed`	Sent when a paused subscription is resumed through the API or the dashboard. A resume the customer makes in the portal is not announced. The periods that elapsed while it was paused are not billed: the next charge is the next billing date after the resume. `data.object` is the subscription: `id`, `subscription_id`, `customer_id`, `status` (`active`), `previous_status` and `effective_date`. Fetch the subscription for its current period and next billing date.
`subscription.plan_changed`	Sent when a subscription moves to another price: through the API (`POST /v2/subscriptions/id/change-plan`) or the dashboard. Nothing is charged when the plan changes; the proration is added to, or credited on, the next renewal invoice. `data.object` carries `subscription_id`, `customer_id`, `status`, `previous_status`, `previous_plan_name`, `new_plan_name`, `amount`, `currency`, `effective_date` and `action_source`. For a change made through the API (`action_source` `api`), `amount` is the new renewal amount in minor units. Fetch the subscription for its current price and amount.

Payment events

Event type	Description
`payment.succeeded`	Sent when a payment is successfully captured. Action required: Provision goods or services to your customer.
`payment.failed`	Sent when a payment attempt fails. Contains failure reason and suggested next steps.

Refund events

Event type	Description
`refund.created`	Sent when a refund is initiated.
`refund.succeeded`	Sent when a refund is successfully processed by the payment gateway.

Void events

Event type	Description
`void.created`	Sent when a void is initiated for an unsettled transaction.
`void.succeeded`	Sent when a void is successfully processed by the payment gateway. The original transaction has been canceled.
`void.failed`	Sent when a void fails (e.g., transaction already settled). Consider using a refund instead.

Customer events

Event type	Description
`customer.created`	Sent when a new customer is created.
`customer.updated`	Sent when customer information is updated.

Direct Debit mandate events

Event type	Description
`mandate.signed`	Sent when a customer signs a Direct Debit mandate instruction. The mandate is pending lodgement with the bank (AUDDIS) — wait for `mandate.activated` before collecting.
`mandate.activated`	Sent when a mandate is lodged and active. Action required: You can now collect from this customer via Direct Debit.
`mandate.suspended`	Sent when a mandate is suspended and can no longer be collected against until reinstated. Also sent when the customer's bank rejects a new mandate's setup (AUDDIS); the failure reason names the rejection. Action required in that case: re-collect bank details or use another payment method.
`mandate.cancelled`	Sent when a mandate is cancelled (by you, the customer, or the bank). It can no longer be collected against.

Direct Debit collection events

Event type	Description
`collection.scheduled`	Sent when a Direct Debit collection is scheduled against an active mandate. Includes the working-day collection date.
`collection.notice_sent`	Sent when the mandatory advance notice for an upcoming collection has been issued to the customer.
`collection.succeeded`	Sent when a Direct Debit collection is successfully taken. Action required: Provision goods or services to your customer.
`collection.failed`	Sent when a Direct Debit collection fails (e.g. insufficient funds). Contains the Bacs reason code. Action required: RevKeen Recovery may retry or fall back to a stored card per your policy.
`collection.indemnity_claimed`	Sent when a customer raises a Direct Debit indemnity claim (the Bacs chargeback equivalent) and the collection is reversed. Action required: Review the disputed collection.

Settlement events

Event type	Description
`settlement.created`	Sent when collected Direct Debit funds are settled and a payout is created. Gross settlement — the bureau fee is reported separately and never netted from the payout.

Terminal events

Event type	Description
`terminal_payment.requested`	Sent when a card-present payment is dispatched to a terminal device. The payment is in-progress and awaiting terminal response.
`terminal_payment.succeeded`	Sent when a card-present payment is approved by the terminal. Action required: Provide goods or services to the customer.
`terminal_payment.declined`	Sent when a card-present payment is declined by the terminal or card issuer.
`terminal_payment.cancelled`	Sent when a card-present payment is cancelled by the merchant before terminal response.
`terminal_payment.error`	Sent when a card-present payment fails due to timeout, terminal error, or connection loss. Check `failure_reason` field: `timeout`, `terminal_error`, or `connection_lost`.
`terminal_refund.succeeded`	Sent when a card-present refund is approved by the terminal.
`terminal_void.succeeded`	Sent when a card-present void is approved by the terminal. The original transaction has been reversed.

Usage events

Event type	Description
`usage.threshold.reached`	Sent when a customer's usage crosses a configured threshold percentage on a meter. Use this to alert customers approaching or exceeding their included allowance.
`usage.period_finalized`	Sent when a billing period is finalized with final usage quantities. An invoice will be generated shortly after.
`usage.invoice.created`	Sent when finalized usage records are converted into an invoice for a customer subscription.
`usage.event.ingested`	Sent after a usage event is accepted by ingestion. This is a high-volume event and should be subscribed to explicitly with narrow endpoint filters.
`usage.event.rejected`	Sent when a usage event is rejected during ingestion validation. Rejected events are not billable.
`usage.event.excluded`	Sent when a usage event is considered by a meter but excluded by filter conditions. The event is not billable. Delivery is at-least-once; dedupe on `data.dedupeKey`.
`usage.event.quarantined`	Sent when a usage event cannot be matched to a single active meter (unmatched, ambiguous, or terminal processing failure). Delivery is at-least-once; dedupe on `data.dedupeKey`.
`usage.cap.exceeded`	Sent when a hard usage cap refuses the event. The ingest transaction rolled back: nothing was persisted and nothing was charged. Delivery is at-least-once; dedupe on `data.dedupeKey`.

Meter events

Event type	Description
`meter.created`	Sent when a usage meter is created.
`meter.updated`	Sent when a usage meter is updated. The payload includes changed attributes when available.
`meter.archived`	Sent when a usage meter is archived and can no longer be attached to new pricing.
`meter_price.created`	Sent when a meter price is created for a product price.
`meter_price.updated`	Sent when a meter price is updated. The payload includes changed attributes when available.
`meter_price.deactivated`	Sent when a meter price is deactivated and no longer available for new subscriptions.

Event data structure

Each webhook event uses the same envelope:

Field	Description
`id`	Unique event identifier
`type`	Event type (e.g., `invoice.paid`)
`created`	When the event occurred (Unix timestamp)
`livemode`	`true` for live events, `false` for sandbox
`data.object`	Snapshot of the affected object
`data.previous_attributes`	Previous values of changed attributes, on update events