Reference · built on requestOperator by FibricFinance & billing

Payment Retry

Failed card renewals watched per account, with a retry schedule, a customer notice, or a service hold proposed for each one.

Request accessPricing ↗

About

A renewal fails and the billing system starts its own retry clock. This operator watches that clock and everything around it. It reads invoice.payment_failed events and the attempt_count and next_payment_attempt fields from Stripe, dunning_status and dunning_attempts on Chargebee invoices, and Recurly's dunning events. It reads the decline code, because a hard decline will not clear on retry. It reads the account's open tickets, so a customer who has already written in is not sent a form letter.

For each account it proposes one path: let the retries run, send a notice asking for a new card, or hold service and say so. You approve the path. It then leaves a record of what was sent, when, and what the billing system did next.

This is a reference listing. It documents what Fibric would read from Payment Retry and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Stripe invoice.payment_failed events with attempt_count and next_payment_attempt, and the subscription status moving through past_due, unpaid, or canceled
  • Stripe decline codes on the failed attempt, separating retryable failures from hard declines such as lost_card or stolen_card
  • Chargebee invoices in payment_due or not_paid with dunning_status of in_progress, exhausted, stopped, or success, and their dunning_attempts
  • Recurly new_dunning_event, failed_payment, and successful_payment webhooks, and the invoice's past due state
  • Open Zendesk tickets and Intercom conversations for the same customer, so a billing notice is not sent into an active complaint
  • Delivery and bounce events on notices sent through Twilio SendGrid or Twilio SMS, which decide whether a second notice is proposed

Proposed actions

  • Target capability: propose leaving Stripe's retry schedule to run where the decline is retryable and a payment method is on file
  • Target capability: propose an email through SendGrid or an SMS through Twilio asking for a new card, with the invoice link and the pause date
  • Target capability: propose a service hold on a subscription once retries are exhausted, with the Chargebee or Stripe status it will move to
  • Target capability: propose stopping dunning on a Chargebee invoice where a person has agreed a different arrangement on a ticket
  • Target capability: propose a note on the customer's Zendesk ticket or Intercom conversation recording the billing state and the notice sent

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Ask for a new card only when a retry cannot work

    When a Stripe invoice.payment_failed event carries a hard decline code, a SendGrid email asking for a new payment method is proposed on the first failure instead of waiting for the retry window.

    With Stripe, Twilio SendGrid

  • Hold service after Chargebee gives up

    When a Chargebee invoice's dunning_status becomes exhausted, a service hold is proposed with the customer's last notice date shown. Approve it and the hold is applied once.

    With Chargebee

  • Do not dun a customer mid-complaint

    Before any notice, open Zendesk tickets for the customer are checked. If one exists, the proposal becomes a note on that ticket for the agent instead of an email.

    With Zendesk, Stripe

  • Text where email bounced

    A Recurly failed_payment event whose email notice bounced is followed by a proposed Twilio SMS with the same invoice link, sent only on approval.

    With Recurly, Twilio

Requirements

  • A billing connector that emits payment failure events and exposes dunning state: Stripe, Chargebee, or Recurly
  • A messaging connector for the notice: Twilio SendGrid for email, Twilio for SMS, or both
  • A support connector to check for open conversations before a notice goes out: Zendesk or Intercom
  • Your rules: how many failed attempts before a notice, how many days before a hold, and which plans are never held
  • A customer id shared between billing and support, or an email address on both, for the match
Authentication
It has no billing login of its own. It reads events and writes notices through the billing, support, and messaging connectors you attach, each with the scopes you grant.

Limits

  • It schedules nothing inside the billing system. Stripe, Chargebee, and Recurly keep their own retry rules; it decides what to say and when to hold.
  • Stripe does not retry on a hard decline code without a new payment method. For those accounts it proposes a notice, never a retry.
  • A notice is proposed once per invoice. A bounce or a failed SMS brings back one new proposal, with the other channel offered.
  • It sends no message and holds no service on its own. Each account waits for your approval.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Payment Retry ↗

Questions and answers

What am I approving for each account?
One path: run retries, send a notice, or hold service. The proposal shows the invoice, the failed attempts so far, the decline code, the next scheduled attempt, any open ticket, and the exact message text. Approve, edit the text, or pick another path.
What record does it leave?
Per invoice: the failure events it saw, the path chosen, who approved, the message id from SendGrid or Twilio, its delivery status, and the billing status afterwards. A hold records the status it moved to and how to lift it.
Can it charge a card or cancel a subscription on its own?
No. It never initiates a charge. Retries stay with the billing system's own schedule. A hold or a stop-dunning change happens only after a person approves it, and it is applied once.
Ask about Payment Retry

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy