API (webhooks)
Integrations (Braintree, Stripe parity)
UI (indirect – user action triggers event)
Notifications (downstream client usage)
When using Braintree as the payment provider, Pelcro does not emit a webhook event when an end user deletes a saved payment method from their account.
The existing source.canceled webhook:
Is Stripe-specific
Requires manual cancellation on the Stripe side
Is not triggered for Braintree customers
As a result, clients using Braintree cannot reliably detect or respond to payment method removals.
As a Pelcro client using Braintree,
I want to receive a webhook event when a user deletes a saved payment method,
So that I can notify the user in real time, improve security transparency, and maintain feature parity across payment providers.
Emit a webhook event when a user deletes a payment method while using Braintree
New event example: payment_method.deleted or source.deleted
Alternatively: extend an existing normalized event if appropriate
Provider-agnostic behavior
Event should fire consistently for Stripe and Braintree
Abstract provider-specific logic behind Pelcro’s API
Webhook payload should include
customer_id (Pelcro customer)
payment_provider (braintree | stripe)
payment_method_id (Pelcro + provider reference)
subscription_id (nullable, if applicable)
timestamp
Non-sensitive payment method metadata (e.g. type, last4, brand)
Trigger conditions
Fired when deletion is initiated via:
Pelcro UI
Pelcro API
JS-SDK (if applicable)
Should not depend on provider-side manual actions
Clients can send real-time email notifications confirming payment method removal
Parity between Stripe and Braintree integrations
Improved security awareness, auditability, and user trust
Reduced need for provider-specific workarounds
A normalized webhook event exists for payment method deletion
Event fires for Braintree payment method removals
Event behavior is consistent across Stripe and Braintree
Webhook payload is documented in Pelcro API docs
Event is covered by automated tests
No sensitive payment data is exposed
Backward compatibility is preserved for existing webhook consumers
Should this be a new canonical event (payment_method.deleted) or an extension of an existing one (source.deleted)?
Should subscription context be required or optional?
Any edge cases when a payment method is auto-removed (e.g. provider invalidation)?
Please authenticate to join the conversation.
Backlog
Pelcro Product
5 days ago

Deiver Romero
Get notified by email when there are changes.
Backlog
Pelcro Product
5 days ago

Deiver Romero
Get notified by email when there are changes.