PCI DSS Compliant ERP Systems & Secure Payment Processing

Financial Transaction Engineering: PCI DSS Compliance Architecture

Executive Summary

This is the encryption, network, and ledger design behind PCI DSS aligned ERP systems built by ERPStack. The current standard is PCI DSS v4.0.1. The most valuable engineering decision in this domain is not a stronger control — it is a smaller scope. Software that never sees a primary account number falls outside most requirements entirely, so every design below pushes cardholder data toward the gateway and away from your ERP and its PostgreSQL database.

Cardholder Data Isolation

Tokenisation at the browser. Card fields render inside the processor's own iframe — Stripe Elements, Adyen, or Braintree — so the PAN travels from the shopper's browser to the gateway without touching your Next.js servers, your logs, or PostgreSQL. The ERP receives a token, the card brand, and the last 4 digits.

Network segmentation. The application tier is separated from payment-adjacent services by security groups that deny by default. Terraform describes the AWS VPC, so the boundary is reviewable as code rather than as a screenshot. Database subnets carrying financial records are private, reachable only through named application roles.

Strong cryptography. TLS 1.3 on every route, with weak cipher suites removed at the load balancer rather than merely deprioritised. At rest, tokens and transaction records are encrypted with AES-256.

Key management. Keys live in AWS Key Management Service or Microsoft Azure Key Vault on a 90-day rotation, with a grant held only by the payment service. Every key use is logged with the calling identity — which is the evidence an assessor tests, rather than the policy document describing it.

Requirement 10: Reconstructing Who Did What

// Append-only payment ledger in PostgreSQL. No PAN, no CVV, no PIN — ever.
// Amounts are stored in minor units to avoid float rounding.
import { integer, pgTable, serial, timestamp, varchar } from 'drizzle-orm/pg-core';

export const paymentAuditLog = pgTable('payment_audit_log', {
  id: serial('id').primaryKey(),
  transactionId: varchar('transaction_id', { length: 256 }).notNull(),
  userId: varchar('user_id', { length: 256 }).notNull(),
  actionType: varchar('action_type', { length: 64 }).notNull(), // TOKENIZE | REFUND | VOID
  amount: integer('amount').notNull(),
  currency: varchar('currency', { length: 3 }).notNull(),
  paymentToken: varchar('payment_token', { length: 256 }).notNull(),
  clientIp: varchar('client_ip', { length: 45 }).notNull(),
  timestamp: timestamp('timestamp', { mode: 'date' }).defaultNow().notNull(),
});

Ledger rows are write-once — UPDATE and DELETE are revoked for every PostgreSQL role — and replicate within seconds to offsite AWS object storage under a write-once lock.

Vulnerability Management

Requirement 6 and Requirement 11 assume continuous work rather than an annual scramble. Semgrep SAST runs on every commit in GitHub Actions and dependency audits fail the build on a high-severity match. Internal and external vulnerability scans run at least quarterly and after any significant change. RBAC lets a billing coordinator read a transaction and issue a refund while denying edits to the ledger itself, and Zod schemas reject malformed payment payloads at the API boundary before they reach business logic.

Operational Outcomes

Tokenisation removes most systems from the cardholder data environment, which is what shrinks a 12-requirement assessment to a short questionnaire. Rate limits and edge filters block card-testing and credential-stuffing traffic before it reaches checkout. And scope reduction is achieved without pushing the customer onto a hosted page that breaks the buying flow.

Stack and Boundaries

The PCI DSS aligned ERP runs on Next.js and TypeScript with PostgreSQL behind Drizzle ORM, deployed by Terraform into your own AWS or Microsoft Azure account. RBAC is enforced in the Next.js API layer, Redis holds 0 payment data, and Zod validates 100% of API boundaries. Semgrep SAST, Vitest, and Playwright run in GitHub Actions on every commit. ERPStack operates 0 of it: after handover no ERPStack account reaches your PostgreSQL cluster or your AWS keys, so we sit outside your cardholder data environment.