Failed payment follow-up
with a clear next action
A failed collection is an operational event, not a reason to repeatedly charge the same customer. First identify the payment state, then choose the action supported by your gateway and agreed with your customer.
14-day free trial · No credit card required
Unpaid does not always mean declined
| Observed state | First check | Next action |
|---|---|---|
| Invoice unpaid; no provider transaction | Was checkout completed or collection initiated? | Send the customer to the secure invoice payment flow |
| Provider payment pending | Is the method asynchronous or awaiting customer action? | Follow the provider's state; avoid duplicate collection |
| Provider payment failed | What reason and permitted action does the provider return? | Correct configuration or request the appropriate customer action |
| Provider paid; invoice unpaid | Do amount, currency and references match? | Investigate status handling before collecting again |
Retry only when a retry is appropriate
Some failures are temporary; others require a new payment method or customer authentication. Use the provider's current guidance for the specific transaction type rather than imposing one retry schedule on all payment methods.
For example, Stripe's recovery documentation describes retry behaviour and situations where customer intervention is needed. That documentation concerns Stripe's own supported billing flow. It does not prove that the same recovery product is enabled by a BillingServ gateway connection.
Keep the responsibility clear: your BillingServ invoice, the payment provider's transaction and your application's service entitlement are different records. Agree how they should be reconciled and which system may initiate another collection.
Explain what is due and how to resolve it
A reminder should identify the invoice and due date, give a secure route to payment and explain how to contact your team if the invoice is disputed. Avoid including sensitive payment data or unnecessary decline details.
Example reminder structure
“Invoice [reference] for [amount and currency] remains unpaid. Please sign in to your customer portal to review the invoice and available payment options. If you have already paid or need us to check the invoice, contact [support route].”
This is a writing example, not BillingServ email-template syntax. Use the variables available in Email Templates. Review Invoice Settings for reminder timing and suspension-related defaults.
Avoid accidental cancellation or deletion
A failed payment should trigger the policy you agreed with the customer. Do not equate a temporary suspension with account deletion, and do not assume a refunded payment reverses a hosting or domain operation.
For supported service integrations, test suspension and restoration on a disposable resource before enabling them for live accounts. Give staff a way to investigate a disputed invoice or a pending payment without repeatedly changing service state.
When payment succeeds, verify both the invoice and the service outcome. A paid record is not by itself evidence that a provider-side restoration completed. See billing automation for those handoffs.
Track recovered invoices, not just emails sent
- Count invoices entering the unpaid follow-up process.
- Record the reason where reliably available and the action taken.
- Measure confirmed payments against that same invoice cohort.
- Separate pending, cancelled and genuinely unrecovered invoices.
- Track duplicate-charge incidents and customer complaints as quality checks.
Do not treat a reminder click as recovered revenue. Report the observation window and avoid attributing every later payment to automation. Start with invoice payment collection and the setup checks for Stripe, GoCardless or PayPal.
Connect payment follow-up to your invoices
Try BillingServ with your products, customers and payment workflow.
No credit card required.