Technical architecture
Status: Proposed implementation blueprint, subject to partner and hosting choices.
Guiding principles
Start with a modular monolith and a clear payments boundary. Avoid premature microservices. Design for financial correctness, observable operations and safe retries before optimizing throughput.
Proposed stack
| Layer | Proposed technology |
|---|---|
| Merchant and consumer web apps | Next.js App Router, TypeScript |
| API and orchestration | NestJS modular monolith |
| Database | PostgreSQL with Prisma |
| Jobs | Durable managed queues/workers with retries and dead-letter handling |
| Hosting | AWS Sydney for backend, data and worker workloads |
| Payment method storage | PCI-compliant external vault/provider |
| Collection and disbursement | Regulated Australian banking/payments partner |
| Observability | Centralized structured logs, metrics, tracing and alerting |
| Infrastructure | Infrastructure as code, separated dev/staging/prod |
Modules
Identity & Access; Merchant Onboarding; Consumer Profiles; Mandates & Payment Methods; Billing; Orchestration; Partner Adapters; Ledger; Settlement & Reconciliation; Payouts; Pricing & Invoicing; Notifications; Audit & Operations.
Reliability
Use transactional outbox/inbox, unique idempotency constraints, explicit payment state machines and deterministic job identifiers. Workers must safely retry after crashes. Provider timeouts create an unknown state requiring lookup/reconciliation, never an automatic second charge.
Deployment
Keep the documentation site separate from the product runtime. Set up isolated environments, migrations, feature flags, staged releases, CI security checks and rollback procedures. Use managed backups with restore drills. Define SLOs for payment initiation, webhooks and reconciliation.