Forem: abhishek pundir

Payment Processing in Modern E-Commerce: Payment Gateways & Security

abhishek pundir — Thu, 16 Apr 2026 02:31:58 +0000

Processing payments seems simple: user enters card → charge → done. In reality, it's one of the most security-critical, regulation-heavy, and complex parts of e-commerce. Get it wrong and you lose customers, money, and trust. Here's what you need to know.

The Payment Processing Landscape

Every year, e-commerce platforms process trillions in transactions. But the infrastructure behind it is surprisingly intricate:

Customer → Merchant (You) → Payment Processor → Payment Gateway 
→ Card Network → Issuing Bank → Customer's Bank

Each step requires authentication, encryption, compliance, and error handling. One failure at any point = no sale.

Why You Can't DIY Payment Processing

Never store credit card data yourself.

Seems obvious, right? Yet every year, companies get hacked because they thought they could handle card data "just this once."

PCI-DSS Compliance

If you store, process, or transmit credit card data, you must comply with PCI-DSS (Payment Card Industry Data Security Standard).

Requirements include:

✅ Data encryption (in transit AND at rest)
✅ Network firewalls and intrusion detection
✅ Secure password management
✅ Regular security testing
✅ Restricted access to cardholder data
✅ Audit logging (every access recorded)
✅ Security incident response plan

The cost? Compliance audits run $10K-100K+ per year. A breach? $200K-millions.

The solution? Use a PCI-compliant payment processor. They handle the liability.

Payment Gateways: How They Work

The Ecosystem

┌──────────────┐
│   Customer   │
│  (Cardholder)│
└────────┬─────┘
         │
┌────────▼──────────────┐
│  Your E-Commerce App  │
└────────┬──────────────┘
         │
┌────────▼──────────────────────┐
│   Payment Processor (Stripe)   │
│  - Tokenization              │
│  - Fraud detection           │
│  - Network routing           │
└────────┬──────────────────────┘
         │
┌────────▼──────────────────┐
│  Card Networks (Visa, MC) │
└────────┬──────────────────┘
         │
┌────────▼────────────────────┐
│  Issuing Bank (Customer's)  │
│  - Approves/Declines       │
│  - Charges account         │
└─────────────────────────────┘

Top Payment Processors

Processor	Best For	Fees	Complexity
Stripe	Startups, SaaS, Subscription	2.9% + $0.30	Low
Square	Retail, Point-of-Sale	2.6% + $0.10	Low
PayPal	B2C, Marketplace	3.49% + $0.49	Medium
Braintree	Marketplace, Subscriptions	2.9% + $0.30	Medium
Authorize.net	Enterprise, Established	2.5% - 3.5%	High

We recommend Stripe for most use cases — excellent documentation, developer-friendly, worldwide coverage.

Implementing Stripe: Step by Step

Step 1: Client-Side Tokenization

Never send raw card data to your server. Use Stripe.js to tokenize on the client:

<!-- HTML -->
<form id="payment-form">
  <div id="card-element"></div>
  <button id="submit-btn">Pay $99.99</button>
</form>

<script src="https://js.stripe.com/v3/"></script>
<script>
  const stripe = Stripe('pk_live_YOUR_PUBLIC_KEY');
  const elements = stripe.elements();
  const cardElement = elements.create('card');
  cardElement.mount('#card-element');

  document.getElementById('payment-form').addEventListener('submit', async (e) => {
    e.preventDefault();

    // Tokenize card on client
    const { token } = await stripe.createToken(cardElement);

    if (token) {
      // Send token (not card!) to your server
      const response = await fetch('/api/charge', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ token: token.id, amount: 9999 })
      });

      const result = await response.json();
      if (result.success) {
        alert('Payment successful!');
      }
    }
  });
</script>

Key point: Card data never touches your server.

Step 2: Server-Side Charge

Your backend receives only the token, never the card:

import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

async function chargeCard(req: Request, res: Response) {
  const { token, amount, description } = req.body;

  try {
    // Create charge using token
    const charge = await stripe.charges.create({
      amount: amount,  // in cents
      currency: 'usd',
      source: token,
      description: description,
      metadata: {
        orderId: req.body.orderId,
        userId: req.user.id
      }
    });

    if (charge.status === 'succeeded') {
      // Save order to database
      await Order.create({
        userId: req.user.id,
        amount: amount,
        chargeId: charge.id,
        status: 'paid'
      });

      res.json({ success: true, chargeId: charge.id });
    }
  } catch (error) {
    console.error('Charge failed:', error.message);
    res.status(400).json({ success: false, error: error.message });
  }
}

Advanced: Payment Intents (Recommended)

Stripe deprecated simple charges in favor of Payment Intents—more flexible, handles 3D Secure, subscriptions, etc.

