Case Study — Internal PlatformsInternal · Production

Bymond Customer & Billing Platform

The subscription, billing, and account system Bymond built to run its own commercial operations, including BigBlueButton Host.

Overview

What we built

Bymond built its own customer and billing platform to run its subscription hosting business: customer accounts, subscription lifecycle, Stripe-powered billing alongside manual GST-compliant invoicing for Indian customers, payment webhooks, invoice generation, and service-quota provisioning, unified behind one portal.

The Problem

Billing logic that can't live in more than one place

Running a subscription hosting business across multiple currencies, with customers in India alongside customers in the US, Europe, and elsewhere, and GST-compliant invoicing on top, is operationally fragile the moment pricing logic exists in more than one place. A client-side price calculation, a stale cached exchange rate, or a checkout payload a client is trusted to supply correctly can each produce a wrong charge or a tax-compliance problem. The platform needed one authority for what something costs, full stop.

Requirements

What the platform needed to guarantee

  • A single authoritative source of pricing and currency conversion.
  • Checkout that can never be manipulated by a client-supplied price.
  • Correct region-specific tax handling, including Indian GST.
  • Resilient payment-provider integration with webhook delivery guarantees.
  • Automatic, currency-correct renewal billing.
  • Low-friction customer login without a password to leak or reuse.

Architecture

The API layer is the only place pricing logic runs. A checkout quote fans out from the billing engine to payment providers, the database, and provisioning at once: a paid quote simultaneously charges the customer, persists the record, and updates their service quota.

Customer Portal
API Layer
Billing Engine
Stripe & Manual Billing
Database
Provisioning
Engineering Challenges

What was actually hard

Preventing price tampering

Client applications never compute prices. Every checkout is locked to a signed, time-limited pricing quote generated server-side; the backend rejects any client-supplied price, tax, or exchange-rate override at checkout time, no matter what the request payload claims.

Multi-currency, multi-jurisdiction billing

All internal accounting runs in one canonical currency. India is forced to INR with 18% GST applied after conversion; other regions default sensibly. Conversion uses daily-cached central-bank reference rates rather than ad hoc lookups at checkout time.

Renewals that stay correct over time

A subscription renewal recomputes from the canonical currency using the reference rate for the renewal date itself, rather than freezing a rate at signup, so a multi-year subscription doesn't silently drift from real currency movement.

Passwordless auth without weakening security

Login uses a one-time code exchanged for an HttpOnly, Secure, same-site-strict session cookie rather than a password. Sensitive values (one-time codes, credentials, webhook secrets) are redacted from server logs by policy, not left to convention.

Two different cancellation paths, one customer action

Stripe-billed subscriptions cancel at the end of the paid period through Stripe itself. India's manually invoiced subscriptions need an equivalent local cancellation flag instead. The same customer-facing cancel action has to route to the mechanism that actually applies.

Solution

How it fits together

The backend is the sole source of pricing: a checkout can only proceed against a signed quote it generated itself, with no client-supplied amount ever trusted. Stripe handles card billing for subscription and one-time charges; Indian customers who need GST-compliant invoicing outside Stripe's flow are billed manually against the same canonical pricing engine, so both paths agree on what a plan actually costs. Provisioning is wired to the same billing events, so a paid plan maps automatically to real service quota instead of requiring a manual step.

Interface

What the portal looks like

The mockup below is a representative sample of the portal's layout and information architecture. It shows how the pieces above surface to a customer, and is not a real customer's data.

B
Bymond Customer PortalENTERPRISE ACTIVE
Workspace: org_bymond_global
2FA Security On
Manage Billing
Illustrative product interface. This is a representative mockup of the platform's UI and layout. The node counts, hours, and invoice figures shown below are sample data, not real customer metrics.
Active Server Nodes
12 Nodes
Auto-Scaling Active
Monthly WebRTC Hours
4,850 hrs
+14% vs previous month
Current Plan
Dedicated Pool
Renews Sep 1, 2026
Provisioned Infrastructure & SaaS Subscriptions3 Active Managed Services
Scalelite Load-Balanced BBB ClusterFLAGSHIP
Multi-node pool · Sub-300ms latency · Global TURN
RUNNING
Automated MP4 Video Recording Pipeline
Background rendering worker · S3 Cloud Archival
RUNNING
Recent InvoicesView All
INV-2026-0801PAID
Aug 1, 2026 · BBB Host Cluster₹45,000
INV-2026-0701PAID
Jul 1, 2026 · BBB Host Cluster₹45,000
Technology

What it's built on

Next.jsExpress (Node.js)TypeScriptMongoDBStripeJWT / HttpOnly Cookies
Production Considerations

Running it, not just building it

  • Security: signed, time-limited pricing quotes; HttpOnly/Secure/SameSite session cookies; sensitive values redacted from logs by policy.
  • Reliability: a webhook delivery and retry model, so a missed payment-provider callback doesn't silently drop a billing event.
  • Compliance: GST-compliant invoicing for Indian customers, applied after currency conversion rather than approximated.
Related Solutions

See it in context

Need billing logic that can't be gamed?

Subscription billing, multi-currency pricing, and payment integrations: tell us what you're building.