Example processfintech

Failed payment recovery automation software

An example of failed payment recovery as a governed process: agents do the 11 steps, and a person signs 2 gates before anything irreversible happens. Download it, import it into your workspace, and adapt it to your systems.

Download example · JSONImport into Minctrl →

minctrl.process/v1 · hash 008a03f46d2d…e3dd

The graph11 agent steps2 human gatessigns: Billing & dunning policy owner (RevOps / Finance)

Failed-payment smart-dunning autopilot

Soft declines and expired cards silently leak millions of payments a year, and most teams paper over it with a fixed retry cron and generic dunning emails that misfire on timing and channel. Every fee waiver, credit, or delinquent-account suspension is a manual, inconsistent judgment call buried in support queues, so recoverable revenue churns out. Agents classify each failure, schedule issuer-aware retries, refresh expired cards, and run multi-channel dunning straight-through, recovering routine soft declines without a human touch. Only genuine judgment calls — a fee/credit concession or suspending/cancelling a delinquent account — reach the billing owner, who signs the irreversible action.

The governed flow · branches, parallel work & a human on the irreversible step
active Reg E error dispute on fileno active disputeinvestigation complete; error determination madenon-EU customer or SCA exemption validEU customer; SCA required but failed and no exemptionexpired cardsoft decline / recoverablehard decline / unrecoverableretry spacing or attempt-limit exceededcease-communication notice on filepayment recoveredrecoverable with a concessionwindow exhausted / unrecoverableopen Reg E dispute detected at gate — halt concession
Start
agent · low risk
Ingest the failed-payment event and pull subscription, invoice, decline code, and prior dunning history
agent · low risk
Classify the failure (soft decline vs expired card vs hard decline) and score recovery likelihood against the recovery policy; map decline code to ISO 20022, Visa, and Mastercard response codes to distinguish transient issuer failures from card errors and hard stops
agent · low risk
Query the dispute ledger: has the customer filed an error claim or dispute for this recurring payment within 60 days of statement date (Reg E § 1005.11(a) window)? If yes, freeze all retry and dunning attempts and route to investigation; if no active dispute, proceed to SCA/geo check.
agent · medium risk
Execute Reg E error investigation: acknowledge dispute within 1–2 business days, determine within 10 business days whether an error occurred, issue provisional credit to the customer's account if investigation extends beyond day 10, complete final determination by day 45 (only if provisional credit granted), and document findings. Freeze all recovery retries and dunning during the investigation window.
agent · low risk
For EU customers: validate SCA exemption status per PSD2 RTS § 13. If the initial subscription charge failed SCA validation and no exemption applies (cardholder-initiated transaction, trusted merchant, or low-risk threshold <€50), route to suspensionGate to pause recovery until customer completes a new SCA challenge. If exemption is valid or customer is non-EU, proceed to failure-type classification.
decision
Failure type & recoverability?
agent · medium risk
Expired card: trigger account-updater to refresh stored credentials before retrying
parallel · fan-out / join
Run smart retries and multi-channel dunning concurrently
agent · medium risk
Before scheduling each retry, validate: (1) minimum 48–72 hours have elapsed since the prior attempt, and (2) total retry count remains below 7 per Visa/Mastercard network rules (Visa § 5.4.6; Mastercard Switch Rules § 10.1) to avoid chargeback exposure under codes 4855/4863. If either limit is exceeded, block retry and route to suspensionGate. Otherwise, schedule issuer- and time-zone-aware smart retries and refresh expired-card credentials via account-updater.
agent · medium risk
Before any outreach, validate the customer has not submitted a written cease-communication notice per FDCPA § 1692c(c). If a cease notice is on file, block all communications immediately and route to suspensionGate. Otherwise, run compliant multi-channel dunning (email/SMS/in-app) with self-serve card-update links, respecting the 7-call/7-day frequency cap, the 8 AM–9 PM consumer-local-time window (§ 1692d(a)), and comms and consent limits from the consent ledger.
decision
Recovery outcome after the retry/dunning window?
gate · human sign-off
The billing owner signs any fee waiver, refund, or credit concession proposed to win back the payment. Before signing, confirm no open Reg E error dispute is active for this transaction — if a dispute is active, reject the concession and route to disputeInvestigation.signs: Billing & dunning policy owner (RevOps / Finance)
agent · high riskirreversible
Execute the approved concession (waive fee / issue credit or refund), post it to the ledger, and re-attempt the discounted invoice
gate · human sign-off
The billing owner signs the suspension or cancellation of the delinquent account once the recovery window is exhausted (or all retry/dunning attempts are confirmed complete), a hard decline is confirmed, an SCA challenge cannot be completed, or a cease-communication notice blocks further outreachsigns: Billing & dunning policy owner (RevOps / Finance)
agent · high riskirreversible
Execute the approved service suspension or subscription cancellation and notify the customer
agent · low risk
Track recovered-revenue, retry-success, and involuntary-churn metrics and feed outcomes back into retry/dunning timing. Assign a data-retention-expiry date (max 6 years per GDPR § 5(1)(e)) to all failed-payment records and dunning logs, and trigger automatic deletion at expiry.
Done
low riskmedium riskhigh riskbranch / reworkgate · human sign-off
Use this example
01

Download the file

A minctrl.process/v1 document: the graph and the hash of the process it becomes.

02

Import it in Processes

Import into Minctrl opens this example in your workspace; one click stores it as your first version. Import JSON does the same with the file, and a file changed after download is refused.

03

Connect your systems

Every connector starts in shadow: steps run, nothing leaves Minctrl until you configure a connector and switch it live.

04

Adapt it

Change signers, time limits and steps on the canvas. Each save is a new version; a running case stays on the version it started with.

Questions
How do I automate failed payment recovery with Minctrl?

Start from this example. Import the file in Processes, connect your own systems, and adapt the steps on the canvas. Agents run the reversible steps; every irreversible step waits at a gate for the role you choose. The example has 11 steps and 2 gates; you can change any of them.

Is failed payment recovery in Minctrl auditable?

Every run start, signature and change to the process is written to a hash-chained audit log your auditor can verify and export. A run is pinned to the exact graph it started on.

Does the AI decide everything?

No. Minctrl will not make a process runnable while an irreversible step can be reached without a human gate, and one person cannot sign two gates of the same run.

More examples