async function createPaymentIntent(req: Request, res: Response) {
  const { amount, customerId, orderId } = req.body;

  try {
    // Create payment intent
    const paymentIntent = await stripe.paymentIntents.create({
      amount: amount,
      currency: 'usd',
      customer: customerId,
      description: `Order #${orderId}`,
      metadata: { orderId },
      // Require confirmation (3D Secure, etc.)
      confirmation_method: 'manual',
      confirm: false
    });

    // Return client secret to client
    res.json({ clientSecret: paymentIntent.client_secret });
  } catch (error) {
    res.status(400).json({ error: error.message });
  }
}

Client-side:

async function confirmPayment(clientSecret) {
  const { paymentIntent, error } = await stripe.confirmCardPayment(clientSecret, {
    payment_method: {
      card: cardElement,
      billing_details: { name: 'Jenny Rosen' }
    }
  });

  if (paymentIntent.status === 'succeeded') {
    console.log('Payment successful!');
  } else if (error) {
    console.error('Payment failed:', error.message);
  }
}

Why Payment Intents?

✅ Handles complex payment methods (digital wallets, bank transfers)
✅ Automatic 3D Secure / 2FA
✅ SCA compliance (Strong Customer Authentication)
✅ Idempotent (retry-safe)

Handling Payment Webhooks

Payments are asynchronous. The customer's bank doesn't approve instantly. Use webhooks:

// Listen for Stripe events
app.post('/webhooks/stripe', express.raw({type: 'application/json'}), async (req, res) => {
  const sig = req.headers['stripe-signature'];
  const event = stripe.webhooks.constructEvent(
    req.body,
    sig,
    process.env.STRIPE_WEBHOOK_SECRET
  );

  switch (event.type) {
    case 'payment_intent.succeeded':
      const paymentIntent = event.data.object;
      console.log(`Payment successful: ${paymentIntent.id}`);

      // Update order status
      await Order.updateOne(
        { paymentId: paymentIntent.id },
        { status: 'paid' }
      );

      // Send confirmation email
      await sendConfirmationEmail(paymentIntent.metadata.orderId);
      break;

    case 'payment_intent.payment_failed':
      console.log('Payment failed');
      // Notify customer
      break;

    case 'charge.refunded':
      // Handle refund
      await Order.updateOne(
        { chargeId: event.data.object.id },
        { status: 'refunded' }
      );
      break;
  }

  res.json({received: true});
});

Critical: Always verify webhook signature:

// ✅ CORRECT - Verify signature
const event = stripe.webhooks.constructEvent(body, sig, secret);

// ❌ WRONG - No verification (vulnerability!)
const event = JSON.parse(body);

Security Best Practices

1. HTTPS Everywhere

All communication with payment processors MUST be HTTPS. Stripe enforces this.

// ✅ Correct
const stripe = new Stripe('https://api.stripe.com/...', {
  https: true
});

// ❌ Never HTTP

2. Store Tokens, Not Cards

If you need to charge recurring:

// Create customer and save card
const customer = await stripe.customers.create({
  email: user.email,
  payment_method: token,
  invoice_settings: { default_payment_method: token }
});

// Later: charge without card
await stripe.paymentIntents.create({
  amount: 5000,
  customer: customer.id,
  off_session: true
});

Never store raw card data. Never.

3. Idempotency Keys (Prevent Double-Charges)

Network timeout? Retry? Stripe will see duplicate request.

import crypto from 'crypto';

async function chargeUser(userId, amount) {
  // Create unique idempotency key
  const idempotencyKey = crypto
    .createHash('sha256')
    .update(`${userId}-${amount}-${Date.now()}`)
    .digest('hex');

  try {
    const charge = await stripe.paymentIntents.create(
      {
        amount,
        currency: 'usd',
        customer: userId
      },
      { idempotencyKey }  // Stripe uses this for deduplication
    );

    return charge;
  } catch (error) {
    // Even on error, same key returns same result
    // Safe to retry
    throw error;
  }
}

Result: If network fails mid-request, retry safely without double-charging.

4. Rate Limiting & Fraud Detection

Implement rate limiting on your payment endpoint:

import rateLimit from 'express-rate-limit';

const paymentLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,  // 15 minutes
  max: 10,                    // 10 attempts
  message: 'Too many payment attempts, try again later',
  standardHeaders: true,
  legacyHeaders: false
});

app.post('/api/charge', paymentLimiter, async (req, res) => {
  // Handle payment
});

Use Stripe's built-in fraud detection:

const paymentIntent = await stripe.paymentIntents.create({
  amount: 5000,
  currency: 'usd',
  payment_method: paymentMethod,
  // Enable radar (Stripe's fraud detection)
  payment_method_options: {
    card: {
      request_three_d_secure: 'automatic'
    }
  }
});

5. Environment Variables

Never hardcode API keys:

// ✅ Correct
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

// ❌ WRONG - exposes key in git history
const stripe = new Stripe('sk_live_abc123...');

