Version
WEBHOOK

project.payment_method.deleted

A payment gateway is removed from a project.

When this fires

A creator removes a payment method from the project:

  • Dashboard: the remove action on the project's Payment Methods page.
  • Bot: the main bot's payment-method menu, "disconnect" on a connected gateway.
  • REST: DELETE /v1/projects/{project}/payment-methods/{method}.
  • MCP: the delete_payment_method tool.

It does not fire when:

  • A gateway is switched off. That is project.payment_method.updated with changes.active, and the row stays.
  • A Stripe method is disconnected from its Connect account. The row is kept (unlinked and inactive) and that flow raises no event at all.
  • The row was already gone. Deleting twice writes nothing the second time and emits nothing.

The row is soft-deleted, not destroyed. Subscriptions sold through the gateway keep pointing at it for refunds and history, and if the creator sets the same gateway up again in the same mode, the same row is revived. Expect this id to come back to life, and remember there is no project.payment_method.created event to tell you when it does.

Caveats

  • active: true here means the creator removed a gateway that was live for new purchases. If you mirror the project's checkout options anywhere, this is the event to react to; a deactivation would have arrived as updated first.
  • Existing subscriptions are untouched. Their renewals, refunds and history keep referencing this gateway even though the row no longer appears in the project's payment methods list.
  • linked is not in the snapshot, and nothing about the gateway's credentials or connected account is ever sent.

Related events

  • project.payment_method.updated: every change to the gateway before this one, including switching it off.
  • project.deleted: a project going away takes its gateways with it without a per-gateway event.

Ability to subscribe

A token needs this to subscribe an endpoint to the event.

Header Parameters

SB-Signature*string

t=<unix seconds>,v1=<hex>: the HMAC-SHA256 of "<t>.<raw body>" under the endpoint's secret. Verify it before acting, and refuse a t more than 300 seconds from now. During a secret rotation a v0= signature under the previous secret may precede v1=.

SB-Event-Id*string

The event's ULID, bare. The envelope's id is the same ULID prefixed evt_, so strip the prefix before comparing. Deduplicate on it: a retry carries the same id.

SB-Event-Name*string

The event name, the same as the envelope's type.

Content-Type*string

Always application/json.

User-Agent*string

Always Subscriby-Webhooks/1.0.

Payload

JSONWhat Subscriby posts to your endpoint

The signed JSON envelope posted to your endpoint.

The envelope every event is delivered in.

Responses

2XXAny success status

Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.

defaultAny other status

Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.

How is this guide?

Last updated on