For crowdfunding
Crowdfunding platforms: when a campaign fails, the transfers are already gone
Crowdfunding contains the highest-velocity leak scenario in any vertical: the failed campaign. Two thousand backers, forty-five dollars each, refunded within hours because the platform honours its promise — and every single refund without reverse_transfer strands a micro-transfer simultaneously. Nothing about the moment is calm: support is drowning, socials are hostile, and the one thing requiring mathematical precision is executing under maximum stress.
Anatomy of the failed campaign
Deadline passes unfunded; platform refunds N backers × M dollars immediately. Each backer’s pledge created a destination charge and an immediate transfer minus platform fee. Refunds fire en masse; reversals require per-backer instruction. Modelled: 2,000 backers × $45 at a 5% fee strands $4,500 across as many accounts if flags miss — in one afternoon.
- Refunded to backers
- $90,000
- Transferred to campaign
- $85,500
- Stranded if flags omitted
- $85,500
- Platform fee retained improperly
- $4,500
Batch idempotency under load
Mass execution is where idempotency discipline earns its keep: queue workers retry, webhooks redeliver, and one missing key doubles a backer’s correction into a complaint. Keys scoped per backer-refund pair, live-state checks before acting, throughput throttled to Stripe’s comfortable range — the difference between a clean unwind and a support catastrophe.
Flexible funding: the permanent partial engine
Keep-it-all campaigns generate ordinary partial-refund traffic forever — reward downgrades, address-change recharges, backer remorse. Lower drama than failures, higher lifetime total. The same flag discipline applies; the cadence just stops being newsworthy.
Cross-border backers, FX layers
Multi-currency campaigns convert twice per stranded transfer — outbound at pledge-correction, inbound at refund. Face-value refund policies need explicit FX-delta treatment recorded separately, or month-end inherits two thousand tiny mysteries.
What FeeGuard does about it
Historical scans replay failed-campaign periods and report exactly what stranded, per backer and in aggregate; bulk workflows then execute corrections idempotently. For platforms running frequent campaigns, monitoring catches the flexible-funding drip continuously while staying ready for the next dramatic unwind.
Common questions
Can we reverse safely in bulk?
Yes — keys per backer-refund pair plus live-state checks make mass correction safe. Unkeyed loops are what turn unwinds into incidents.
Reverse before telling creators?
Creators get notice per template; backers are unaffected financially either way. Sequence communication to the parties who can act.