.env file (in .gitignore):

STRIPE_PUBLIC_KEY=pk_live_...
STRIPE_SECRET_KEY=sk_live_...
STRIPE_WEBHOOK_SECRET=whsec_...

6. Input Validation

Always validate amounts, currencies, and metadata:

async function validateAndCharge(req: Request) {
  const { amount, currency, orderId } = req.body;

  // Validate amount
  if (!Number.isInteger(amount) || amount < 50) {
    throw new Error('Invalid amount');
  }

  // Validate currency
  if (!['usd', 'eur', 'gbp'].includes(currency)) {
    throw new Error('Invalid currency');
  }

  // Validate order exists and belongs to user
  const order = await Order.findById(orderId);
  if (!order || order.userId !== req.user.id) {
    throw new Error('Order not found');
  }

  // Validate amount matches order
  if (order.total !== amount) {
    throw new Error('Amount mismatch');
  }

  // Safe to charge
  return await stripe.paymentIntents.create({ amount, currency });
}

Handling Different Payment Methods

Modern e-commerce isn't just credit cards:

async function createPaymentIntent(req: Request, res: Response) {
  const { amount, paymentMethod } = req.body;

  const paymentIntent = await stripe.paymentIntents.create({
    amount: amount,
    currency: 'usd',
    payment_method: paymentMethod,
    // Enable multiple payment methods
    payment_method_types: [
      'card',
      'ideal',           // Netherlands
      'bancontact',      // Belgium
      'giropay',         // Germany
      'eps',             // Austria
      'sofort',          // Europe
      'alipay',          // Asia
      'wechat_pay'       // China
    ]
  });

  res.json({ clientSecret: paymentIntent.client_secret });
}

Handling Disputes & Chargebacks

Customers will dispute charges. Here's how to handle it:

// Listen for chargeback
app.post('/webhooks/stripe', async (req, res) => {
  const event = stripe.webhooks.constructEvent(req.body, sig, secret);

  if (event.type === 'charge.dispute.created') {
    const dispute = event.data.object;

    console.log(`Chargeback: ${dispute.id}`);
    console.log(`Amount: ${dispute.amount}`);
    console.log(`Reason: ${dispute.reason}`);

    // Your response strategy
    const evidence = {
      access_activity_log: 'Logs showing customer accessed account',
      billing_address: 'Delivery confirmed to billing address',
      customer_communication: 'Emails showing customer confirmed purchase',
      customer_email_address: 'customer@example.com',
      customer_name: 'John Doe'
    };

    // Submit evidence
    await stripe.disputes.update(dispute.id, { evidence });
  }

  res.json({ received: true });
});

Tips to prevent chargebacks:

✅ Clear product descriptions
✅ Prominent refund policy
✅ Send confirmation emails
✅ Include shipping tracking
✅ Respond to disputes with evidence

PCI Compliance Checklist

Even with a payment processor, you're responsible for:

✅ HTTPS/TLS encryption
✅ Access control (who can see payment data?)
✅ Regular security audits
✅ Vulnerability scanning
✅ Incident response plan
✅ Employee security training
✅ Audit logging

You DON'T need to comply if:

✅ You never touch raw card data
✅ You use tokenization (Stripe, PayPal, etc.)
✅ You use hosted payment forms

Cost Structure

Typical payment processing costs:

Service	Monthly	Per-Transaction	Notes
Stripe	Free	2.9% + $0.30	Lowest for small volumes
Square	Free	2.6% + $0.10	Good for retail
PayPal	Free	3.49% + $0.49	Higher fees
Authorize.net	$25	2.5%-3.5%	Better for high volume

Example: 1,000 transactions at $50 average

Stripe: $1,460/month
Square: $1,310/month
Authorize.net: $25 + $1,250 = $1,275/month

At scale, processor choice matters.

Common Mistakes

1. Not Testing Failed Payments

Use Stripe test cards:

4000 0000 0000 0002  → Card declined
4000 0025 0000 3155  → Requires authentication
5200 0282 2222 2210  → Mastercard declined

Test both success and failure paths.

2. Ignoring Webhook Failures

If Stripe webhook fails, order status is wrong. Implement retries:

async function handleWebhookWithRetry(event, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      await processWebhook(event);
      return;
    } catch (error) {
      console.log(`Attempt ${i + 1} failed:`, error);
      if (i < maxRetries - 1) {
        await sleep(1000 * Math.pow(2, i)); // exponential backoff
      }
    }
  }
}

3. Hardcoding Production Keys

Use environment variables. Period.

4. Not Handling Currency Correctly

Stripe uses the smallest unit (cents for USD, paise for INR):

// ✅ Correct
const amount = 99.99 * 100;  // 9999 cents

// ❌ Wrong
const amount = 99.99;  // Will charge $0.99

5. Trusting Client-Side Validation Alone

Client validation is for UX. Server validation is for security:

