Architecture overview
How Core's services fit together and how a request flows end-to-end.
Core is composed of four services that work together to hold balances, issue cards, set limits, and move money: a ledger that keeps the books, a card issuing service that creates and authorizes cards, a spending controls service that decides what cards can do, and a payouts service that pushes money out. Every API call passes through the same authentication, idempotency, and routing pipeline before reaching the service that owns the request.
This page describes that pipeline. It is the right starting point if you want to understand what happens between a client request and the eventual webhook your system receives.
Services
| Service | Responsibility |
|---|---|
| Ledger | Double-entry bookkeeping — accounts, transactions, holds, settlements, reconciliation. |
| Cards | Virtual and physical card issuing, activation, freeze, replacement, digital-wallet provisioning. |
| Spending controls | Real-time authorization decisions per card based on limits, categories, and rules. |
| Payouts | Disbursement to internal ledger accounts or external destinations through Banking rails. |
Request lifecycle
Every Core request follows the same five steps:
- Authenticate — the API key in the
Authorizationheader is validated. - Check idempotency — if
X-Idempotency-Keyis set, a cached response is returned for known keys. - Route to the owning service — based on the URL path.
- Execute and respond — the service writes to the ledger, returns the result, and synchronously commits.
- Fire webhooks — async events are dispatched to your registered endpoint.
Multi-tenant model
Each Mono customer is a tenant. All Core resources — ledger accounts, cards, payouts — are tenant-scoped. There is no cross-tenant visibility.
Next steps
- Authentication — credentials and headers.
- Ledger — the foundation Core is built on.
- Integration example — realistic walkthrough.