Destination

Internal domain models that Stripe, PayPal, and future providers implement. A PaymentAttempt that works regardless of backend. A CollectionMethod that abstracts card tokens, billing agreements, and bank debits. The 15 Stripe packages collapse to one provider boundary with adapters.

One place that knows everything about a customer's billing health — across providers, products, and time. The recompute engine already reads all 5 stores. It becomes the kernel of a unified customer state model.

Own the invoicing cycle. Credits applied before charging. Complex proration rules. Usage-based line items. Multi-provider settlement. Invoice presentment that isn't limited to what Stripe's invoice object supports.

The recompute engine evolves from a state reconciler into a rule engine. Segment-based escalation. Revenue-aware retry. Product-specific consequences. Provider-aware recovery. Graduated consequences replace blunt flags.

From blind references to Stripe objects → a surface that understands customer state natively. 6 new capabilities: billing history shows Resolved vs Paid, bad debt payment isolated, NinjaPanel recompute, Grafana business observability, PayPal path corrected, Unified Checkout for account setup. Account health, cross-product billing status, and self-service recovery.

From 126 Stripe API calls → domain-level pricing that delegates to providers. Pay-before-commit for all subscription mutations. Single collection path. Explicit payment outcome matrix — 6 rows, every case handled. The changes_calculator speaks billing nouns. Entitlements sync simplified from Sync+Unsync to Sync only.

From 27 blind handlers responding to individual Stripe events → one recompute function that reads all 5 stores, computes correct state, and applies the delta. 5 event types replace 196. Temporal orchestration. Events are triggers, not the logic. ~5 billing-webhooks processors removed.

Recompute engine provides the policy layer; PDE provides clean payment states to act on. Without PDE, the input signal is noisy. With both, dunning policy can vary by customer segment, revenue tier, and product type.

Recompute detects drift; entitlements mapping provides a single function to re-provision. Without mapping, restoration requires per-product logic. With both, accounts self-heal when payment succeeds.

Pay-before-commit enables trying a second payment method on failure; Stripe consolidation makes it safe. Without consolidation, adding a fallback touches 15 packages. With both, Stripe fails → offer PayPal automatically.

Pay-before-commit enables billing at usage thresholds, not calendar intervals. Without PDE, a threshold hit would commit before payment. Requires invoice sovereignty, PDE ordering, and the policy engine — all three pillars converge.

Own the invoice → apply credits before charging. Customer credit balances, promotional credits, goodwill adjustments, overpayment application. Not possible when Stripe owns the invoice lifecycle.

PayPal failures get PayPal-appropriate recovery paths. Card failures get card-appropriate retry schedules. The policy engine distinguishes provider semantics instead of treating all failures identically.

Stripe charge fails → offer PayPal. PayPal lapses → prompt for card. Requires provider-agnostic payment attempts and the consolidation boundary.

Move customers between providers without domain model changes. The provider is an implementation detail behind the boundary. Adding a new payment provider means writing one adapter.

Own the invoice → own proration math. Mid-cycle upgrades, downgrades, plan stacking, usage overages — all computed in domain logic, not delegated to Stripe's proration engine.

Bill at usage thresholds, not calendar intervals. All three pillars converge: invoice sovereignty for flexible billing cycles, PDE for safe commitment, and the policy engine for threshold rules.