Product boundary
What PPOps owns, what your application owns and what it cannot do.
This manual targets 0.1.0-beta.3. Read the source and availability policy before installing. Historical reports retain their original scope.
PPOps is a self-hosted merchant service for private native USDC on Arbitrum. It creates signed payment requests, observes a receiver through view-only access and emits payment events after reconciling private settlements.
The current primitive is PPOps PayIn: a signed payment request, payer execution, view-only settlement detection, privacy/finality validation, matching and deterministic merchant notification. An operations layer for private money movement is the product direction; incoming payments are the implemented scope.
Responsibilities
| Component | Owns |
|---|---|
| Merchant application | Products, prices, orders, fulfillment and customer policy |
| PPOps daemon | Intent identity, signed requests, viewing/scanning, payment projection and event outbox |
| Separate payer wallet | Private liquidity, descriptor verification, proof generation, fees, submission and recovery |
| External infrastructure | RAILGUN, Arbitrum finality, operator-selected RPC and PPOI availability |
One daemon instance serves one receiver, network and token. The merchant’s spending wallet can remain on a separate device; its viewing capability alone is imported into PPOps. Invoice/customer identifiers remain in the merchant’s local data, outside the public request and encrypted opaque payment reference.
The service uses a familiar payment-intent lifecycle. A backend creates a request and waits for an authenticated event before delivering an order. Self-hosting leaves operation and data with the merchant; it also leaves the merchant responsible for backups and dependency availability.
Implemented in the current source
- View-only merchant daemon with authenticated REST API.
- Signed EIP-712 payment descriptor and public request.
- Finality, PPOI and reference-aware reconciliation.
- Transactional outbox with authenticated, retried webhook delivery.
- Checkout with periodic status updates, expiry and payer guidance.
- Isolated demo and runnable merchant integration example.
- Optional TypeScript HTTP and webhook helpers.
- Configuration diagnostics, runtime status and offline backup/restore.
- Separate reference payer with controlled historical Gate A/B evidence.
- Beta.3 PayIn UX: local browser signature verification, request-link QR, payment-language progress and a non-submitting payer readiness command.
The demo, diagnostics, HTTP helpers and refreshed checkout are additions in beta.2. The published beta.1 tag has the earlier product surface.
Not included
PPOps does not provide spending custody, wallet funding, refunds, swaps, fiat conversion, commerce plugins or additional rails. QR encoding of the signed-request URL is implemented in the working tree; interoperability with consumer-wallet QR scanners and deep links remains unvalidated. The checkout is a request/status surface, not a wallet or signer.
Payout, starting potentially with refunds, remains roadmap only. There is no payout API. Future signing and approval must remain external to the merchant’s view-only daemon.
The reference payer shares the repository for reproducibility, but has its own dependencies, database, process and secrets. Merchant code must never import that spending runtime. Documentation packaged with the merchant may describe the payer; that does not include its executable code.
Verification and operational scope
Mainnet verification reports document the exact behavior tested on Arbitrum One. Deployments should validate environmental prerequisites and RPC quorum health before processing live payments.
Use Merchant integration for application code, Payment states for exact semantics, and the documentation index for architecture and dated evidence.