// ✅ Always validate on server
async function charge(req: Request) {
  const { amount } = req.body;

  // Never trust client amount
  const order = await Order.findById(req.body.orderId);
  const actualAmount = order.total;  // Server source of truth

  if (amount !== actualAmount) {
    throw new Error('Amount mismatch - fraud attempt?');
  }

  return stripe.paymentIntents.create({ amount: actualAmount });
}

Building Secure Payment Infrastructure

Payment processing is complex. Many companies choose to not build it themselves.

At Vexio, we handle payment integration for enterprise e-commerce platforms. We:

✅ Integrate with Stripe, PayPal, Square (any processor)
✅ Ensure PCI compliance
✅ Implement fraud detection
✅ Handle disputes and chargebacks
✅ Support multiple currencies and payment methods
✅ Provide secure webhooks and reconciliation
✅ Build custom payment workflows

If you're building an e-commerce platform, let Vexio handle payment infrastructure so you can focus on your business.

Summary: Payment Processing Checklist

Before going live with payments:

✅ Choose a processor (Stripe recommended)
✅ Implement client-side tokenization
✅ Use Payment Intents (not deprecated charges)
✅ Verify webhook signatures
✅ Implement idempotency keys
✅ Add rate limiting
✅ Enable fraud detection
✅ Store environment variables securely
✅ Validate on the server
✅ Test with all payment methods
✅ Document your implementation
✅ Set up monitoring and alerts
✅ Plan for disputes and chargebacks

Resources

Next Steps

Building an e-commerce platform with payments?

Start with Stripe (easiest to integrate)
Test thoroughly with test cards
Implement webhooks for async payment confirmation
Use Payment Intents (not charges)
Never store raw card data
Monitor transactions and disputes

Questions about payment integration? Drop a comment below.

Ready to build secure payment infrastructure?

👉 Explore Vexio's e-commerce solutions →

We specialize in helping companies integrate payments, manage transactions, and build scalable payment systems.

Building Scalable E-Commerce Platforms: Architecture & Best Practices

abhishek pundir — Sun, 12 Apr 2026 13:07:19 +0000

Handling Black Friday traffic spikes, managing inventory across warehouses, processing thousands of orders per minute—e-commerce architecture is deceptively complex. Here's what we learned building platforms that scale.

The E-Commerce Challenge

The typical e-commerce platform needs to:

Handle 10x-100x traffic spikes during sales
Process payments reliably (no lost transactions)
Keep inventory accurate across channels
Search millions of products in milliseconds
Deliver personalized recommendations
Work flawlessly on mobile (70%+ of traffic)

Most platforms break under this pressure. We've learned why—and how to fix it.

Architecture: The Foundation

Separation of Concerns

Modern e-commerce isn't one monolith. It's multiple specialized services:

┌─────────────────────────────────────────────┐
│         CDN (CloudFlare, Akamai)            │
│    (Static content, API caching)            │
└────────────────────┬────────────────────────┘
                     │
┌─────────────────────────────────────────────┐
│    API Gateway (Kong, AWS API Gateway)      │
│         (Rate limiting, auth)               │
└────┬─────────────┬──────────────┬───────────┘
     │             │              │
┌────▼──┐  ┌──────▼──┐  ┌───────▼──┐
│Product│  │ Checkout│  │ Inventory│
│Service│  │ Service │  │ Service  │
└────┬──┘  └────┬────┘  └───┬──────┘
     │          │           │
└────┬──────────┬───────────┘
     │
┌────▼──────────────────────┐
│   Message Queue (Kafka)   │
└────┬──────────────────────┘
     │
┌────▼──────────────────────┐
│  Background Jobs/Workers  │
│ (Email, Analytics, etc)   │
└───────────────────────────┘

Key services:

Product Service - catalog, search, recommendations
Shopping Cart Service - quick add/remove, persistence
Checkout Service - payment processing, order creation
Inventory Service - stock levels, reservations
Order Service - order management, fulfillment
User Service - authentication, profiles

Each service:

✅ Has its own database
✅ Scales independently
✅ Deploys separately
✅ Owned by one team

Database Architecture

The Problem: One Database Won't Work

A single PostgreSQL instance will:

Struggle with concurrent writes (lock contention)
Slow down under complex joins
Become a bottleneck

Our Solution: Database per Service + Read Replicas

┌─────────────────┐
│ Product Service │
├─────────────────┤
│ PostgreSQL      │
│ (Products DB)   │
│ + 2 Read Reps   │
└────────┬────────┘
         │
┌────────▼────────┐
│ Checkout Service│
├─────────────────┤
│ PostgreSQL      │
│ (Orders DB)     │
│ + 1 Read Rep    │
└────────┬────────┘
         │
┌────────▼────────┐
│ Inventory Svc   │
├─────────────────┤
│ PostgreSQL      │
│ (Inventory DB)  │
│ + 3 Read Reps   │
└─────────────────┘

