Architecture Overview
The Payments platform is built on a double-entry ledger system. Every financial operation—charges, transfers, holds, payouts—creates balanced ledger entries where debits equal credits. This isn’t optional; it’s enforced at the database level. The system is organized around seven primitives that compose together to handle any legal payment workflow:| Primitive | Purpose | Key Operations |
|---|---|---|
| Accounts | Where money lives | Create, balance, ledger history |
| Parties | Who’s involved | Clients, vendors, opposing counsel |
| Charges | Money coming in | Create, capture, refund |
| Transfers | Money moving internally | Create, approve, cancel |
| Holds | Earmarked funds | Create, approve, release |
| Payouts | Money going out | Create, process, cancel |
| Ledger | Immutable record | Query entries, transactions |
Account Types
The platform supports four account types, each with specific behaviors:Trust Accounts
Client funds held in trust. These accounts enforce IOLTA/trust accounting rules:- Funds are segregated by client via sub-accounts
- Transfers out require explicit approval
- Complete audit trail for bar compliance
- Real-time balance visibility per matter
Operating Accounts
Firm funds for business operations:- Earned fees transferred from trust
- Operating expenses
- No client fund restrictions
Sub-Accounts
Virtual accounts within a parent trust account:- Track funds by matter or client
- Inherit parent account’s compliance rules
- Roll up to parent balance
- Individual transaction history
Escrow Accounts
Conditional funds with release requirements:- Settlement proceeds
- Disputed amounts
- Funds awaiting court approval
The Ledger System
Every balance change creates ledger entries. The ledger is append-only—entries are never modified or deleted. This provides: Auditability: Every dollar movement is traceable to a specific transaction with timestamp, actor, and context. Accuracy: Balances are derived from ledger entries, not stored separately. The math is always correct because it’s computed, not cached. Compliance: Bar auditors can verify any balance by summing ledger entries. The audit trail is built into the data model.Transaction Structure
Each financial operation creates aledger_transaction with one or more ledger_entries:
- Transaction: Groups related entries (e.g., a transfer creates two entries)
- Entry: Single debit or credit to an account
- Balance: Sum of all entries for an account
- Entry 1: Debit trust account (-$10,000)
- Entry 2: Credit operating account (+$10,000)
- Net effect: Zero (balanced transaction)
Holds and Approvals
Legal payments often require conditional handling. The hold system supports:Hold Types
- Settlement holds: Funds awaiting lien satisfaction
- Retainer holds: Unearned fees that can’t be touched
- Escrow holds: Funds pending court approval
- Compliance holds: Regulatory or audit freezes
Approval Workflows
Holds can require specific approvers before release:- Define required approvers when creating the hold
- System validates approver authorization
- Approval timestamps and actor recorded
- Multi-party approval supported
Balance Impact
Holds reduce available balance without moving funds:balance: Total funds in accountavailable_balance: Balance minus active holds- Transfers validate against available balance
Integration Points
The Payments API integrates with the broader Case.dev platform:Stripe Connect
For actual money movement, the platform integrates with Stripe Connect:- Charges processed through Stripe
- Payouts via Stripe transfers
- Bank account verification
- PCI compliance handled by Stripe
Webhooks
Real-time notifications for payment events:- Charge completed/failed
- Transfer approved
- Hold released
- Payout processed
Workflows
Trigger payment operations from Case.dev Workflows:- Auto-charge on matter creation
- Transfer fees when invoice paid
- Release holds on settlement approval
Security Model
Organization Isolation
All payment data is scoped to organizations. API keys can only access their organization’s accounts, parties, and transactions.Audit Logging
Every API call is logged with:- Actor (API key or user)
- Operation performed
- Affected resources
- Timestamp
Compliance Controls
- Trust account transfers require approval
- Holds enforce approver authorization
- Balance verification before transfers
- Immutable ledger prevents tampering