A ClearBox deployment is composed of a frontend, a backend, and a set of orchestrated third-party services. Understanding the boundaries between them clarifies which system owns each step of a flow.Documentation Index
Fetch the complete documentation index at: https://docs.clear-box.io/llms.txt
Use this file to discover all available pages before exploring further.
Components
| Component | Responsibility |
|---|---|
| ClearBox Frontend | The user-facing app (web or iOS). Hosts the signup form, the embedded Quiltt connector, and the native Apple Wallet prompt. |
| ClearBox Backend | Your orchestration layer. Holds the source of truth for users, wallets, and cards, and coordinates calls to partner APIs. |
| Quiltt | Open-banking connectivity. Links the user’s bank and returns account metadata and tokens. |
| Persona (ClearCheck) | Identity verification. Runs KYC/AML inquiries; surfaced to users through Crossmint Auth. |
| Crossmint | Non-custodial smart-contract wallet infrastructure, key management, and card issuance. |
| ClearBox Mirror Ledger | The settlement engine. Authorizes transactions in real time and reconciles on-chain in the background. |
| Card networks & POS | Visa/Mastercard rails and the merchant point-of-sale terminals where transactions originate. |
How the layers interact
The frontend never calls partner APIs directly with secret credentials. Instead, it triggers actions on the ClearBox backend, which mints short-lived scoped tokens for client-side widgets (like the Quiltt connector) and makes all privileged calls server-side. This keeps three things true:- Secret keys for Quiltt, Persona, and Crossmint never reach the client.
- The ClearBox backend remains the single source of truth, mapping every external object (bank token, identity, wallet address, card ID) back to a user record.
- Compliance checks run server-side, where they can’t be bypassed.