Skip to main content

💰 Billing & Revenue Architecture

The Kloyst platform heavily diverges mathematically across the two specific WABA offerings. Understanding the backend execution is vital for ensuring no financial bleeding occurs.

1. Shared WABA Wallet Design​

The Shared WABA requires bullet-proof database concurrency principles. Since we (Kloyst) are liable for the WhatsApp bill from Meta, we must guarantee we collect funds beforehand.

Logic Pipeline​

  • A Tenant recharges $100.00 via Stripe/Razorpay into their Ledger.
  • Wallet row now indicates balance: 100.00.
  • Meta executes a webhook denoting a Marketing Conversation took place.
  • Our engine calculates our Markup: Meta Base Cost + Kloyst Margin = Deduction.
  • Database Transaction (Locking):
    1. BEGIN;
    2. SELECT balance FROM "Wallet" WHERE "vendorId" = X FOR UPDATE; (Locks other requests from modifying)
    3. UPDATE "Wallet" SET balance = balance - Deduction;
    4. INSERT INTO "Ledger" ...;
    5. COMMIT;

Why FOR UPDATE is Critical​

If a campaign delivers 5,000 read receipts inside a 3-second window, without row-level locking, 5,000 asynchronous callbacks will read a balance of $10.00 simultaneously and simply update it sequentially causing a massive negative balance bleed (Phantom Writes).

2. Dedicated WABA Invoice Design​

For Enterprise dedicated setups, financial liability is shifted entirely to the customer's direct relationship with Meta. We only act as a volume-transit software.

Logic Pipeline​

  • Zero dependency on wallet verification blocking outbound limits.
  • The Monthly Invoice revolves purely on:
    • Base Platform SaaS Subscription ($299/mo).
    • Software Usage Transit Fee ($0.002 per message tracked securely in postgres counters).

3. The Margin Calculation Object (Caching Strategy)​

Because parsing margin adjustments frequently from Postgres is heavy, we strongly utilize Redis payload caching to attach margins to webhooks directly in memory:

{
  "vendorId": "uuid-1234",
  "planType": "shared",
  "rates": {
    "marketing": 0.08,
    "utility": 0.03,
    "service": 0.02
  }
}

When a webhook determines a "marketing" tag triggered, we fetch against this Redis map almost instantly and calculate exact deduction decimals.