What this is: a demonstration workflow I built for GuraForge to show how I make automations fail safely. All data is fictional and the payment provider, ledger and alerts are local stand-ins. It is not client work.
The problem it targets: the most common automation failures are silent. A webhook arrives twice and creates two records, an API is down for a minute and the run just stops, or something fails and nobody finds out.
What the workflow does
Takes a payment webhook and writes one booking to the ledger, plus a receipt draft (not sent).
Uses the payment's event ID as an idempotency key, so a repeated webhook does not create a second booking.
Retries a failing ledger call up to 3 times, 1 second apart.
A separate error workflow sends one alert when the retries run out.
How it was tested (real n8n 2.46.6 editor, recorded run):
Duplicate webhook delivered twice → 1 booking.
Ledger temporarily down (503, 503, then 201) → recovered on the third try, no duplicate.
Ledger down for good → 1 alert recording 2 failures.
End state: 3 unique bookings, 3 unsent receipt drafts.
What a client gets from me on a similar job: the workflow files, a short test note showing the normal, duplicate and failure cases I ran, setup steps for reconnecting credentials, and the known limits.
Importable workflow and an earlier run receipt: https://guraforge.com/connect/
0 likes · 0 views · Nov 14, 2026
A recorded n8n sandbox test: payment messages into a ledger, duplicate handling, bounded retries and one failure alert. Practice data, not client work.
