PayOpsDocs

Architecture

A payment pipeline built for evidence

PayOps separates chain ingestion, canonical transfer facts, reconciliation decisions, delivery, and operator review so every decision can be reproduced.

01

The system boundary

PayOps begins with an invoice expectation and finalized public chain data. It ends with a persisted decision, replayable evidence, and a signed event for downstream systems. Creating wallets, quoting exchange rates, moving funds, and signing transactions stay outside this boundary.

That narrow scope lets the system optimize for correctness, auditability, and safe failure instead of combining custody and accounting responsibilities in one service.

02

One-way evidence flow

Finalized Solana transactions become canonical transfer records. Reconciliation compares those records with immutable invoice expectations. The result is persisted with its evidence before any webhook is queued.

Every downstream view reads the persisted decision, including checkout status and accounting export. A webhook is a delivery mechanism for that truth, not a second place where payment truth is calculated.

Example
Solana RPC → ingestion → canonical transfer
invoice + transfer → decision + evidence
decision → signed event → your system
03

Deterministic decisions

Parser versions are explicit and ordered. Replaying the same canonical transfer and invoice produces the same outcome, while conflicting representations fail closed.

The recorded representation and rule version travel with the decision evidence, so a future parser or policy change cannot silently rewrite why an earlier invoice was considered paid.

04

Atomic outbox and delivery

The lifecycle event and delivery rows are created in the same database transaction as the authoritative decision. A worker later claims due deliveries with a lease, signs the exact stored payload bytes, and records every attempt.

Retries are bounded by attempt count and time horizon. Manual replay is an explicit one-shot operator action, and stale workers cannot complete a delivery reclaimed by another worker.

05

Operational boundaries

Workers claim durable jobs with leases, delivery attempts are append-only, and stale workers cannot complete a reclaimed job. Review queues expose uncertainty instead of hiding it.

Production controls separate merchant workflows from operational promotion, incident state, and readiness checks. This keeps routine invoice actions from bypassing deployment and safety gates.

06

What to monitor

Monitor ingestion freshness, finalized slot lag, parser failures, unmatched or ambiguous transfers, reconciliation latency, webhook backlog, retry exhaustion, and exception age. Counts alone are not enough; track the oldest item in every durable queue.

A healthy system can answer where a payment is in the pipeline and can reproduce the exact facts behind every terminal decision.