Write to primary, read from replicas:

// Product Service - Heavy read workload
const getProducts = async (filters) => {
  // Read from replica (faster, no write locks)
  return await readReplicaDB.query(`
    SELECT * FROM products 
    WHERE category = $1 AND price < $2
    LIMIT 100
  `, [filters.category, filters.maxPrice]);
};

const updatePrice = async (productId, newPrice) => {
  // Write to primary (ensures consistency)
  await primaryDB.query(
    'UPDATE products SET price = $1 WHERE id = $2',
    [newPrice, productId]
  );

  // Invalidate cache
  await redis.del(`product:${productId}`);
};

Why this matters: Your product searches don't interfere with order processing.

Caching: The Secret Weapon

Most e-commerce performance issues = inadequate caching.

Our caching strategy (in order):

CDN (CloudFlare) - Static assets, API responses
Redis - Hot data (top 100 products, popular searches)
Application memory - Lightweight cache for request lifetime
Database - Last resort

// Multi-layer cache example
async getProduct(productId: string) {
  // Layer 1: Memory cache (ultra-fast)
  const cached = this.memoryCache.get(`product:${productId}`);
  if (cached) return cached;

  // Layer 2: Redis (fast, shared across servers)
  let product = await this.redis.get(`product:${productId}`);
  if (product) {
    this.memoryCache.set(`product:${productId}`, product, { ttl: 300 });
    return product;
  }

  // Layer 3: Database (slow)
  product = await this.db.products.findById(productId);

  // Cache it
  await this.redis.setex(
    `product:${productId}`, 
    3600,  // 1 hour TTL
    JSON.stringify(product)
  );

  return product;
}

Cache invalidation on updates:

async updateProduct(productId: string, updates: any) {
  // Update database
  const product = await this.db.products.update(productId, updates);

  // Invalidate all cache layers
  this.memoryCache.delete(`product:${productId}`);
  await this.redis.del(`product:${productId}`);

  // Notify all services via event
  await this.messageQueue.publish('product.updated', { productId });

  return product;
}

Search: Beyond Basic SQL

You can't SELECT * FROM products WHERE at scale. You need specialized search.

Elasticsearch for Product Search

// Index products in Elasticsearch
const indexProduct = async (product) => {
  await elasticsearch.index({
    index: 'products',
    id: product.id,
    body: {
      name: product.name,
      description: product.description,
      category: product.category,
      price: product.price,
      tags: product.tags,
      rating: product.averageRating,
      inStock: product.quantity > 0
    }
  });
};

// Search with facets
const searchProducts = async (query, filters) => {
  const results = await elasticsearch.search({
    index: 'products',
    body: {
      query: {
        bool: {
          must: [
            { multi_match: { 
              query: query, 
              fields: ['name^2', 'description'] 
            }}
          ],
          filter: [
            { range: { price: { gte: filters.minPrice, lte: filters.maxPrice } } },
            { term: { category: filters.category } },
            { term: { inStock: true } }
          ]
        }
      },
      aggs: {
        categories: { terms: { field: 'category' } },
        priceRange: { range: { field: 'price', ranges: [...] } }
      }
    }
  });

  return {
    products: results.hits.hits.map(h => h._source),
    facets: results.aggregations
  };
};

Why Elasticsearch > SQL for search:

✅ Full-text search with typo tolerance
✅ Faceted search (filters, categories)
✅ Relevance ranking
✅ Autocomplete with suggestions
✅ Scales to 100M+ products

Payment Processing: Get This Right

Never handle credit cards yourself. Use PCI-compliant payment processors.

import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

async processPayment(order: Order, paymentMethod: string) {
  try {
    // Create payment intent
    const paymentIntent = await stripe.paymentIntents.create({
      amount: order.totalAmount * 100, // cents
      currency: 'usd',
      payment_method: paymentMethod,
      confirmation_method: 'manual',
      confirm: true,
      metadata: { orderId: order.id }
    });

    if (paymentIntent.status === 'succeeded') {
      // Update order status
      await this.orderService.markPaid(order.id);

      // Publish event for downstream processing
      await this.messageQueue.publish('payment.succeeded', {
        orderId: order.id,
        amount: order.totalAmount,
        timestamp: new Date()
      });

      return { success: true, transactionId: paymentIntent.id };
    }
  } catch (error) {
    // Payment failed - don't retry automatically
    await this.orderService.markFailed(order.id, error.message);
    throw error;
  }
}

Key principles:

Use established payment gateways (Stripe, PayPal, Square)
Store payment tokens, never raw card data
Implement idempotency (prevent double-charging)
Handle webhooks for async confirmation

Inventory Management: The Tricky Part

Inventory seems simple. It's not.

The problem: Race conditions.

