Skip to content
Mehedi Hasan Sagor

// blog

Designing a Scalable Laravel E‑Commerce Architecture with Secure Payments

Mehedi Hasan Sagor Oct 20, 2026 6 min read
Designing a Scalable Laravel E‑Commerce Architecture with Secure Payments

Why a Thoughtful Architecture Matters

When you launch an online store, the first few weeks can feel like a sprint—adding products, tweaking UI, and chasing orders. But without a solid foundation, the inevitable traffic spikes, new payment methods, and feature requests will turn that sprint into a marathon you can’t finish.

A well‑engineered Laravel e‑commerce stack gives you:

  • Modularity – swap out a payment provider or add a marketplace module without rewriting core logic.
  • Scalability – handle thousands of concurrent shoppers with minimal latency.
  • Security – keep card data out of your servers and stay PCI‑DSS compliant.
  • Observability – quickly spot checkout failures before they hurt revenue.

The following blueprint balances pragmatic development speed with long‑term maintainability. It assumes you are comfortable with Laravel 10+, Docker, and a relational database like MySQL or PostgreSQL.

1. Core Domain Separation

Instead of a monolithic products, orders, and users table, split the domain into bounded contexts. This mirrors the way a real store operates and makes future extensions (subscriptions, rentals, B2B pricing) easier.

app/
├─ Models/
│  ├─ Catalog/Product.php
│  ├─ Catalog/Category.php
│  ├─ Sales/Order.php
│  ├─ Sales/OrderItem.php
│  └─ Users/Customer.php
├─ Services/
│  ├─ Catalog/ProductService.php
│  ├─ Sales/OrderService.php
│  └─ Payments/PaymentGateway.php
└─ Http/Controllers/
   ├─ Catalog/ProductController.php
   ├─ Sales/CheckoutController.php
   └─ Payments/WebhookController.php
  • Catalog – handles product data, inventory, and pricing rules.
  • Sales – orchestrates the checkout flow, creates orders, and emits domain events.
  • Payments – abstracts the gateway (Stripe, PayPal, etc.) behind a common interface.

Using Laravel's Service Container to bind the concrete gateway at runtime keeps the rest of the code agnostic:

// App/Providers/PaymentServiceProvider.php
public function register()
{
    $this->app->singleton(\App\Services\Payments\PaymentGateway::class, function ($app) {
        return match(config('services.payment.default')) {
            'stripe' => new \App\Services\Payments\StripeGateway(),
            'paypal' => new \App\Services\Payments\PayPalGateway(),
            default => throw new \InvalidArgumentException('Unsupported gateway'),
        };
    });
}

2. Checkout Flow – Keep It Stateless

A common pitfall is storing the entire cart in the database and mutating it during checkout. Instead, treat the cart as a value object held in the client (session storage or local storage) and send a concise payload to the server.

POST /checkout
Content-Type: application/json

{
  "customer_id": 42,
  "items": [
    {"product_id": 101, "quantity": 2},
    {"product_id": 57, "quantity": 1}
  ],
  "payment_method_id": "pm_1Hh2..."
}

The controller validates the request, resolves the current price (including discounts), and delegates to OrderService::createFromCart(). All heavy lifting—tax calculation, inventory reservation, and payment intent creation—happens inside a transaction to guarantee atomicity.

// App/Http/Controllers/Sales/CheckoutController.php
public function store(Request $request)
{
    $validated = $request->validate([
        'customer_id' => 'required|exists:customers,id',
        'items' => 'required|array|min:1',
        'items.*.product_id' => 'required|exists:products,id',
        'items.*.quantity' => 'required|integer|min:1',
        'payment_method_id' => 'required|string',
    ]);

    $order = app(OrderService::class)->createFromCart(
        $validated['customer_id'],
        $validated['items'],
        $validated['payment_method_id']
    );

    return response()->json(['order_id' => $order->id], 201);
}

Why a Transaction?

If any step fails—e.g., inventory is insufficient or the payment gateway declines—the database rollbacks, leaving no half‑created orders. Laravel's DB::transaction() makes this straightforward.

DB::transaction(function () use ($orderData) {
    // Reserve stock
    // Create order & items
    // Create payment intent
});

3. Payment Gateway Integration – Stripe Example

Stripe is a popular choice because it offloads PCI scope: the card details never touch your server. The flow is:

  1. Create a PaymentIntent on the server with the total amount.
  2. Return the client_secret to the front‑end.
  3. Use Stripe.js to confirm the payment.
  4. Listen to checkout.session.completed webhook to finalize the order.

Server‑side Intent Creation

// App/Services/Payments/StripeGateway.php
public function createIntent(int $amount, string $currency, string $paymentMethodId, int $customerId): \Stripe\PaymentIntent
{
    \Stripe\Stripe::setApiKey(config('services.stripe.secret'));

    return \Stripe\PaymentIntent::create([
        'amount' => $amount,
        'currency' => $currency,
        'payment_method' => $paymentMethodId,
        'customer' => $customerId,
        'confirm' => true,
        'metadata' => ['order_id' => $orderId ?? null],
    ]);
}

