Three-Plane Reconciliation Architecture for Crypto Payments

Single-plane thinking is seductive. Commerce sees an order marked paid. Engineering sees a Confirmed webhook. Finance sees a bank balance move. Each team declares victory. Month end reveals the gaps: entitlements posted without treasury recognition, or treasury moved without matching order references.

Three-plane reconciliation architecture names the planes, defines allowed transitions between them, and builds matchers that produce either alignment or a routed exception—not silent drift.

The three planes

Data flow without collapsing planes

1. Commerce creates payable intent with stable references and expected amount.
2. Provider plane receives server-created payment object and lifecycle transitions.
3. Verified webhooks update provider state through idempotent handlers.
4. Matchers compare commerce ↔ provider on configured keys and tolerances.
5. Finance matchers compare provider ↔ ledger using recognition policy.
6. Exceptions route to taxonomy-owned queues when matchers fail.

Matcher design principles

Matchers are not one SQL join. Each plane pair may use different keys: commerce may key on order_id while provider keys on payment_id with a mapping table. Document tolerances for amount drift, timing windows, and partial payments explicitly.

Async settlement across planes

Provider plane may show Paid while finance plane waits for Confirmed or treasury posting rules. Architecture should represent intermediate states without forcing commerce to pretend finality. Customer communications, fulfillment, and recognition can legitimately diverge when policy says so—as long as the divergence is configured, not accidental.

Controls finance should demand

• Immutable event log for provider plane transitions.
• Separation of duties on manual overrides.
• Exception resolution codes tied to taxonomy.
• Period close checklist referencing all three planes.
• Drift detection when planes diverge beyond thresholds.

Using provider semantics without outsourcing policy

Kobbopay describes explicit lifecycle semantics and signed webhooks as inputs to provider-plane alignment. Your finance plane still owns recognition timing, treasury posting, and exception ownership—bounded to configured rails and merchant environments.