Skip to main content
Ruba opens the next billing period before attempting its renewal payment. A declined charge therefore moves the subscription into past_due rather than ending it immediately. The open order then moves through payment recovery.

​
The retry schedule

The first failure produces three state changes at once:
  • status becomes past_due and past_due_at records the failure time;
  • the customer receives an email that links to payment-method management in the portal; and
  • the order records its next attempt in next_payment_attempt_at.
Retries are measured from that first decline: Any successful attempt restores active. After the fourth retry, or immediately for a terminal decline such as lost_card, recovery stops and the subscription is revoked.

​
Benefit revocation grace period

Payment state and access state can move on different clocks. Configure Settings → Subscriptions → Grace period for benefit revocation to keep benefits available while the subscription remains past_due. Available delays are Immediately, 2 days, 7 days, 14 days, or 21 days. The delay begins at past_due_at; choosing 21 days spans the complete retry schedule. The setting does not change retry timing and does not make the subscription active. It only postpones benefit removal. Your application can still branch on status === "past_due" after receiving subscription.updated.

​
Helping customers recover

Replacing the default payment method in the Customer Portal triggers another payment attempt immediately instead of waiting for the scheduled retry. Your product can support that route by:
  • showing a prominent portal link whenever customer state is past_due;
  • extending the current period through renewal rescheduling;
  • revoking manually when recovery should stop; or
  • issuing a separate refund when money from another order should be returned.