---
title: "A payment gateway is removed from a project."
method: POST
path: "project.payment_method.deleted"
tags: ["project.* events"]
---

# A payment gateway is removed from a project.

`POST project.payment_method.deleted` (webhook)

### 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.

## Headers

- `SB-Signature` string, required
- `SB-Event-Id` string, required
- `SB-Event-Name` string, required
- `Content-Type` string, required
- `User-Agent` string, required

## Payload

- object: The envelope every event is delivered in.
  - `id` string, required: A ULID unique to the event, prefixed `evt_`. Every retry carries the same id, so it is the key to deduplicate on.
  - `type` 'project.payment_method.deleted', required: The event name, always `project.payment_method.deleted` here.
  - `created_at` string, date-time, required: When the event was emitted, server time, ISO 8601.
  - `api_version` string, required: The contract version of the payload shape, `2026-05-01` today. A breaking change to a shape ships under a new version.
  - `project_id` string, uuid, nullable, required: The project the event belongs to; null for team-scoped and billing events.
  - `data` object, required: The event-specific payload. Keys that do not apply to a given emission are omitted rather than sent as null, so check for presence.
    - `payment_method` object, required: Snapshot taken immediately before the delete: `id`, `provider`, `mode`, `active` only. Never `config`.
      - `id` string, uuid, required: Payment method identifier. No longer resolvable over the API once this event has fired.
      - `provider` string, required: A gateway slug (`stripe`, `paypal`, `skrill`, `coinpayments`, `paystack`, `razorpay`, `ceypay`, `accesscode`) or a `connector:provider` key for a currency a connector brings (`telegram:stars`); `platformcurrency` is the legacy alias earlier native rows carried.
      - `mode` 'live' | 'test', required: Which of the gateway's environments the removed row held.
      - `active` boolean, required: Whether the gateway was still being offered to buyers at the moment it was removed.

## Acknowledgement `2XX`

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

## Other responses

- `default`: 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.

---

[API](https://skmtc.dev/memberpass/apis/subscriby-rest-api.md) · [All operations](https://skmtc.dev/memberpass/apis/subscriby-rest-api/llms.txt) · [OpenAPI document](https://skmtc.dev/memberpass/apis/subscriby-rest-api/revisions/59c4df91d764?raw)