A multi-chain crypto payment gateway that unifies payment state across networks. It combines a payment orchestrator, chain-specific monitoring, signed webhooks, custody flows, settlement queues, and admin and merchant interfaces.
01 / Project scope
Different networks. One payment lifecycle.
The gateway connects payment products, chain monitoring, merchant notifications and the handoff to treasury. The important boundary is not just between chains: payment confirmation, webhook delivery and downstream settlement describe different outcomes.
This case covers solo architecture, implementation and operator tooling for the CPG domain within a shared Beatoz dev pilot. It does not claim sole ownership of the issuer, treasury or compliance services.
- Owned scope
- CPG API, workers and operator interfaces
- Integration boundary
- Issuer, treasury and adjacent pilot services
- Basis of this account
- Published project description, not a source-code audit
02 / System architecture
Follow the work, not the animation.
Merchant / payment products
Create the payment context
Merchant and store configuration, an integrated payment session, widget configuration or a custom payment provide the API-driven entry point.
Strategy / Adapter
Select the network adapter
The orchestrator selects the network-specific adapter. QR data and payment status are managed centrally rather than separately in each payment surface.
Monitoring workers
Observe the chain
Chain-specific workers detect transfers and update payment state. Direct wallet transfers can also be detected by a conditional, throttled scan.
Another entry: a direct wallet transfer is observed on-chain; it need not originate in a payment API call.
Separate follow-up responsibilities — not one shared “done” state
HMAC-signed webhook
Notify the merchant
Delivery is signed, retried and persisted. A notification delivery outcome is not the same thing as an on-chain payment outcome.
Settlement queue → Treasury
Hand off settlement work
Queue-based processing and treasury handoff points connect the domains. Enqueuing or handing off work does not by itself demonstrate downstream settlement completion.
Three boundaries worth explaining.
Shared orchestration, network-specific adapters
- Documented implementation
- The catalog records a Strategy/Adapter orchestrator with separate chain workers.
- Why the boundary matters
- A common entry point can share payment intent and status while isolating network-specific behavior.
- What this does not establish
- This separation still requires explicit adapter contracts and tests; the original adapter test suite is not published here.
Payment state is not webhook delivery state
- Documented implementation
- HMAC signing, delivery retry and persistence are recorded in the project description.
- Why the boundary matters
- Treating delivery as a separate concern makes it possible to explain a failed notification without calling the payment itself a failure.
- What this does not establish
- Retry limits, backoff values and receiving-side deduplication guarantees cannot be inferred from this account.
CPG stops at an explicit treasury boundary
- Documented implementation
- The project description records settlement queues and handoff points for treasury-side processing.
- Why the boundary matters
- A handoff keeps ownership of payment processing distinct from the next financial operation.
- What this does not establish
- A queued job or successful handoff is not evidence that accounting and external settlement have completed.
03 / Failure boundaries
When the happy path stops.
Illustrative review cases, not incidents or passing test results. These connect the documented mechanisms to the evidence needed to evaluate them.
A transfer has no API-created session
- Recorded mechanism
- The account describes direct-transfer scanning alongside API-driven payments.
- Review question
- What evidence associates the observed transfer with the correct payment context?
- Evidence needed
- A sanitized detection fixture and a trace of the matching decision.
The merchant callback fails
- Recorded mechanism
- The account describes signed webhook delivery with retries and persisted records.
- Review question
- Can delivery be retried without confusing notification state with payment state?
- Evidence needed
- A delivery attempt history and a repeatable receiver-side test.
Settlement work has been handed off
- Recorded mechanism
- The account describes queue-separated processors and a treasury handoff.
- Review question
- Which acknowledgement proves handoff, and which evidence proves final completion?
- Evidence needed
- A sanitized cross-domain trace showing both outcomes separately.
Implementation scope
The implementation described in the record.
Backend API
Payment Engine & Settlement
- Unified payment orchestrator (Strategy/Adapter)
- Chain-specific workers & processors
- Settlement queues & controllers
Dashboards
Admin & Merchant UI
- Admin dashboard
- Merchant dashboard
- Operational tooling
Payment Products
Widget / Session / Custom Payment
- Integrated payment sessions
- Payment widget config
- Custom payment flows
Technology
- TypeScript
- NestJS
- PostgreSQL
- Redis
- BullMQ
- Next.js
- TailwindCSS
- Docker
- AWS EC2
- Prometheus
- Grafana
Read the original project account
The problem
Had to keep payment state consistent across heterogeneous networks while supporting both API-driven flows and direct wallet transfer detection. The domain also needed merchant/store onboarding, integrated payment UX (widget/session/custom payments), custody wallet operations, settlement processing, webhook delivery tracking, and clean integration points for issuer, treasury, and compliance-oriented services inside the shared dev rollout.
The response
Implemented merchant/store APIs including a public merchant list for store pages and a Developer Site registration flow (auto-approve), backed by SSOT API credentials. Built a unified payment orchestrator (Strategy/Adapter) with SSOT QR persistence and conditional chain scanning, plus chain-specific workers/processors. Implemented payment products APIs (integrated payments, widgets, custom payments) with session/status endpoints and supporting services (exchange rate/gas fee calculation). Added custody wallet management, issuer-facing integration hooks, settlement flows that can hand off into treasury-side processing, and an HMAC-signed webhook delivery system with retry + persistence. The runtime was structured to fit a central dev-pilot rollout layer rather than a standalone service-only deployment.
Overview
- Solo-built crypto payment gateway monorepo: API + monitoring workers + webhooks + operations dashboards.
- Operated as the payment-facing domain inside a broader Beatoz dev-pilot rollout that also covered issuer-facing flows, treasury, custody, CKYC, and other adjacent services.
Key Components
- Merchant/store onboarding (public merchant list + Developer Site store registration)
- Strategy/Adapter payment orchestration per chain/payment type
- Integrated payment products (widget/session/custom payment) and configuration endpoints
- Custody wallet management and provider-based key signing
- Issuer-facing synchronization hooks and shared runtime wiring for downstream financial/compliance domains
- Queue-separated monitoring workers for transaction detection/confirmation
- HMAC-signed webhooks with retry policies and delivery tracking
- Settlement and operational dashboards (Admin/Merchant)
- Runtime conventions aligned with a central AWS-based dev-pilot rollout layer
04 / Materials & limits
What you can — and cannot — verify here.
- A documented account
- The component roles and responsibilities below come from the existing portfolio record. They describe the author’s work; they are not independent verification of the CPG repository.
- A conceptual diagram and film
- The diagram above explains relationships. The opening film establishes atmosphere. Neither is a screenshot of the payment product or a recording of a real transaction.
- No public runtime proof attached
- This page does not provide the original CPG repository, an independently reproducible CPG test run or production transaction logs. It therefore makes no throughput, availability or end-to-end exactly-once guarantee.
Continue into the design notes.
Published notes linked below discuss the design principles separately from implementation evidence.