Payment dashboards need search, filters, status views, connector labels, and recent activity. The payment core needs strong correctness for authorization, capture, refund, idempotency, provider references, and webhooks.
Those are different jobs.
MasonXPay separates them with Postgres-backed read models. The core payment tables remain authoritative. The dashboard reads from payment_read_models when projection workers are enabled.
The Authoritative Path
Money-moving decisions stay on the core payment path:
- create payment
- confirm payment
- capture
- cancel
- refund
- webhook reconciliation
- idempotency checks
Those flows use the owning Postgres payment shard and normal state-transition services. Redis, Kafka, and projections do not decide financial truth.
The Dashboard Path
The dashboard needs a different shape of data. A merchant list page may need:
- payment ID search
- status filters
- TEST/LIVE mode filters
- provider and connector label filters
- created date filters
- refund summary fields
- human-readable search text
Instead of fanning out across payment shards, MasonXPay projects committed lifecycle events into payment_read_models. The dashboard can then query a tenant-scoped read table designed for list and search UX.
Why Not Start With OpenSearch?
OpenSearch can be useful later for large support search workloads, but it is not necessary as the first read-model layer. Postgres read models are easier to run locally, simpler to test, and good enough for the current dashboard search surface.
The current rule is:
Postgres read models first.
OpenSearch only if dashboard/support search outgrows Postgres.
Never use search indexes for payment correctness.
That keeps operations approachable while preserving a clean scale-out path.
Backfill and Repair
MasonXPay includes projection backfill support so read models can be rebuilt from existing payment/refund rows. Projection failure records and metrics make broken events visible instead of silently hiding dashboard data.
That means operators can treat read models as repairable operational views, not as financial records.
What Merchants Get
The merchant gets a fast dashboard:
- payment lists
- search by ID and text
- status/provider/date filters
- connector labels
- refund summary fields
The payment core keeps the stronger guarantee: the source of truth remains the payment tables and shards.