AxoneSIM

Axon eSIM sells data-only eSIM plans to travellers, built for a market where most buyers pay through local wallets rather than international cards. Visitors browse plans priced in both PKR and USD, place an order, pay by JazzCash, EasyPaisa, card or bank transfer, and receive their eSIM QR code and activation details by email and WhatsApp.

Five tables hold the whole business: customers, plans, orders, payments and admins. An order is a text-keyed record (AXN-ABC123-XY99) that links a customer to a plan and moves through a seven-state lifecycle: pending, paid, processing, delivered, activated, then expired or cancelled, with a payments row recorded per attempt.

Access control is server-authoritative. Row-level security locks every table to the database service role and exposes only active plans to anonymous readers, so all order, payment and customer access happens server-side through API routes that hold the service key. The admin area adds a role check against an admins table that runs on every navigation.

Because the primary payment path is a local transfer rather than a synchronous card gateway, a human verification stage sits inside the order lifecycle. The customer uploads a payment screenshot at checkout; an admin later views that proof and sets the eSIM, either uploading the QR image to storage or pasting a QR URL and activation code.

That single action transitions the order to delivered, cascades any still-pending payment to success so the payment record matches the verified state, and fires a delivery email whose contents render conditionally on which eSIM fields were provided. Keeping every transition server-side under the service role means the browser never mutates an order directly, so a record can only advance along the defined path.

For a market where card penetration is low and money arrives by wallet transfer, a manual-verification state machine models how payment actually happens rather than forcing customers through a gateway they would not complete.

ARCH