Best practices
Production recommendations for running Bre-B Participant integrations.
This page collects the operational practices that separate a Bre-B integration that works in sandbox from one that survives production. Bre-B is real-time and 24/7 — there is no overnight batch window where mistakes go unnoticed. The recommendations below are how you stay out of trouble.
If you are deploying Bre-B Participant to production, 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, and runbooks for the most common production failure modes.
Always confirm the resolved name with the payer
A Bre-B payment key is an alias. Resolution returns the holder's name and bank — display this to the payer and require explicit confirmation before dispatching. This is both a fraud-prevention requirement and a regulatory expectation.
Idempotency on every dispatch
Every outgoing-transfer request must include an idempotency key. A network retry without one is a duplicate transfer.
Verify webhook signatures
Every Bre-B webhook is signed with HMAC-SHA256. Verify the signature before trusting the payload — see Webhook signatures.
Treat synchronous responses as "accepted", not "settled"
A 200 from an outgoing-transfer dispatch means Mono accepted the request. The terminal state arrives via webhook. Do not credit or debit anything in your books until you receive the settlement event.
Handle the full state machine
Bre-B outgoing transfers traverse multiple states — pending, sent, accepted, settled, rejected. Map every state in your application. Surface rejections to the user using the error catalog.
Reconcile every day
Run a daily reconciliation against Mono. Bre-B's 24/7 nature means operational issues compound quickly without it.
Rotate the client secret
OAuth tokens expire automatically. Rotate the client secret used to mint them at least every 90 days and immediately after any suspected exposure.
Antipatterns to avoid
- Skipping name confirmation on the resolved target.
- Dispatching without an idempotency key.
- Trusting an unsigned webhook payload.
- Treating dispatch acceptance as settlement.
- Hardcoding webhook URLs without a rotation path.