Architecture Plan

Webasen Domain System Migration

Architecture and workflow plan for migrating domain purchasing from eNom to Name.com while preserving the existing Cloudways and WordPress hosting automation.

Architecture and delivery plan preparedLaravel hosting platform powered by Cloudways
LaravelName.com APIStripeQueuesDNS Management

Section 1

Project Overview

Webasen is a DIY web hosting platform powered by Cloudways. The existing system allows users to sign up for WordPress hosting and automatically provision their website. The requested upgrade is to replace the current eNom domain purchase process with Name.com, add standalone domain purchases, and provide customers with DNS management from the dashboard.

Section 2

Core Deliverables

  • Replace eNom integration with Name.com API.
  • Update existing Laravel code that interacts with eNom.
  • Add public standalone domain purchasing without requiring hosting.
  • Allow customers to manage DNS records through a dashboard.
  • Keep existing Cloudways and WordPress provisioning stable.
  • Ensure Stripe and Laravel queue reliability.

Section 3

Proposed Architecture

The registrar logic should be isolated behind a service layer instead of directly replacing eNom calls inline. This reduces risk, protects the existing hosting flow, and makes the system easier to maintain if another registrar is added later.

01RegistrarInterface
02NameComRegistrarService
03DomainService
04DomainOrderService
05DnsService
06StripeWebhookController
07RegisterDomainJob
08SyncDnsRecordsJob
09Domain model
10DomainOrder model
11DomainDnsRecord model
12DomainActivityLog model

Section 4

Main Workflow

  1. 1

    Customer searches for a domain.

    Laravel checks availability and pricing through the Name.com service layer.

  2. 2

    Customer checks out through Stripe.

    Hosting purchases continue through the existing hosting signup flow. Domain-only purchases use a separate order flow and do not trigger Cloudways or WordPress provisioning.

  3. 3

    Stripe confirms payment through webhook.

    Laravel records the payment confirmation and dispatches a queued domain registration job.

  4. 4

    Laravel queue registers the domain through Name.com.

    The job must be idempotent to avoid duplicate purchases during retries.

  5. 5

    The domain status is updated.

    Orders move through pending_payment, payment_confirmed, registration_pending, registered, or failed.

  6. 6

    Customer manages DNS from the dashboard.

    The dashboard supports A, CNAME, MX, TXT, and AAAA records where supported by the API.

Domain States

pending_paymentpayment_confirmedregistration_pendingregisteredfailed

Supported DNS Records

ACNAMEMXTXTAAAA

Section 5

Risk Control Plan

  • Map all current eNom usage before modifying production behavior.
  • Build Name.com integration on staging first.
  • Keep hosting provisioning isolated from domain-only purchases.
  • Use Stripe webhooks as the source of truth for paid orders.
  • Use idempotency keys and order status checks before domain registration.
  • Log API requests, API failures, queue failures, and DNS changes.
  • Add admin retry tools for failed registrations where possible.

Section 6

Stripe and Queue Reliability

  • Payment-first workflow.
  • Stripe webhook verification.
  • Queue-based domain registration.
  • Idempotent jobs.
  • Failed job visibility.
  • Manual retry support.
  • Domain order status tracking.
  • No domain registration directly from the frontend request.

Section 7

DNS Dashboard Plan

  • Customer domain list.
  • DNS record table.
  • Add, edit, and delete DNS records.
  • Validation before API call.
  • Clear success and error states.
  • Activity history for support.
  • Admin visibility for debugging.

Section 8

Delivery Timeline

  1. Day 1

    Review Laravel codebase and map eNom, hosting signup, Stripe, Cloudways, and customer account flows.

  2. Day 2

    Build and test the Name.com API integration layer on staging.

  3. Day 3

    Replace the eNom registration flow and verify the existing hosting signup remains stable.

  4. Day 4

    Build standalone domain purchase flow without triggering Cloudways or WordPress provisioning.

  5. Day 5

    Build DNS management dashboard, validate records, add logs, test queues and webhooks, handle edge cases, and prepare handoff.