Customer A: Check stock → 1 item left
Customer B: Check stock → 1 item left
Customer A: Buy → Reserved
Customer B: Buy → OVERSOLD! (2 sold, 1 in stock)

Solution: Pessimistic Locking

async reserveInventory(orderId: string, items: OrderItem[]) {
  const connection = await this.db.getConnection();

  try {
    // Lock inventory rows for this transaction
    await connection.query('BEGIN TRANSACTION');

    for (const item of items) {
      // Lock the row
      const stock = await connection.query(
        'SELECT * FROM inventory WHERE sku = $1 FOR UPDATE',
        [item.sku]
      );

      if (stock.quantity < item.quantity) {
        throw new Error(`Insufficient stock for ${item.sku}`);
      }

      // Deduct stock
      await connection.query(
        'UPDATE inventory SET quantity = quantity - $1 WHERE sku = $2',
        [item.quantity, item.sku]
      );

      // Create reservation record
      await connection.query(
        'INSERT INTO reservations (order_id, sku, quantity) VALUES ($1, $2, $3)',
        [orderId, item.sku, item.quantity]
      );
    }

    await connection.query('COMMIT');
  } catch (error) {
    await connection.query('ROLLBACK');
    throw error;
  }
}

Result: Only one customer gets the item. Guaranteed.

Performance Optimization Checklist

Frontend

✅ Lazy load images (Intersection Observer)
✅ Code split by route
✅ Compress images (WebP, AVIF)
✅ Minimize JavaScript bundles
✅ Service worker for offline support

API Layer

✅ GraphQL (over-fetching prevention) or REST with sparse fields
✅ API response compression (gzip)
✅ HTTP/2 or HTTP/3
✅ Proper cache headers (ETag, Last-Modified)

Database

✅ Indexes on frequently filtered columns
✅ Denormalization for common queries
✅ Partitioning for large tables (orders by date)
✅ Connection pooling

Infrastructure

✅ Auto-scaling (CPU/memory-based)
✅ Load balancing across regions
✅ Database read replicas
✅ Content delivery networks (CDN)

Real-World Metrics

Our e-commerce platform handles:

Metric	Value
Peak traffic	500K requests/second
Product catalog	50M+ items
Search latency (p95)	150ms
Checkout success rate	99.7%
Page load time (p75)	1.2 seconds
Uptime	99.99%

Common Pitfalls to Avoid

1. Synchronous Everything

❌ Wrong: Wait for email to send before confirming order

✅ Right: Queue email job, confirm order immediately

2. No Circuit Breakers

❌ Wrong: Call payment processor, wait forever if it's down

✅ Right: Fail fast, queue for retry, notify customer

3. Undersizing for Peaks

❌ Wrong: Size for average load (crashes on sale day)

✅ Right: Plan for 10x peak load, use auto-scaling

4. Trusting User Input

❌ Wrong: ORDER BY ${req.query.sortBy}

✅ Right: Validate against whitelist, sanitize everything

5. No Monitoring

❌ Wrong: "It works for me" in development

✅ Right: Monitor latency, errors, queue depth 24/7

Tech Stack Summary

Frontend

React/Vue/Next.js with TypeScript
TailwindCSS or Chakra UI
React Query for state management

Backend

Node.js (Express, Fastify) or Python (FastAPI)
PostgreSQL + Redis
Elasticsearch for search
Apache Kafka or RabbitMQ for events

Infrastructure

Docker + Kubernetes
AWS/GCP/Azure
CloudFlare CDN
Stripe/PayPal for payments

Why Architecture Matters

A poorly architected e-commerce platform will:

❌ Lose sales during traffic spikes
❌ Have inventory inconsistencies
❌ Suffer from slow search
❌ Frustrate customers with checkout delays

A well-architected platform will:

✅ Handle 10x traffic seamlessly
✅ Keep inventory accurate
✅ Search 50M+ products in 150ms
✅ Convert more visitors to customers

The difference? System design.

Building vs. Buying

You might be thinking: "Can't I just use Shopify or WooCommerce?"

You can—if:

Your business fits the standard mold
You don't have custom workflows
You can live with vendor limitations
You want minimal technical overhead

You need custom: if you have:

Complex fulfillment workflows
Multi-channel inventory
Unique product attributes
Specific performance requirements
Integration needs

At Vexio, we build custom e-commerce platforms for companies that outgrew their off-the-shelf solutions. We handle the architecture, scaling, payment integrations, and complex workflows so you can focus on growth.

If you're building or scaling an e-commerce platform, explore how Vexio can help with enterprise e-commerce solutions tailored to your business.

Next Steps

If you're building an e-commerce platform:

Identify your bottlenecks - Where will traffic spike? Search? Checkout?
Design for scale early - Database architecture matters
Implement caching - It's not optional
Use managed services - Don't write your own payment processor
Monitor everything - You can't fix what you can't measure

Questions?

