Commerce core
Keep business rules—catalog eligibility, checkout decisions, order transitions and operational policies—inside an explicit application layer. Web and mobile experiences should consume those rules instead of duplicating them.
These public docs explain Thonem architecture and integration patterns. They intentionally avoid inventing universal endpoint names because concrete APIs can vary by implementation and release.
Keep business rules—catalog eligibility, checkout decisions, order transitions and operational policies—inside an explicit application layer. Web and mobile experiences should consume those rules instead of duplicating them.
A payment gateway or shipping provider should not leak provider-specific concepts across the whole commerce codebase. An adapter translates the provider into a smaller internal contract.
// illustrative contract — not a public endpoint
PaymentAdapter.authorize(order, paymentContext)
PaymentAdapter.handleCallback(providerPayload)
PaymentAdapter.refund(transaction, amount)Callbacks should be authenticated where supported, parsed defensively, recorded with an idempotency key, acknowledged quickly and moved into controlled processing. Repeated provider delivery must not repeat a destructive action.
Separate static marketing routes from application routes. Validate Nginx before reload, switch files atomically where practical, smoke-test application baselines, and keep a rollback path that does not require restoring the entire platform.
Inventory → wrap → replace → verify → retire. Each retired legacy module should leave fewer hidden dependencies, not simply relocate them to a new framework.
Non-critical failures should create a useful error reference and preserve the main journey where doing so is safe. Payment, inventory or security failures should never be silently converted into success.
Exact API routes, credentials, signatures, database schemas and private operational runbooks are deployment-specific and are not published here.
These guides are intentionally provider-neutral where possible. Exact deployed contracts remain project-specific.
Scope one complete commerce journey and protect what already works.
DESIGNDomain boundaries, adapters and incremental modernization.
EVENTSVerification, idempotency, retries and safe side effects.
RELEASEPreflight, protected-route baselines, atomic switch and rollback.
RUNDiagnose failures while preserving transaction truth.
CONFIGSeparate public settings, runtime values and secrets.
DEBUGScope failures, collect evidence and recover safely.
CHANGEManage compatibility across code, data and integrations.
TRUSTTrust boundaries, privilege, credentials and auditability.
DIAGNOSESeparate public overlay health, local checks and protected-route baselines.
MANIFESTRegenerate machine-readable indexes and verify the public website release.
CONTRACTSStable boundaries, errors, idempotency and versioning.
QUALITYVerify journeys, contracts and failure behavior.
SPEEDMeasure and optimize from evidence.
CONTENTGenerate indexes and registries from published pages.
Search the generated public documentation index.
Search docs →Understand how published HTML becomes search, docs and release metadata.
Read guide →Keep website, application, database and provider versions separate.
Read guide →