Security Software in E-commerce (Middle-Tier Architecture)

E-commerce security is not a single piece of software — it is a set of functions distributed across the layers of a web application architecture. Understanding where each security function executes, and why, requires understanding the three-tier model that underlies most web applications: the presentation tier (the browser and front-end code the user interacts with), the application tier (the server-side logic that processes requests), and the data tier (the database that stores persistent data). The middle tier — the application tier — is where the majority of e-commerce security logic executes. In Java-based architectures, the middle tier is implemented using JSPs (JavaServer Pages) and Java Servlets running on an application server such as Apache Tomcat or JBoss. In Node.js architectures, Express.js or Fastify handle the equivalent role. In both cases, the middle tier sits between the user-facing front end and the database, processing payment transactions, enforcing access controls, validating input, managing sessions, and coordinating with external payment APIs. This lesson examines the security functions that the middle tier must implement for an e-commerce application, grounded in the payment security standards and tooling that govern production deployments in 2026.

Before examining specific security functions, it is worth mapping those functions to the tier where they execute, because the placement determines both the effectiveness of the control and the compliance obligations it satisfies. The presentation tier handles user-facing security: HTTPS enforcement (redirecting HTTP to HTTPS), Content Security Policy headers that prevent cross-site scripting by restricting which scripts the browser will execute, and client-side input validation that provides immediate user feedback without being relied upon for actual security enforcement. Presentation-tier security improves usability but cannot be trusted — a malicious actor can bypass the browser entirely and send requests directly to the application tier. The application tier — the middle tier — handles the security functions that actually protect the system: server-side input validation and sanitization, authentication and session management, authorization enforcement, payment API integration, PCI DSS compliance logic, fraud detection, and audit logging. Every security function that involves trusting data or making access control decisions must execute in the middle tier, where the application controls the execution environment. The data tier handles encryption at rest, role-based access controls on database users, and backup integrity. The middle tier controls which database operations execute and with what credentials — parameterized queries passed from the middle tier to the database prevent SQL injection by ensuring that user-supplied input is never interpreted as SQL syntax.

Authentication in an e-commerce application confirms that the user making a request is who they claim to be. The middle tier implements authentication by validating credentials against stored (hashed) values and issuing session tokens that subsequent requests must present. Password storage in the middle tier should use a slow hashing algorithm — bcrypt, scrypt, or Argon2 — rather than fast cryptographic hashes like SHA-256. Fast hashes allow attackers who obtain a database of password hashes to test billions of guesses per second using GPU hardware. Slow hashing algorithms introduce a deliberate computational cost that makes brute-force attacks impractical. In a Java Servlet, bcrypt integration uses the jBCrypt library; in Node.js, the bcrypt npm package provides equivalent functionality. Multi-factor authentication (MFA) adds a second verification step beyond the password. TOTP (Time-based One-Time Password) — the algorithm behind Google Authenticator and Authy — generates a six-digit code that changes every thirty seconds and is validated by the middle tier against a shared secret stored per user. For high-value accounts (administrators, merchants with payment management access), MFA is not optional — it is the primary defense against credential compromise. Session tokens issued after successful authentication must be cryptographically random, stored server-side (in Redis or a database session store), and associated with security metadata: the IP address and User-Agent at login time, the session creation timestamp, and an absolute expiration. The middle tier validates the session token on every request, checks that the security metadata matches, and invalidates the session on logout or after the expiration period. Storing session state in a signed JWT (JSON Web Token) is an alternative approach — the middle tier signs the token with a secret key, and subsequent requests are validated by verifying the signature without a database lookup, at the cost of losing the ability to invalidate individual sessions before expiration.

Payment processing is the highest-stakes security function in any e-commerce application. The Payment Card Industry Data Security Standard (PCI DSS) defines twelve requirements governing how cardholder data must be handled, transmitted, and stored. The middle tier's design determines which PCI DSS requirements apply to the application and how burdensome compliance is.
The cardinal principle of modern e-commerce payment architecture is: never let raw cardholder data touch your application server. When cardholder data flows through the middle tier — even briefly — the middle tier becomes in-scope for PCI DSS, triggering extensive audit and security requirements. Modern payment gateways provide client-side tokenization tools specifically to prevent this.

