Inkress ADRsarchitecture decisions
Inkress commerce platform

The decisions behind how it actually works.

A living record of the architecture: card data isolation, the money ledger, tenancy, authorization, and the flows that move real money. Each decision grounded in the code, with the trade-offs it accepted.

47
decision records
28
subsystems
11
visual explainers
EDGE · CARD DATACORE PLATFORM · PAN-FREEDATA · VPCBuyer browsercard-elementsEdge CDECF Worker · retains nothingsealed PANcommerce-apiElixircommerce-workerOban jobscommerce-paymentscontrol planecommerce-riskPDPcommerce-web · storefront + checkoutPanTokenPostgres · MAINPostgres · JOBSObanVault · sealed tokensLedger · double-entryprojectionPowerTranz / FAC3-D Secure

Card data is quarantined at the edge; the core platform and its data stores only ever see tokens.

Visual explainers

How the platform holds together

The flagship decisions, drawn. Each links to the full record.

MERCHANT PAGE (SAQ A)OUR EDGE CDECONTROL PLANE (PAN-FREE)card-elementsiframe on our originWorker /tokenizedecrypts in-isolatePowerTranzPAN → PanTokenVaultsealed at restsealedtokenPAN exists only here, for the request
ADR 0006Cardholder data is isolated to an edge CDE; the platform handles only PanTokens
ledger_transactionscapture path · floatentry writerasync workertransaction_entriesdouble-entry · decimalrunning_balanceper account+currencysourceprojection is rebuildable from source · advisory-lock per account
ADR 0029The double-entry ledger is an async, rebuildable projection of the capture-path ledger
BuyerEdge CDEcommerce-apiPowerTranzenter cardSPI sale + 3DSchallenge (RedirectData)ACS authenticationresult → MerchantResponseUrlgate: Y + CAVVcomplete /spi/paymentthe server finalizes from the captured callback; the browser is never trusted
ADR 0010Card charges use PowerTranz SPI with server-finalized 3-D Secure (strict Y+CAVV)
any queryon a tenant tableOrg.Repo.prepare_queryglobal hookINNER JOIN merchant_recordsWHERE merchant_id = tenantskip_org_id → bypassexplicit escapeambient tenant from the auth pipeline
ADR 0020Tenancy uses polymorphic owner-record tables scoped by a global query hook
RequestcredentialPrincipalone identityDB grants(resource, access_level)YAML policynon-CRUD + ownershipENFORCE_DB_AUTHZ + modelled action → DB, else YAML
ADR 0023Authorization is DB-driven from a resolved Principal, with YAML as the fallback decider
Provider callbackFAC/WiPay/…Session checkoutPaid transitionsubscriptionsenqueue_webhook→ Verk (dead)HTTP enqueue→ ObanNotificationWorker.newrescued no-opDeliveryWorkermerchant webhooksOnly subscription billing is delivered today; provider-path webhooks are dead
ADR 0014Background jobs and outbound merchant webhooks run on Oban, migrating off Verk
The index

All 47 decisions

Grouped by subsystem, in the order they were recorded.