Skip to content

Business Flows (Cross-App)

This section documents how real user actions move through the system.

The goal here is not to explain apps or files, but to clearly answer:

  • A flow starts from where
  • Which systems participate
  • Where decisions are made
  • What gets created or updated

If you want to understand how the system actually behaves in production, this section is critical.

Product Discovery → Purchase Flow

Public Browsing

  • Home page shows featured products
  • Products page lists all products
  • Products can be filtered by category
  • Clicking a product opens the Product Detail page

Product Detail Page Logic

  • Not logged in user
  • Cannot buy
  • Prompted to login
  • Logged in user
  • If product NOT purchased → Buy Now
  • If product already purchased → Download

Buy Now → Login → Redirect

When a logged-out user clicks Buy Now:

  1. User is redirected to the login page
  2. After successful login:
  3. User is redirected back to the same product detail page
  4. This preserves purchase intent

Checkout Flow

From the product detail page:

  1. User clicks Buy Now
  2. User is taken to a Checkout page
  3. Checkout page includes:
  4. Order summary
  5. Billing address form
  6. User clicks Continue to Secure Payment
  7. Payment is initiated and user is redirected to DodoPayments

At this stage:

  • An Order is created
  • is_paid = false

Payment → Access Grant Flow

Payment Processing

  • DodoPayments handles the actual payment
  • After payment attempt, a webhook is triggered

Webhook Responsibilities

The DodoPayments webhook:

  • Verifies payment status
  • Updates the existing Order:
  • is_paid = true if successful
  • is_paid = false if failed
  • Creates PurchasedProduct only on successful payment

Important Rules

  • Order is created even if payment fails
  • PurchasedProduct is created only when payment is successful
  • Failed payments do not grant access

This separation allows:

  • Accurate order history
  • Clear audit trail
  • Safe retry or support handling

Product Download & Update Flow

Download Flow

  • When a user clicks Download
  • The system generates a pre-signed URL
  • The file:
  • Is private
  • Expires after a few minutes
  • Cannot be reused

This ensures:

  • Secure delivery
  • No public file exposure
  • Controlled access

Product Update Badge Logic

When a product is edited or updated:

  • product.updated_at is updated
  • A badge is shown if: product.updated_at > (now() - 3 days)

Key points:

  • Any product edit triggers this
  • Badge is shown for 3 days
  • Helps users identify newly updated products
  • No version tracking required

Purchased users can:

  • Re-download the latest version
  • Without paying again (lifetime access)

Support Request Flow (Customer Side)

Support Request Creation

  • Support can be raised only for purchased products
  • There is no upfront payment at request creation time
  • Request is sent directly to the seller

At this stage:

  • SupportRequest is created
  • Seller is notified
  • No payment is attached yet

Support States

SupportRequest follows fixed states:

  • NEW
  • DISCUSSING
  • PAYMENT
  • IN_PROGRESS
  • COMPLETED
  • CANCELLED

This ensures predictable handling and UI consistency.

Support Handling Flow (Seller Side)

Seller can:

  • View incoming support requests
  • Read customer messages
  • Change support status
  • Add a meeting link
  • Add internal admin notes

Payment for support:

  • Is manually decided
  • Happens during discussion/payment phase
  • Not automatically enforced by the system

This keeps support flexible and realistic.

ShortURL Flow

When a ShortURL is accessed:

  1. Expiry check is performed
  2. Destination URL is resolved
  3. Redirect happens
  4. Hit count is incremented

ShortURLs:

  • Can point to internal or external URLs
  • Can be reused
  • Destination can be changed anytime
  • Support expiry or lifetime access

Under-Construction Flow

When under-construction mode is active:

  • A middleware blocks the entire project
  • Public pages, auth pages, and panels are blocked
  • Users see an under-construction page

Bypass Mechanism

  • Access is allowed only if:
  • A secret key is passed as a GET query parameter
  • This allows:
  • Admins
  • Sellers to access the site during maintenance

Seller Analytics Flow (High-Level)

Seller dashboard analytics:

  • Data updates on page refresh
  • Not precomputed in advance
  • Cached to avoid empty or slow dashboard loads

This provides:

  • Fresh data
  • Acceptable performance
  • Smooth UX
  • Reduce Google Analytics API hits

Background Tasks (Celery Usage)

Celery is used for:

  • Database backups
  • Sending Telegram notifications for support requests
  • Email verification
  • Password reset emails

Celery Beat is used to:

  • Schedule recurring tasks
  • Manage tasks via admin UI

These tasks are intentionally kept out of request-response cycles.

How to Use These Flows

Every app-level decision documented later will map back to one of these flows.

If you are:

  • Debugging → trace the flow
  • Customizing → identify the flow first
  • Adding features → decide which flow it belongs to

Understanding flows first prevents accidental breakage.