Skip to main content
Legal payments are different. Trust accounts have rules. Settlements require holds. Every dollar needs an audit trail. Generic payment platforms weren’t built for this—so we built one that was. Contact Sales →

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:
PrimitivePurposeKey Operations
AccountsWhere money livesCreate, balance, ledger history
PartiesWho’s involvedClients, vendors, opposing counsel
ChargesMoney coming inCreate, capture, refund
TransfersMoney moving internallyCreate, approve, cancel
HoldsEarmarked fundsCreate, approve, release
PayoutsMoney going outCreate, process, cancel
LedgerImmutable recordQuery 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 a ledger_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
For a $10,000 transfer from trust to operating:
  • 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 account
  • available_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

Getting Started

The Payments platform is currently available to select partners. If you’re building legal technology that handles money, we’d love to talk. Contact Sales →