Building an e-commerce platform? Struggling with scaling?

Drop a comment or reach out. We've solved these problems and love talking architecture.

Related Resources:

Learn more about building scalable e-commerce systems:

👉 Visit Vexio →

Connect with us to discuss your e-commerce architecture needs.

How We Built a Custom ERP System: Tech Stack & Lessons Learned

abhishek pundir — Sun, 12 Apr 2026 12:57:44 +0000

Building a custom Enterprise Resource Planning (ERP) system is no small feat. Here's what we learned designing and implementing a scalable, modular ERP platform from scratch.

The Problem We Solved

Most companies start with off-the-shelf ERP solutions like SAP or Oracle. But what happens when your business needs are too specific? What if you need:

Custom workflows unique to your industry
Integration with legacy systems that vendors won't support
Real-time data across distributed teams
The ability to pivot features without vendor locks

We faced this exact challenge. So we built our own. Here's how.

Our Tech Stack

Backend: Node.js + NestJS

We chose Node.js with NestJS as our foundation:

Why?

TypeScript for enterprise-grade type safety
Easy to scale horizontally
Rich ecosystem for business logic
Fast development iteration

// Example: Core business module structure
@Module({
  imports: [DatabaseModule, AuthModule],
  controllers: [InventoryController, OrderController],
  providers: [InventoryService, OrderService],
})
export class BusinessModule {}

Pain point: Event-driven updates across modules became complex. Solution: We implemented a message queue pattern with Bull/Redis.

Database: PostgreSQL + Redis

PostgreSQL for transactional data:

ACID compliance (critical for financial records)
Complex joins for reports
Powerful JSON support for semi-structured data

Redis for caching & real-time features:

Session management
Real-time inventory updates
Rate limiting & queue management

-- Example: Inventory table design
CREATE TABLE inventory (
  id UUID PRIMARY KEY,
  sku VARCHAR(50) UNIQUE NOT NULL,
  quantity_on_hand INT NOT NULL,
  quantity_reserved INT DEFAULT 0,
  last_updated TIMESTAMP,
  warehouse_id UUID REFERENCES warehouses(id)
);

Key lesson: Don't underestimate the importance of indexing. A missing index on warehouse_id caused our inventory queries to take 30+ seconds on 1M+ records.

Frontend: React + TypeScript

Built with:

React Query for server state management
Tailwind CSS for consistent UI
Zustand for client state
Vite for fast bundling

The dashboard handles real-time updates via WebSockets—critical for monitoring inventory, orders, and financials simultaneously.

Infrastructure: Docker + Kubernetes

Containerized everything:

Services run in Docker containers
Orchestrated with Kubernetes
Auto-scaling based on CPU/memory
Separate environments: dev → staging → production

# Example: Kubernetes deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: erp-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: erp-api
  template:
    metadata:
      labels:
        app: erp-api
    spec:
      containers:
      - name: erp-api
        image: vexioapp/erp-api:latest
        resources:
          limits:
            memory: "512Mi"
            cpu: "500m"

Architecture Decisions

1. Microservices vs Monolith

We started monolithic, then split.

Initially: Everything in one Node.js app—users, inventory, orders, accounting, reporting. Deployment was single-click. But scaling was painful. If inventory got hammered, the entire system degraded.

What changed: We broke it into domain-driven microservices:

User Service (auth, permissions)
Inventory Service (stock, warehouses)
Order Service (sales orders, fulfillment)
Accounting Service (GL, AP, AR)
Reporting Service (BI, analytics)

Each service:

Has its own database (no shared tables)
Communicates via APIs & message queues
Scales independently

Trade-off: More complex to manage, but operational efficiency improved 40%.

2. Event-Driven Communication

Order placed → triggers inventory deduction → triggers accounting entry.

We use Apache Kafka (or RabbitMQ as alternative):

// Example: Order Service publishes event
async createOrder(orderData) {
  const order = await this.db.orders.create(orderData);

  // Publish event for other services
  await this.messageQueue.publish('order.created', {
    orderId: order.id,
    items: order.items,
    customerID: order.customerId
  });

  return order;
}

// Inventory Service subscribes
messageQueue.subscribe('order.created', async (event) => {
  await this.inventoryService.reserveItems(event.items);
});

Benefit: Services are decoupled. A slow accounting service doesn't block order creation.

3. Real-Time Updates with WebSockets

Managers need live dashboards. We use Socket.io for pushing updates:

// Server: When inventory changes
@Injectable()
export class InventoryGateway {
  @WebSocketServer() server: Server;

  async updateInventory(sku: string, quantity: number) {
    await this.inventoryService.update(sku, quantity);

    // Push to all connected clients
    this.server.emit('inventory.updated', {
      sku,
      newQuantity: quantity,
      timestamp: new Date()
    });
  }
}

Biggest Challenges We Faced

1. Data Consistency Across Services

