Use cases · Payments and fintech
Money moves exactly as the rules say.
In a payment flow, a two-character refactor can pay out money that was never collected. Bracel executes the rules that guard every amount on every pull request, before merge.
- POST /payments · 100.00201
- GET refunded total0.00
- POST refund · 50.00 (control)201
- GET refunded total50.00
- POST refund · 50.01201
What breaks quietly
The bugs a review reads past.
Each of these looks reasonable in a diff. Each one only shows itself when the code runs.
- 01
Over-refunds
A guard that compares each refund with the capture, and forgets what was already refunded.
- 02
Partial state
A rejected operation that still moves a total, because a write happened before the check.
- 03
Open admin routes
A refund or payout endpoint that ships without its authentication middleware.
Rules to protect
Start with one. Add the next when it ships.
Rules are approved by your team and read from your base commit, so a pull request cannot change the rules that judge it.
-
Refunds never exceed the captured amount
Available · refund.amount-cap@1
-
Admin payment routes refuse requests without credentials
Available · http.auth-required@1
-
Retrying the same refund cannot create a duplicate
Planned · not yet a template
-
Rejected refund attempts are auditable
Planned · not yet a template
How it runs
Inside your CI. Evidence on the pull request.
- 01
A pull request touches a protected route.
- 02
Your GitHub Actions runner builds and starts the application in isolation, without network access.
- 03
Bracel executes the approved rules against it.
- 04
The check states the verdict, what was expected and observed, and why.