Webhook Handling

Stripe sends a signed POST request. Verify the signature, then update order status.

// App/Http/Controllers/Payments/WebhookController.php
public function handle(Request $request)
{
    $payload = $request->getContent();
    $sigHeader = $request->header('Stripe-Signature');
    $endpointSecret = config('services.stripe.webhook_secret');

    try {
        $event = \Stripe\Webhook::constructEvent($payload, $sigHeader, $endpointSecret);
    } catch (\UnexpectedValueException $e) {
        return response()->json(['error' => 'Invalid payload'], 400);
    } catch (\Stripe\SignatureVerificationException $e) {
        return response()->json(['error' => 'Invalid signature'], 400);
    }

    if ($event->type === 'payment_intent.succeeded') {
        $intent = $event->data->object;
        $order = Order::where('payment_intent_id', $intent->id)->firstOrFail();
        $order->update(['status' => 'paid']);
    }

    return response()->json(['status' => 'ok']);
}

Key takeaways

  • Store only the payment_intent_id on the order; never store raw card data.
  • Process the webhook asynchronously (dispatch a job) if you need to send emails or update inventory.

4. Scaling the Stack

Queue‑Based Order Fulfilment

Checkout should respond within a few hundred milliseconds. Anything beyond that—sending confirmation emails, updating analytics, or notifying a warehouse—belongs in a queue.

// App/Jobs/SendOrderConfirmation.php
public function handle()
{
    Mail::to($this->order->customer->email)
        ->send(new OrderConfirmed($this->order));
}

Configure a reliable driver (Redis or Amazon SQS) and monitor queue latency with Laravel Horizon.

Read Replicas for Catalog

Product browsing is read‑heavy. Replicate the primary database and direct catalog queries to the replica using Laravel's read connection:

// config/database.php
'connections' => [
    'mysql' => [
        'read' => [
            'host' => env('DB_READ_HOST', 'replica'),
        ],
        'write' => [
            'host' => env('DB_HOST', 'primary'),
        ],
        // other options …
    ],
],

Wrap critical write operations (order creation) with DB::connection('mysql')->transaction() to ensure they always hit the primary.

Caching Frequently Accessed Data

Cache product listings and price lookups for a short TTL (e.g., 60 seconds) to smooth traffic spikes.

Cache::remember("product:{$id}", 60, fn() => Product::find($id));

Use Cache Tags if you need to invalidate a group when inventory changes.

5. Security Checklist for Payments

| Area | Recommendation | |------|----------------| | PCI Scope | Never store raw card numbers; use Stripe Elements or PayPal SDKs. | | HTTPS | Enforce HSTS and use a reputable CDN (Cloudflare, Fastly). | | CSRF | Laravel’s built‑in CSRF token protects the checkout POST endpoint. | | Rate Limiting | Apply ThrottleRequests middleware to /checkout (e.g., 10 attempts per minute per IP). | | Webhook Validation | Verify signatures as shown; reject unknown events. | | Secrets Management | Keep API keys in .env and rotate them regularly; use AWS Secrets Manager or HashiCorp Vault in production. |

6. Deployment Playbook

  1. Infrastructure as Code – Terraform or Pulumi to spin up VPC, RDS, and ElasticCache.
  2. Zero‑Downtime Deploys – Use Laravel Envoy or GitHub Actions to run php artisan migrate --force inside a rolling update (Blue/Green). Ensure migrations are backward‑compatible (add columns, not drop).
  3. Observability –
    • Logs: Ship storage/logs/*.log to Loki or CloudWatch.
    • Metrics: Export request latency, queue lag, and payment success rates to Prometheus.
    • Tracing: OpenTelemetry integration helps trace a checkout request across the API, queue, and webhook.
  4. Backup & Recovery – Automated nightly snapshots of the primary DB; test point‑in‑time restores quarterly.
  5. Feature Flags – Wrap new payment methods in a flag (e.g., features.apple_pay) using spatie/laravel-feature-flags to roll out safely.

7. Take Action – Your First Milestone

Sketch your domain model using the three bounded contexts (Catalog, Sales, Payments). Build a minimal checkout API that creates an order and a Stripe PaymentIntent. Deploy it behind a staging domain, enable HTTPS, and fire a test webhook. Once the flow works end‑to‑end, iterate by adding caching and queue jobs.

By treating the e‑commerce platform as a collection of well‑defined services rather than a tangled monolith, you gain the flexibility to grow—whether that means adding subscription billing, marketplace features, or a mobile‑first storefront—without compromising security or performance.

Prepared by Mehedi Hasan Sagor, Full‑Stack Engineer – Laravel, Vue, Ionic, React Native

  • Laravel
  • Architecture
  • Payments
  • E Commerce