> ## Documentation Index
> Fetch the complete documentation index at: https://docs.myfundingmachine.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Failed-payment reminders

> App-engine email and SMS reminders for existing overdue subscription invoices.

The app engine can send clients a secure link to their existing overdue Stripe
subscription invoice. Email and SMS come from the app's CRM messaging connection,
using the existing reviewed audience and send ledger. This does not enable Stripe
emails, create invoices or subscriptions, charge cards, or change account access.

## When messages send

For a reviewed client, the engine checks the current SaaS-to-CRM-to-Stripe billing
relationship during its regular scheduled pass. A qualifying invoice must be live,
open, have a positive remaining balance and an attempted automatic payment. Its
payment intent must require a payment method or customer authentication. Payments
still processing do not qualify. Canceled subscriptions and paused collection do
not qualify.

The oldest eligible invoice receives an initial email and companion SMS on
successive passes. Each channel can send again after three and seven days from its
first accepted message. There is a minimum three-day gap between reminder rounds
on that channel; delayed runs never send all missed reminders at once. A round
sends at most once per invoice and channel, regardless of payment retries or
duplicate webhook events. An unavailable or opted-out channel does not block the
other channel. Invoice receipts follow the client across onboarding and retention
cards, so changing cards does not restart the reminder schedule.
The engine checks every ten minutes and processes a bounded audience
page, so a large audience can take multiple passes to reach every client.

The client can pay without entering the suspended CRM account. The link pays the
existing invoice; it is not the separate payment-method update link. Account
reactivation remains owned by the CRM's SaaS billing integration. Updating the card
for future charges and confirming restored access remain rollout acceptance checks.

## Stopping and safeguards

The engine reads Stripe again immediately before claiming a message. A paid,
voided, uncollectible or zero-balance invoice no longer qualifies. A changed balance,
contact, subscription or account binding stops the prepared send. Later passes
recompute from current provider facts, so a delayed failure event cannot reopen a
paid invoice. Paying one invoice does not suppress a different outstanding invoice.
As with any external send, payment can settle during the final request window;
already accepted messages cannot be recalled.

CRM Do Not Disturb, missing channel addresses, client holds, engine pauses,
reviewed communication allowances, canceled-billing suppression and uncertain-send
blocks remain in force. Only open cards in the engine's existing eligible stages
are processed. Missing or ambiguous provider evidence blocks sending and appears
in the engine pass report. Billing-read failures block payment recovery messages;
unrelated engine work continues with its existing mapping, consent and ledger
checks. Hosted invoice URLs are rendered only into the outgoing
message, not saved in the app's action ledger or compute previews.

An uncertain provider response requires staff to inspect and reconcile the existing
durable claim before retrying. Provider acceptance is not proof of delivery.

## Activation and rollback

Deploying code alone does not enroll clients in these messages. Using the existing
[engine configuration procedure](https://docs.myfundingmachine.com/staff/onboarding-engine-rollout.md), pause the engine
and review the intended clients' mappings, consent, message history, and ownership
of any existing payment reminders. Add `B1` and `billing-sms` to their communication
allowances, with `send_email` and `send_sms` allowed. Test in `compute` mode first.
Use the approved sender and logo configuration already used by engine emails.

The Stripe credential must read the merchant account, subscriptions, invoices,
invoice payments and expanded payment intents. No additional Stripe write access
is needed. The reader verifies the configured Stripe account and the current CRM
subscription relationship for each client; invoice metadata alone is not a binding.

New-customer enrollment policies and existing audience members have separate saved
allowances. Review both when activating the intended population. Existing overdue
invoices qualify when a client is opted in; no automatic historical backfill is
performed outside the reviewed audience. Approve production activation separately.

To stop reminders, pause the engine or remove these two communication allowances
using its paused configuration procedure. Resume other engine work after review.
Preserve accepted and uncertain receipts so re-enabling does not repeat messages.

Stripe reference: [Hosted invoice page](https://docs.stripe.com/invoicing/hosted-invoice-page).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.