Diviz — Modern E‑commerce Platform with Flexible Payment Architecture

Project overview

Full-stack e-commerce platform featuring a redesigned Next.js storefront, Laravel backend, and configurable payment workflows including online payments, installments, cheque payments, and customer credit management.

My role

Full-Stack Developer

The problem

A Persian fragrance and beauty storefront needs a consistent shopping experience while supporting immediate payment, manual review, delivery payment, and eligible credit purchases. The redesign also has to connect those different order and financing states to one understandable customer journey.

What I delivered

• Backend: implemented catalog, category, cart, checkout, order, authentication, account, and administrative workflows behind versioned Laravel REST APIs.
• Backend: developed configurable payment methods, server-side eligibility checks, checkout quotes, order creation, payment processing, and protected receipt review.
• Backend: built customer credit profiles, financing-plan selection, down-payment calculations, repayment schedules, credit requests, and administrative approval controls.
• Frontend: designed and implemented Pixel Home with Next.js 16, React 19, TypeScript, Tailwind CSS, reusable components, Persian RTL layouts, and responsive mobile navigation.
• Frontend: integrated dynamic homepage sections, product discovery and detail pages, the shopping cart, checkout, order tracking, and authenticated customer-account interfaces.
• Integration: connected payment and financing selections to backend quotes, preserved order identity on ambiguous retries, and supported both prefixed and canonical Pixel Home routes.

How the system fits together

Laravel backend architecture

Laravel 12 serves versioned REST endpoints for the catalog, categories, search, session-backed carts, checkout, orders, authentication, and customer accounts. Eloquent models represent the relational commerce and financing data. CheckoutService, PaymentGatewayManager, CustomerCreditService, CreditPlanService, and DeferredPaymentService separate business rules from the Next.js presentation layer. Administrative controllers and Blade views manage products, orders, payment settings, credit requests, and financing operations.

Flexible payment architecture

Payment methods describe business workflows; gateway adapters handle online transaction requests and verification. Six methods are represented in the backend. Store settings, customer access rules, order amount, and eligible credit plans determine which choices are available for a particular checkout. Their presence in code does not mean all six are enabled for every live customer.

• Online payment: request a gateway transaction, then verify the callback server-side before recording payment success.
• Card-to-card transfer: require a transfer reference and receipt upload, then register the order for administrative review.
• Cash on delivery: create a delivery-payment order when the configured access rules permit it.
• Cheque payment: attach an eligible financing plan and scheduled cheque obligations, with document and review workflows.
• Installment payment: calculate any required down payment, financing charge, and repayment schedule from the selected plan.
• Wholesale credit: offer approved wholesale customers a matching credit plan and reserve the financed portion against their available credit.

Customer credit and installments

Customer credit profiles carry status, validity, approved limits, credit rank, and method permissions. Plans can restrict customer type, rank, customer group, explicit profile assignment, and order amount. DeferredPaymentService calculates fixed or percentage down payments and financing fees, creates installment or cheque schedules with due dates, and preserves a snapshot of the agreed terms. CustomerCreditService checks remaining credit and overdue obligations; transactional reservations lock the profile and financing record. Customer credit applications support required-document submission and administrative approval, rejection, or requests for corrections. Account interfaces expose credit balances, applications, installments, cheques, and due dates.

ZarinPal integration and gateway boundaries

The ZarinPal adapter implements transaction requests, redirect URLs, status inquiry, and verification against the transaction’s stored amount and authority. It converts stored toman amounts to rials for the gateway. PaymentService serializes callbacks, recognizes already-paid transactions, and keeps uncertain verification pending so the existing authority can be reconciled. Mellat, Saman, Zibal, IDPay, and NextPay are registered adapters that extend AbstractDisabledGateway: they report unconfigured and throw for request or verification. They are extension points, not completed gateway integrations. No live merchant connection or successful financial transaction was verified during this review.

Pixel Home frontend redesign

Pixel Home is the redesigned Persian RTL storefront built with Next.js 16, React 19, TypeScript, Tailwind CSS, and reusable UI components. It includes backend-driven homepage sections, responsive navigation, product cards, catalog filters, search, product details, a cart and checkout flow, order tracking, and customer-account pages. The authenticated account includes orders, addresses, credit requests, cheque obligations, and installments. The captured public homepage, listing, product page, and mobile view show the deployed Pixel Home interface; private account screens were reviewed in source.

REST integration and reversible storefront routing

Server-rendered pages and the browser API client consume Laravel’s REST contracts. Browser requests use the storefront’s same-origin /api/v1 proxy, allowing session cookies and CSRF protection to participate in account and cart flows. Pixel Home has its own /pixel-home routes. A build-time NEXT_PUBLIC_PIXEL_HOME_DEFAULT flag enables beforeFiles rewrites for supported storefront routes and redirects prefixed links to canonical paths while preserving queries. APIs, static assets, and Laravel payment callbacks keep their own routing. This makes the redesign selectable without replacing backend business rules; the public capture confirmed Pixel Home at the root during review.

Checkout state and retry consistency

The backend encrypts a short-lived checkout quote bound to the customer, cart signature, delivery selection, payment method, plan, gateway, and calculated totals. Order creation recalculates those conditions, rejects stale quotes or missing transfer evidence, and checks stock with row locks inside a transaction. The Pixel Home client invalidates quotes when selections change and refreshes them on price, cart, stock, or expiry errors. Its CheckoutAttempt retains the original request body and Idempotency-Key after an ambiguous response, reuses a known order, and separates order creation from payment initiation. Guest cart browsing is supported; the address/checkout step requires authentication and account completion.

Implemented outcome

The implementation brings the redesigned Pixel Home shopping interface together with Laravel-controlled checkout, payment, and financing rules. Administrators can configure payment workflows and manage customer credit while the frontend presents the available choices through shared API contracts. The case study documents these delivered capabilities without attributing revenue, conversion gains, order volumes, user counts, or measured performance improvements.

Validation and evidence

The public storefront and focused local application tests were checked alongside the source review.

• 30 Laravel checkout/payment and credit-application tests passed with 385 assertions against an isolated SQLite test database and fake gateway responses.
• 31 frontend tests passed for checkout retries, API integration, guest-cart/authentication boundaries, and Pixel Home routing/navigation.
• The public homepage, catalog, product details, and mobile storefront were captured using real Chrome.

Scope of verification

• Checkout requires login on the live storefront. No private account, receipt, or payment-method screenshot was captured.
• No real order, financial transaction, merchant credential, production concurrency load, or business performance result was verified.

Engineering challenges

• Keep payment-method eligibility distinct from gateway configuration and customer credit-plan selection.
• Present down payments, finance charges, and remaining obligations consistently across quotes, orders, and customer accounts.
• Handle stale quotes, stock changes, lost responses, and pending gateway verification without treating an uncertain response as a completed payment.
• Introduce the Pixel Home interface while preserving cart sessions, account destinations, backend callbacks, and supported storefront paths.

Technical decisions

• Keep pricing, eligibility, credit reservation, and payment verification on the Laravel side of the REST boundary.
• Persist financing terms and schedules with the order, rather than reconstructing historical obligations from a changing plan.
• Reuse the original checkout attempt after an ambiguous response and reconcile an existing gateway authority before starting another charge.
• Activate Pixel Home through explicit build-time route configuration, with APIs and payment callbacks excluded from template rewrites.