Application Patterns

ENG-01 §3 sets the governing rule: PH epics own Payment Hub domain behavior and data, ENG-01 owns the technology baseline and shared technical scaffolding, and new abstraction should be justified by repeated implementation needs rather than created preemptively. Initial application topology itself remains fully open (DR-003, no current lean recorded); if a modular-monolith approach is confirmed, ENG01-23 would scaffold it on the current-lean NestJS framework (DR-002, open), not a microservices split.

Backend

Current lean: NestJS 11 on Node.js 22 (DR-002/DR-001, open — ENG-01 §4), reflecting the parent PE company's shared platform stack. Not yet built, not yet decided.

Frontend

Current lean: Next.js (App Router) (DR-022, open — ENG-01 §4), reflecting the parent PE company's shared platform stack. Its primary intended role, if confirmed, is the BFF for OX-01's Ops console, per the Identity and Access page. Not yet built, not yet decided. CX-01's own Sender/Recipient-facing Web SDK is a separate concern with its own build/distribution boundary — see ENG-01's ENG01-18 for where that boundary is drawn (open — ENG-01 §4/Decision Register ENG02-25).

API

Not yet fully defined. ENG-01 §6 calls for: HTTP framework and request/schema validation approach, Tenant/authentication context propagation, authorization integration, standard error envelope, versioning, pagination/filtering, and OpenAPI generation, with a reference command endpoint and read endpoint demonstrating all of it — that reference implementation is ENG01-04's deliverable, not yet built.

Error Handling

STD01-04 governs command/event context, not error shape directly, but ENG-01 §5's shared capability catalog calls for a "common technical error envelope and reusable platform error codes without absorbing domain-specific decisions" — i.e., a shared technical-error contract that stays out of payment-domain status/reason modeling, which each PH epic (e.g. PH-06's Decision reasons, PH-08's handoff_status) owns itself.