The problem: Order Service reserves inventory, but Inventory Service is temporarily down. Orders process, but inventory never gets updated.

Solution: Saga pattern for distributed transactions.

async function processOrderSaga(order) {
  try {
    // Step 1: Reserve inventory
    const reservation = await inventoryService.reserve(order.items);

    // Step 2: Create accounting entries
    await accountingService.recordSale(order.amount);

    // Step 3: Update order status
    await orderService.markProcessed(order.id);

  } catch (error) {
    // Rollback everything if any step fails
    await inventoryService.releaseReservation(reservation);
    throw error;
  }
}

2. Reporting Performance

Real-time reports across millions of transactions = slow queries.

We implemented:

Read replicas of the database for reporting
Data warehouse (Snowflake/BigQuery) for historical analytics
Materialized views for common reports

-- Materialized view: Monthly sales by region
CREATE MATERIALIZED VIEW sales_by_region_monthly AS
SELECT 
  EXTRACT(YEAR_MONTH FROM order_date) AS month,
  region,
  SUM(amount) AS total_sales,
  COUNT(*) AS order_count
FROM orders
GROUP BY month, region;

-- Refresh every hour
REFRESH MATERIALIZED VIEW CONCURRENTLY sales_by_region_monthly;

3. Permission & Access Control

Complex organizational hierarchies = complex permissions. You can't just hardcode "user can view orders."

Solution: Role-Based Access Control (RBAC) with attribute-based rules:

// Define permissions
{
  role: "regional_manager",
  permissions: [
    { resource: "orders", actions: ["read", "update"], region: "ASIA" },
    { resource: "inventory", actions: ["read"], warehouse: "ANY" }
  ]
}

// Check before returning data
async getOrders(userId, filter) {
  const user = await this.getUser(userId);
  const allowedRegions = user.permissions
    .filter(p => p.resource === 'orders' && p.actions.includes('read'))
    .map(p => p.region);

  return db.orders.find({ region: { $in: allowedRegions } });
}

Key Lessons Learned

1. Start Simple, Evolve Gradually

Don't architect for Netflix-scale on day one. We spent months on infrastructure we didn't need. MVP first, optimize later.

2. Database Design is Everything

A single missing index or poorly designed schema cascades into system-wide performance issues. Invest time upfront.

3. Logging & Monitoring Are Non-Negotiable

When something breaks in production (and it will), you need to know why. We use:

ELK Stack (Elasticsearch, Logstash, Kibana) for centralized logging
Prometheus + Grafana for metrics
Sentry for error tracking

4. Documentation Saves Time

When you have 5+ services, teams need to understand:

API contracts (OpenAPI/Swagger)
Database schemas
Event formats
Deployment procedures

We use AsyncAPI for documenting message-driven events.

5. Testing is Critical

Unit tests catch logic bugs. But integration tests prevent system-wide failures:

// Integration test: Verify order → inventory → accounting flow
it('should create order and update all services', async () => {
  const order = await orderService.create(testOrder);

  // Verify inventory was reserved
  const inventory = await inventoryService.getReservation(order.id);
  expect(inventory.quantity).toBe(-10);

  // Verify accounting recorded the transaction
  const ledger = await accountingService.getEntries(order.id);
  expect(ledger).toHaveLength(2); // Debit + Credit
});

What We'd Do Differently

Invest in API design early - Changing contracts across services is painful
Build observability from day one - Don't add monitoring after things break
Use events for everything - Even internal service calls; makes debugging easier
Separate read & write models - CQRS pattern simplifies complex domains

The Result

Today, our ERP system handles:

50+ integrated modules (Inventory, Accounting, HR, CRM, etc.)
10M+ transactions/day across multiple regions
99.95% uptime (we're still chasing 99.99%)
Sub-200ms API response times (p95)

But more importantly: it's maintainable. New features take weeks, not months. Teams can own their own services. We can scale components independently.

Why This Matters

Building a custom ERP isn't for everyone. But if your business has unique needs—complex workflows, legacy integrations, specific compliance requirements—an off-the-shelf solution will constrain you.

At Vexioapp, we specialize in helping companies design and build custom ERP systems that actually fit their business. We've learned these lessons so you don't have to. Whether you need a full ERP build, integrations with existing systems, or help modernizing legacy infrastructure, we understand the technical and business challenges.

If you're building or planning an ERP system, check out how Vexioapp can help with enterprise solutions.

Questions?

Have you built custom enterprise systems? What was your biggest challenge?

Drop a comment below or reach out if you want to discuss ERP architecture, tech choices, or lessons learned.

Looking to Build or Upgrade Your ERP System?

If your company is considering a custom ERP, enterprise platform, or e-commerce solution, Vexioapp has the expertise to guide you through the technical decisions and architecture challenges we've covered here.

Visit Vexioapp → to explore our ERP, e-commerce, and enterprise solutions.

Resources: