Best practices
Production recommendations for running Banking integrations.
This page collects the operational practices that separate a Banking integration that works in sandbox from one that survives production. They are how you avoid duplicate transfers, recover gracefully when a rail times out, and reconcile the books at the end of each day.
If you are deploying Banking to handle real money, treat this page as a launch checklist and as a reference during incidents.
This page is a best-practices scaffold. The full version will include concrete examples, anti-patterns to avoid, and runbooks for the most common production failure modes.
Idempotency on every transfer
Every transfer-creation request must include an idempotency key. Without it, a network timeout will silently double-send.
Treat synchronous responses as "accepted", not "settled"
A 200 from a bank-transfer creation means Mono accepted the request — not that the rail confirmed credit. Wait for the webhook before marking the operation as settled in your books.
Plan for fallbacks
Mono Turbo can fall back to ACH automatically. Your reconciliation must handle a transfer requested as Mono Turbo that ultimately settled as ACH — the rail-level fees and timing differ. Read the rail field on the confirmation webhook.
Reconcile daily
Run a daily reconciliation that compares your view of every transfer (and its terminal state) against Mono's. Surface drift the day it appears, not the week after.
Verify webhook signatures
Every Banking webhook is signed. Verify the signature before trusting the payload — see the webhook documentation.
Rotate API keys
Rotate API keys at least every 90 days and immediately after any suspected exposure. Keys do not expire on their own.
Antipatterns to avoid
- Sending a fresh idempotency key on every retry.
- Treating PSE collection-link creation as confirmation that the customer paid.
- Hardcoding rail choices that block fallback.
- Logging API keys, signed payloads, or PII.