Remove a payment provider
Removes a provider connection without deleting its history. The connection stays retrievable with status removed, so payments, reconciliations and disputes that name it still resolve, and it takes no new payments. It returns 409 invalid_state while this is the only live provider, while it has open disputes (payments at this provider that a chargeback still holds in disputed), while it is the account default, while any routing rule uses it, or while any customer’s own payment_provider override names it. For the default the message is “Choose another default provider first”: make another provider the default with PATCH, then remove this one. Runledger never hands the default over by itself. When routing rules or customer overrides use the provider, the error lists them in blocked_by, each as an {object, id} of routing_rule or customer. An Admin changes or deletes those rules first (PATCH or DELETE /v1/routing_rules/{id}) and moves those customers to another provider (PATCH /v1/customers/{id} with a new payment_provider, or null to clear the override), then removes the provider. Connect another provider, or wait for the disputes to close, and try again.
Who can remove one. Only an Admin can remove a live provider. An agent key, and a Collaborator, is refused with 403 and permission_denied. In the sandbox a key with providers:connect can remove one.
Saved payment methods. Payment methods that customers saved at the removed provider are kept on record and marked unusable. They are not charged, and the customer shows as needing a new payment method (payment_method_status on the customer is unusable). Removal doesn’t wait for them, so it succeeds while customers still hold methods at the provider. Needs providers:connect.
Authentication
A secret key (rl_sk_test_..., rl_sk_live_...) or a restricted key with limited scopes (rl_rk_test_..., rl_rk_live_...). A restricted key can carry agent: true and an expires_at, and is what a coding agent should hold. Keys end in a checksum so secret scanners can recognize them. People create, roll and revoke keys in the dashboard; GET /v1/api_keys lists them, masked.
Path parameters
The payment provider ID (pp_...).
Headers
Send true to see what the write would do without doing it. The response is the normal body with dry_run: true, changes (path, before, after), warnings and errors added, and nothing is stored. Validation runs as it would for a real write. The request is kept in request logs, tagged Dry run. When the same change is then made for real, its audit event has dry_run_preceded: true.