• Stripe Elements renders payment form fields as iframes hosted on Stripe's servers. The cardholder types their card number into a Stripe-hosted iframe embedded in the merchant's checkout page. The card number never enters the merchant's browser context, never traverses the merchant's application server, and never reaches the merchant's database. Stripe's JavaScript returns a payment method token — a string like pm_1OqLfX2eZvKYlo2C5g8BmZbv — that the merchant's front end submits to the merchant's middle tier. The middle tier uses the Stripe Node.js SDK or Java SDK to confirm the payment intent using that token. The actual card processing happens entirely within Stripe's PCI-compliant infrastructure.
  

  
  // Node.js middle tier — confirming a payment intent
  const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);
  
  app.post('/confirm-payment', async (req, res) => {
    const { paymentMethodId, amount, currency } = req.body;
    
    const paymentIntent = await stripe.paymentIntents.create({
      amount,           // in smallest currency unit (cents for USD)
      currency,
      payment_method: paymentMethodId,
      confirm: true,
      return_url: 'https://merchant.com/order-confirmation'
    });
    
    res.json({ status: paymentIntent.status });
  });
  

• PayPal's JavaScript SDK follows the same tokenization pattern. PayPal renders its own payment button and handles the authorization flow; the merchant's middle tier captures the authorized payment using PayPal's server-side API with a captured order ID.
• Square Terminal extends this security model to in-person and card-not-present transactions, providing PCI-compliant hardware that encrypts card data at the point of entry — the encrypted data flows to Square's servers without the merchant application ever handling plaintext card data.

The middle tier's role in this architecture is coordination: creating payment intents or orders with the gateway, confirming them after client-side tokenization, handling webhook events from the gateway (payment succeeded, payment failed, dispute opened, refund processed), and updating the order management database accordingly. The middle tier never stores, processes, or transmits raw Primary Account Numbers (PANs), CVV codes, or magnetic stripe data.

3D Secure 2.0 (3DS2) is the current standard for authenticating cardholders during online transactions. It replaced both the original 3D Secure protocol and the earlier SET (Secure Electronic Transaction) protocol, which was developed in 1996 but never achieved widespread adoption due to its complexity and implementation cost.
3DS2 operates through a frictionless flow for low-risk transactions and a challenge flow for higher-risk ones. In the frictionless flow, the card issuer evaluates risk signals such as device fingerprint, transaction history, IP geolocation, billing address match — and approves the transaction without interrupting the checkout experience. In the challenge flow, the issuer presents an additional verification step: a one-time code sent to the cardholder's registered phone number, or a biometric verification through the issuer's mobile banking app. The middle tier's role in 3DS2 is to pass the correct risk signals to the payment gateway and handle the authentication result. Stripe's Payment Intents API handles 3DS2 automatically — when the card issuer requires a challenge, Stripe returns a `requires_action` status with a redirect URL. The middle tier detects this status and returns the redirect URL to the front end, which redirects the user to complete the challenge. After the challenge, the user returns to the merchant's site and the middle tier confirms the payment intent. 3DS2 also shifts liability. When a transaction is authenticated through 3DS2 and subsequently disputed as fraudulent, liability shifts from the merchant to the card issuer. For merchants handling high-value transactions or operating in high-fraud categories, 3DS2 authentication is not just a security measure — it is financial risk management.

Fraud detection in e-commerce has evolved from static rule engines to machine learning models trained on billions of transactions. The contrast between the two approaches illustrates how AI integration has changed the security software landscape.

• Manual rule-based fraud detection executes logic in the middle tier: if the order total exceeds $500 and the billing address does not match the shipping address and the IP address is in a high-risk country, flag the transaction for manual review. Rule sets are written by fraud analysts based on known fraud patterns and tuned over time as fraud tactics evolve. The limitations are inherent: rules are static, fraud patterns change faster than rules are updated, and high thresholds generate false positives that decline legitimate transactions.
• AI-powered fraud prevention — Stripe Radar, PayPal's fraud protection, Signifyd, Kount — applies machine learning models trained on transaction data across millions of merchants. These models evaluate hundreds of signals simultaneously: device fingerprint, typing cadence on the payment form, velocity of transactions from the same device, card BIN (Bank Identification Number) risk profile, email address reputation, shipping address history. The model produces a risk score; the merchant's middle tier receives that score from the gateway's API response and applies merchant-specific business logic — auto-decline above a certain threshold, flag for manual review in a band below that threshold, auto-approve below a lower threshold.

The middle tier integration for Stripe Radar is passive — Radar evaluates every payment intent automatically and applies the merchant's configured rules without additional API calls. For standalone fraud platforms like Signifyd, the middle tier makes an explicit API call to the fraud platform with order data after payment authorization but before fulfillment, and waits for the fraud decision before releasing the order to the fulfillment system.

Transport Layer Security (TLS) 1.3 is the current standard for encrypting data in transit between the user's browser and the web server. TLS creates an encrypted channel through a handshake process: the server presents its digital certificate, the client verifies the certificate against trusted certificate authorities, and both parties negotiate a session key for encrypting subsequent communication. All payment data, session tokens, and personal information transmitted between the browser and the application server travels through this encrypted channel.

• Digital certificates — specifically TLS certificates — authenticate the server's identity to the browser. The padlock icon in the browser address bar indicates that the connection is TLS-encrypted and the server's certificate has been verified by a trusted certificate authority. Let's Encrypt provides free, automatically renewed TLS certificates through the ACME protocol, eliminating the cost barrier that made HTTPS deployment selective before 2016. Production e-commerce applications should configure HSTS (HTTP Strict Transport Security) to instruct browsers to always use HTTPS for the domain, preventing protocol downgrade attacks.
• For data at rest, the database layer encrypts sensitive fields — stored payment method references, billing addresses, personally identifiable information — using AES-256. The middle tier handles the encryption key management, typically delegating to a managed key management service (AWS KMS, Google Cloud KMS, HashiCorp Vault) rather than storing encryption keys in application configuration files.

SQL injection remains one of the most common and damaging attack vectors against web applications. The attack works by embedding SQL syntax in user-supplied input — a search field, a form parameter, a URL query string — that the application passes to the database without sanitization, causing the database to execute the embedded SQL as a legitimate query.
The middle tier prevents SQL injection through parameterized queries. Rather than building SQL strings by concatenating user input, the middle tier passes the SQL statement with placeholder parameters to the database driver separately from the parameter values. The database driver ensures the parameter values are treated as data, never as SQL syntax, regardless of what characters they contain.

// Java Servlet — parameterized query preventing SQL injection
PreparedStatement stmt = connection.prepareStatement(
    "SELECT * FROM orders WHERE customer_id = ? AND status = ?"
);
stmt.setInt(1, customerId);
stmt.setString(2, status);
ResultSet rs = stmt.executeQuery();

ORMs — Hibernate for Java, Sequelize or Prisma for Node.js — generate parameterized queries automatically when using their query builder APIs, making SQL injection prevention the default behavior rather than something developers must remember to implement.
Web Application Firewalls (WAFs) — AWS WAF, Cloudflare WAF, Fastly — operate at the network layer before requests reach the application server. They apply rule sets that block common attack patterns: SQL injection attempts, cross-site scripting payloads, directory traversal attempts, and known exploit signatures. WAFs provide a defense-in-depth layer, but they cannot replace proper input validation in the middle tier — a sophisticated attacker can often craft payloads that bypass WAF rules if the application itself is vulnerable.

The middle tier is responsible for generating the audit log that compliance frameworks require. PCI DSS requires logging of all access to cardholder data, all authentication attempts (successful and failed), and all administrative actions. GDPR requires the ability to demonstrate what personal data is held, how it is processed, and when it was accessed. The middle tier logs these events to a centralized logging system — Datadog, Splunk, AWS CloudWatch — with sufficient detail to support forensic investigation after a security incident.
Data privacy compliance affects the middle tier's data handling logic directly. GDPR's right to erasure requires that when a user requests deletion of their account, the middle tier orchestrates deletion of personal data across all storage systems: the primary database, the email marketing platform, the support ticket system, and any analytics systems that store user-level data. CCPA requires that users be able to opt out of data sale and that the application honor those preferences in its data processing logic.
International e-commerce introduces additional compliance considerations. Multi-currency support requires the middle tier to handle currency conversion, display prices in the user's local currency, and process payments in the appropriate currency through the payment gateway's multi-currency APIs. Stripe's multi-currency support allows merchants to present prices in 135+ currencies while settling in their home currency. Subscription businesses require recurring billing logic in the middle tier: creating subscription records through Stripe Billing or PayPal Subscriptions, handling failed payment retries according to a dunning schedule, and managing plan upgrades, downgrades, and cancellations through the gateway's subscription management API. In the next lesson, you will learn about specific examples and properties of bundled software solutions.