System Requirements Document for rapid-top

1. Introduction

rapid-top is an Indonesian digital top-up marketplace operated by Xyz_Games. It sells game currency and passes, mobile pulsa and data packages, e-wallet balances, and household bill payments (PLN electricity tokens, electricity bill payment, digital game vouchers) through a single storefront. The product intent is a fast, playful, discovery-driven storefront where buying diamonds feels like opening a loot crate rather than filling a form, backed by visible trust mechanics: 24-hour automated transactions, automated payment across many methods, automated balance deposit, automated WhatsApp notifications, complete transaction history, real-time sales reports, membership tiers with tiered pricing, a reseller program, discount codes and promos, daily flash sales, customer reviews and ratings, and a refund guarantee when a transaction fails.

The audience is Gen-Z and young millennial gamers in Indonesia plus reseller agents who resell the same catalogue to their own customers. The service is delivered as a first-party web application with application-owned identity, a backend that performs payment, fulfilment, deposit, and notification work automatically, and WhatsApp as an outbound notification recipient.

2. System Overview

rapid-top is a single first-party web application with an anonymous public entry, self-service identity establishment, returning verification, a protected shopping and account area, and a protected operational area for the owner/admin. The catalogue spans four families: game top-up (17 named titles plus an ever-growing set of additional products), pulsa & data (5 operators), e-wallet & saldo (7 items), and tagihan & lainnya (3 items). Every purchase is fulfilled by automated 24-hour transaction processing, paid through automated payment with multiple methods, optionally funded from an automatically deposited wallet balance, and confirmed to the customer by automated WhatsApp notification.

Three active human roles use the product: Pembeli / Pelanggan (buyer/customer), Reseller, and Pemilik / Admin Operasional (owner/operational admin). WhatsApp is an outbound-only external recipient, not a persona. Payment providers, game publishers, and operator/biller systems are external services owned outside rapid-top.

Current scope is limited to the catalogue, the transaction lifecycle, the membership and pricing ladder, the reseller program, promotions and daily flash sales, reviews and ratings, refunds for failed transactions, and the operational management surfaces that keep those running. Nothing beyond that is in scope.

2a. Product Interpretation and Delivery Boundary

rapid-top is delivered as a first-party web application. The public entry (Landing) is reachable anonymously and explains the catalogue, payment methods, and service benefits before any protected access. Identity is application-owned: customers and resellers establish it themselves through Sign Up, and all three roles verify it again through Login before reaching protected data and activity. Admin access is not self-service; it is granted through internal provisioning or invitation before operational management becomes available.

Protected state — wallet balance, transaction history, membership level, reseller standing, reviews, refund claims, and all operational management — is only available after identity is established and verified. Payment processing, 24-hour automated transaction fulfilment, automated balance deposit, and automated WhatsApp notification run as backend processes owned by the platform; the human-facing side of those processes (initiating a purchase, funding a wallet, watching a status, reading a notification, claiming a refund) is owned by the pages described in section 2c.

The refund guarantee applies only to transactions that failed. It is not a general cancellation or buyer's-remorse right, and it does not apply to successful transactions. Flash sales run every day. Lower prices are granted according to membership level (Member, Basic, Gold, Platinum). These three facts are hard constraints and are not softened anywhere in this document.

Everything described here is current. No future-horizon features are accepted in this document.

2b. Source Content Inventory

The authoritative source enumerates the following catalogue and system facts. They are preserved exactly.

Top Up Game

• Mobile Legends: Bang Bang — Diamond, Starlight, Weekly Pass
• Free Fire — Diamond, Membership, Token, Bundle
• PUBG Mobile — UC, Royale Pass, Item
• Valorant — Valorant Point, Battle Pass
• Genshin Impact — Genesis Crystal, Blessing
• Honkai: Star Rail — Oneiric Shard, Express Pass
• Zenless Zone Zero — Polychrome, Bangboo Pass
• Roblox — Robux
• Call of Duty Mobile — CP, Battle Pass
• Farlight 84 — Octane, Pass
• Blood Strike — Credits, Pass
• Delta Force — Credits, Pass
• Super Sus — Coins, Pass
• Higgs Domino — Koin Emas
• Ragnarok Origin — Crystal, Pass
• Tower of Fantasy — Tanium, Dark Crystal
• Cookie Run Kingdom — Crystals, Pass
• Lainnya terus bertambah! (additional products are added continuously)

Pulsa & Paket Data

• Telkomsel — Pulsa & Paket Internet
• XL / Axis — Pulsa & Paket Internet
• Indosat — Pulsa & Paket Internet
• Tri (3) — Pulsa & Paket Internet
• Smartfren — Pulsa & Paket Internet

E-Wallet & Saldo

• DANA
• OVO
• GoPay
• ShopeePay
• LinkAja
• Saldo Google Play
• Saldo Apple

Tagihan & Lainnya

• Token Listrik PLN
• Pembayaran Tagihan Listrik
• Voucher Game Digital

Fitur Sistem

• Transaksi Otomatis 24 Jam
• Pembayaran Otomatis — Beragam Metode
• Deposit Saldo Otomatis
• Notifikasi WhatsApp Otomatis
• Riwayat Transaksi Lengkap
• Laporan Penjualan Real-Time
• Level Keanggotaan: Member, Basic, Gold, Platinum
• Harga Lebih Murah Sesuai Level
• Program Reseller
• Kode Diskon & Promo
• Flash Sale Setiap Hari
• Ulasan & Rating Pelanggan
• Garansi Dana Kembali Jika Gagal

2c. Page Content and Component Coverage

Landing

• Information/state: anonymous public entry. Explains the digital product catalogue, the automated payment methods, and the service benefits (24-hour automated transactions, refund guarantee on failed transactions, daily flash sales, membership pricing). Shows a live ticker of recent transactions and a daily flash-sale strip.
• Primary actions: browse into the catalogue; proceed to Sign Up; proceed to Login.
• Supporting actions: explore the hero's low-poly kiosk scene by dragging horizontally to rotate the camera; click an orbiting currency prop to jump straight to that game's top-up page; move through the colour-coded category rail (Top Up Game / Pulsa & Data / E-Wallet / Tagihan).
• Domain entities: product category, game title, currency prop, flash-sale offer, recent transaction ticker entry.
• Component responsibilities: full-bleed hero scene with headline, capsule CTA, live ticker, and real-time 3D kiosk with orbiting props; horizontally scrollable category rail of colour-coded capsule chips with snap points; product grid of flat colour-block tiles with monogram, cheapest denomination, and "Mulai dari Rp…"; membership-tier ladder drawn as four stacked toy blocks; reseller panel styled as a HUD console; edge-to-edge flash-sale marquee.
• States: loading (hero scene and catalogue tiles resolving); empty (no flash sale currently active, no recent transactions to ticker); success (catalogue and hero rendered); error (catalogue fetch fails — retry affordance, hero remains usable); recovery (retry restores catalogue; reduced-motion users get a static hero pose and a scrollable flash-sale row).

Login

• Information/state: anonymous verification surface for Pembeli / Pelanggan, Reseller, and Pemilik / Admin Operasional returning to protected data and activity.
• Primary actions: submit credentials to verify identity and continue to protected access.
• Supporting actions: move to Sign Up if no identity exists yet; return to Landing.
• Domain entities: account identity, session.
• Component responsibilities: credential form; submit control; link to Sign Up; error messaging region.
• States: loading (verification in progress); empty (form untouched); success (verified, redirected to the protected destination the actor was seeking); error (invalid credentials — inline message, form retained, no protected state exposed); recovery (retry, or switch to Sign Up).

Sign Up

• Information/state: anonymous self-service registration for Pembeli / Pelanggan and Reseller. Admin does not self-register here.
• Primary actions: submit registration details to establish an application-owned identity.
• Supporting actions: move to Login; return to Landing.
• Domain entities: account identity, role selection (customer or reseller), contact details used for WhatsApp notification.
• Component responsibilities: registration form; role selection between customer and reseller; submit control; link to Login; validation and error region.
• States: loading (submission in progress); empty (form untouched); success (identity established, moved to verified access); error (validation failure or duplicate identity — inline message, entered data retained); recovery (correct and resubmit, or go to Login if an identity already exists).

Catalog

• Information/state: the full product and service catalogue across Top Up Game, Pulsa & Paket Data, E-Wallet & Saldo, and Tagihan & Lainnya, including the continuously growing set of additional game products.
• Primary actions: select a product to open its details.
• Supporting actions: filter and browse by category; search by product name; move through the category rail.
• Domain entities: product, product category, game title, denomination/variant, cheapest denomination, membership-adjusted price.
• Component responsibilities: category rail; product grid of flat colour-block tiles with monogram, name, cheapest denomination, and "Mulai dari Rp…"; search and filter controls; tile hover tilt with rising low-poly currency prop.
• States: loading (skeleton tiles); empty (no products match the filter or search — clear-filter affordance); success (grid rendered with membership-adjusted prices); error (catalogue fetch fails — retry affordance); recovery (retry or clear filters restores the grid).

Product Details

• Information/state: the selected product with its available denominations or variants, the membership-adjusted price for the actor's level, and any active flash-sale or promo price.
• Primary actions: choose a denomination or variant and proceed to Checkout.
• Supporting actions: enter the destination account/identifier required for fulfilment; apply an available promo; return to Catalog.
• Domain entities: product, denomination/variant, destination account identifier, membership level, price, flash-sale offer.
• Component responsibilities: denomination/variant selector; destination identifier input; price display with Rp prefix; membership price-difference indicator; proceed-to-checkout control.
• States: loading (denominations resolving); empty (product has no available denomination — message and return to Catalog); success (denomination selected, price shown, ready to proceed); error (invalid destination identifier or unavailable denomination — inline message); recovery (correct the identifier or pick another denomination).

Checkout

• Information/state: the order summary (product, denomination, destination identifier, price, applied discount/promo, flash-sale price if applicable), the available automated payment methods, and the wallet balance option.
• Primary actions: confirm the purchase and trigger automated payment.
• Supporting actions: choose among the multiple payment methods; pay from wallet balance; apply or remove a discount code/promo; review the refund guarantee condition.
• Domain entities: order, payment method, wallet balance, discount code, promo, flash-sale price, membership level, refund guarantee.
• Component responsibilities: order summary; payment-method selector; wallet-balance option; discount/promo input; confirm control; refund-guarantee notice stating it applies only to failed transactions.
• States: loading (payment methods and balance resolving); empty (no payment method available — message); success (payment confirmed, order handed to automated 24-hour fulfilment, confirmation shown); error (payment fails or balance insufficient — inline message, order not fulfilled); recovery (retry with another method, top up the wallet, or abandon and return to Catalog).

Wallet

• Information/state: the actor's current balance and the automated deposit history that funds transactions.
• Primary actions: initiate an automated balance deposit.
• Supporting actions: choose a deposit amount and payment method; review deposit history; return to Checkout to use the balance.
• Domain entities: wallet balance, deposit, payment method, deposit status.
• Component responsibilities: balance display; deposit form with amount and method; deposit history list; status indicators.
• States: loading (balance and history resolving); empty (no deposits yet — explanatory message); success (deposit completed automatically, balance updated); error (deposit fails — inline message, balance unchanged); recovery (retry deposit or use a direct payment method at Checkout).

Promotions

• Information/state: the available discount codes and promos, their conditions, and their validity.
• Primary actions: obtain a discount code or promo for use at Checkout.
• Supporting actions: browse active promos; copy a code; return to Checkout to apply it.
• Domain entities: discount code, promo, validity, applicable products.
• Component responsibilities: promo list; code display with copy affordance; validity and condition labels.
• States: loading (promos resolving); empty (no active promos — message); success (promos listed); error (fetch fails — retry affordance); recovery (retry restores the list).

Flash Sale

• Information/state: the daily flash-sale offers, their discounted prices, and their remaining availability.
• Primary actions: select a flash-sale offer and proceed to its Product Details or Checkout.
• Supporting actions: browse the flash-sale strip; return to Catalog.
• Domain entities: flash-sale offer, product, denomination, flash-sale price, availability.
• Component responsibilities: flash-sale marquee/strip; offer tiles with flash-sale price; countdown or availability indicator.
• States: loading (offers resolving); empty (no flash sale active at this moment — message, since flash sales run daily but not every instant); success (offers listed with discounted prices); error (fetch fails — retry affordance); recovery (retry restores offers; reduced-motion users get a scrollable row).

Transactions

• Information/state: the complete transaction history with status for every recorded transaction, including the stamped "BERHASIL" badge on successful top-ups.
• Primary actions: open a transaction to see its detail and current status.
• Supporting actions: filter by status or date; proceed to Reviews for a completed transaction; proceed to Refunds for a failed transaction.
• Domain entities: transaction, status, product, denomination, destination identifier, amount paid, timestamp, success stamp.
• Component responsibilities: transaction list; status indicators; detail view; links to Reviews and Refunds.
• States: loading (history resolving); empty (no transactions yet — explanatory message); success (history listed with statuses); error (fetch fails — retry affordance); recovery (retry restores history).

Reports

• Information/state: real-time sales reports for Reseller and Pemilik / Admin Operasional, showing sales as they occur.
• Primary actions: review real-time sales figures.
• Supporting actions: filter by period or product; for resellers, review resale margin; for admin, monitor operational throughput.
• Domain entities: sale, revenue, product, period, reseller margin.
• Component responsibilities: real-time sales figures; period/product filters; margin view for resellers; operational view for admin.
• States: loading (report resolving); empty (no sales in the selected period — message); success (report rendered with current figures); error (fetch fails — retry affordance); recovery (retry restores the report).

Reseller

• Information/state: the reseller's workspace for the reseller program — reseller standing, reseller pricing, and the tools to transact on behalf of buyers.
• Primary actions: perform a transaction on behalf of a buyer at reseller pricing.
• Supporting actions: review reseller pricing and membership level; apply discount codes/promos; move to Reports to monitor resale performance.
• Domain entities: reseller standing, reseller price, membership level, buyer transaction.
• Component responsibilities: reseller status panel styled as a HUD console; reseller pricing display; transaction-on-behalf control; link to Reports.
• States: loading (reseller data resolving); empty (no reseller activity yet — explanatory message); success (reseller workspace rendered with pricing); error (fetch fails — retry affordance); recovery (retry restores the workspace).

Reviews

• Information/state: the actor's completed transactions available for review, and the reviews and ratings already given.
• Primary actions: submit a review and rating for a completed transaction.
• Supporting actions: view existing reviews and ratings; return to Transactions.
• Domain entities: review, rating, transaction, product.
• Component responsibilities: reviewable-transaction list; rating control; review text input; submit control; existing review display.
• States: loading (reviewable transactions resolving); empty (no completed transaction available to review — message); success (review and rating recorded and displayed); error (submission fails — inline message, input retained); recovery (retry submission).

Refunds

• Information/state: the actor's failed transactions that are eligible for the refund guarantee, and the status of refund claims already made. Only failed transactions appear here.
• Primary actions: submit a refund claim for a failed transaction under the refund guarantee.
• Supporting actions: review claim status; return to Transactions.
• Domain entities: failed transaction, refund claim, claim status, refund guarantee.
• Component responsibilities: eligible-failed-transaction list; claim submission control; claim status display; notice that the guarantee applies only to failed transactions.
• States: loading (eligible transactions resolving); empty (no failed transaction eligible for refund — message); success (claim submitted, status shown); error (submission fails — inline message); recovery (retry submission).

Catalog Admin

• Information/state: the operational catalogue of products and services, including the continuously growing set of additional products.
• Primary actions: add, edit, or remove catalogue products and their denominations/variants.
• Supporting actions: assign products to categories; set the cheapest denomination shown on tiles; review the full catalogue.
• Domain entities: product, product category, denomination/variant, availability.
• Component responsibilities: catalogue table/list; product editor; denomination editor; category assignment; save and remove controls.
• States: loading (catalogue resolving); empty (no products — add affordance); success (change saved and reflected in the catalogue); error (save fails — inline message, edits retained); recovery (retry save).

Membership

• Information/state: the membership levels Member, Basic, Gold, and Platinum, and the price granted at each level.
• Primary actions: configure membership levels and the lower price granted per level.
• Supporting actions: review which level applies to which account; adjust the price ladder.
• Domain entities: membership level (Member, Basic, Gold, Platinum), level price, account level assignment.
• Component responsibilities: level ladder editor; per-level price configuration; account level assignment; save control.
• States: loading (levels resolving); empty (no levels configured — configure affordance); success (level and price changes saved); error (save fails — inline message, edits retained); recovery (retry save).

Promotions Admin

• Information/state: the discount codes and promos currently configured, with their conditions and validity.
• Primary actions: create, edit, or deactivate discount codes and promos.
• Supporting actions: set conditions and validity; review active and inactive promos.
• Domain entities: discount code, promo, condition, validity.
• Component responsibilities: promo list; promo editor; code generator; activate/deactivate control.
• States: loading (promos resolving); empty (no promos configured — create affordance); success (promo saved and reflected); error (save fails — inline message, edits retained); recovery (retry save).

Flash Sale Admin

• Information/state: the flash sales that run every day, with their offers, discounted prices, and scheduling.
• Primary actions: create, edit, or end a daily flash sale and its offers.
• Supporting actions: set flash-sale prices and availability; review past and current flash sales.
• Domain entities: flash sale, offer, product, denomination, flash-sale price, schedule.
• Component responsibilities: flash-sale list; offer editor; price and availability controls; schedule control.
• States: loading (flash sales resolving); empty (no flash sale configured — create affordance); success (flash sale saved and live); error (save fails — inline message, edits retained); recovery (retry save).

Refund Admin

• Information/state: refund claims raised under the refund guarantee, each tied to a failed transaction.
• Primary actions: process a refund claim for a failed transaction.
• Supporting actions: review claim detail and the underlying failed transaction; mark a claim processed; review processed claims.
• Domain entities: refund claim, failed transaction, claim status, refund amount.
• Component responsibilities: claim queue; claim detail; process control; status display; notice that the guarantee applies only to failed transactions.
• States: loading (claims resolving); empty (no refund claims pending — message); success (claim processed and status updated); error (processing fails — inline message, claim retained); recovery (retry processing).

3. Functional Requirements

Each requirement is a distinct story point with provenance and observable acceptance.

FR-01 — Game top-up catalogue (explicit) As a Pembeli / Pelanggan or Reseller, I should be able to browse game top-up products for Mobile Legends: Bang Bang (Diamond, Starlight, Weekly Pass), Free Fire (Diamond, Membership, Token, Bundle), PUBG Mobile (UC, Royale Pass, Item), Valorant (Valorant Point, Battle Pass), Genshin Impact (Genesis Crystal, Blessing), Honkai: Star Rail (Oneiric Shard, Express Pass), Zenless Zone Zero (Polychrome, Bangboo Pass), Roblox (Robux), Call of Duty Mobile (CP, Battle Pass), Farlight 84 (Octane, Pass), Blood Strike (Credits, Pass), Delta Force (Credits, Pass), Super Sus (Coins, Pass), Higgs Domino (Koin Emas), Ragnarok Origin (Crystal, Pass), Tower of Fantasy (Tanium, Dark Crystal), and Cookie Run Kingdom (Crystals, Pass), so that I can find the exact currency or pass I want to buy. Acceptance: every named title and every named item appears in the catalogue under Top Up Game. Failure/recovery: if the catalogue fails to load, a retry affordance restores it. Continuation: selecting a title opens its Product Details.

FR-02 — Continuously growing game catalogue (explicit) As a Pemilik / Admin Operasional, I should be able to add additional game products beyond the named titles ("Lainnya terus bertambah!"), so that the catalogue keeps growing. Acceptance: a newly added game product appears in the catalogue alongside the named titles. Failure/recovery: a failed save retains the edits for retry. Continuation: the new product is immediately purchasable.

FR-03 — Pulsa & paket data catalogue (explicit) As a Pembeli / Pelanggan or Reseller, I should be able to browse pulsa and internet package services for Telkomsel, XL / Axis, Indosat, Tri (3), and Smartfren, so that I can buy pulsa or a data package for any of those operators. Acceptance: all five operators appear with both Pulsa and Paket Internet. Failure/recovery: catalogue load failure offers retry. Continuation: selecting an operator opens its Product Details.

FR-04 — E-wallet & saldo catalogue (explicit) As a Pembeli / Pelanggan or Reseller, I should be able to browse e-wallet and balance services for DANA, OVO, GoPay, ShopeePay, LinkAja, Saldo Google Play, and Saldo Apple, so that I can top up any of those balances. Acceptance: all seven items appear under E-Wallet & Saldo. Failure/recovery: catalogue load failure offers retry. Continuation: selecting an item opens its Product Details.

FR-05 — Tagihan & lainnya catalogue (explicit) As a Pembeli / Pelanggan or Reseller, I should be able to browse Token Listrik PLN, Pembayaran Tagihan Listrik, and Voucher Game Digital, so that I can pay bills and buy digital vouchers. Acceptance: all three items appear under Tagihan & Lainnya. Failure/recovery: catalogue load failure offers retry. Continuation: selecting an item opens its Product Details.

FR-06 — Denomination and variant selection (explicit) As a Pembeli / Pelanggan or Reseller, I should be able to choose the denomination or variant of the selected product and enter the destination account identifier, so that the top-up reaches the correct account. Acceptance: the chosen denomination and destination identifier are carried into Checkout. Failure/recovery: an invalid destination identifier produces an inline message and blocks progression. Continuation: the actor proceeds to Checkout.

FR-07 — Automated 24-hour transaction (explicit) As a Pembeli / Pelanggan or Reseller, I should have my transaction processed automatically 24 hours a day, so that I receive my purchase without waiting for manual handling. Acceptance: a confirmed order is fulfilled automatically and its status becomes successful without human intervention. Failure/recovery: if automated fulfilment fails, the transaction is recorded as failed and becomes eligible for the refund guarantee. Continuation: the result is visible in Transactions.

FR-08 — Automated payment with multiple methods (explicit) As a Pembeli / Pelanggan or Reseller, I should be able to pay automatically through a range of payment methods, so that I can complete a purchase with the method I prefer. Acceptance: more than one payment method is offered at Checkout and a confirmed payment completes automatically. Failure/recovery: a failed payment leaves the order unfulfilled and offers retry with another method. Continuation: successful payment hands the order to automated fulfilment.

FR-09 — Automated balance deposit (explicit) As a Pembeli / Pelanggan or Reseller, I should be able to deposit balance automatically into my wallet, so that I can fund transactions from that balance. Acceptance: a deposit completes automatically and the wallet balance increases. Failure/recovery: a failed deposit leaves the balance unchanged and offers retry. Continuation: the balance is usable at Checkout.

FR-10 — Automated WhatsApp notification (explicit) As a Pembeli / Pelanggan or Reseller, I should receive automated WhatsApp notifications about my transactions, so that I know the outcome without checking the app. Acceptance: a transaction outcome triggers an automated WhatsApp message to the actor's registered contact. Failure/recovery: if notification delivery fails, the transaction status remains authoritative in Transactions. Continuation: the actor can always confirm the outcome in Transactions.

FR-11 — Complete transaction history (explicit) As a Pembeli / Pelanggan or Reseller, I should be able to review my complete transaction history with statuses, so that I can track every purchase I have made. Acceptance: every recorded transaction appears with its status. Failure/recovery: history load failure offers retry. Continuation: a completed transaction can be reviewed; a failed transaction can be claimed for refund.

FR-12 — Real-time sales reports (explicit) As a Reseller or Pemilik / Admin Operasional, I should be able to view real-time sales reports, so that I can monitor sales as they happen. Acceptance: sales figures update as sales occur. Failure/recovery: report load failure offers retry. Continuation: the reseller uses the report to judge resale margin; the admin uses it to monitor operations.

FR-13 — Membership levels (explicit) As a Pemilik / Admin Operasional, I should be able to configure the membership levels Member, Basic, Gold, and Platinum, so that accounts are placed on the correct level. Acceptance: all four levels exist and are assignable to accounts. Failure/recovery: a failed save retains edits for retry. Continuation: the level determines the price the account sees.

FR-14 — Lower prices by membership level (explicit, hard constraint) As a Pembeli / Pelanggan or Reseller, I should see lower prices according to my membership level (Member, Basic, Gold, Platinum), so that my level gives me a real price advantage. Acceptance: the price shown for a product reflects the actor's membership level, and a higher level yields a lower price. Failure/recovery: if the level cannot be resolved, the standard price is shown rather than an incorrect discount. Continuation: the level-adjusted price is carried into Checkout.

FR-15 — Reseller program (explicit) As a Reseller, I should be able to participate in the reseller program and transact on behalf of buyers at reseller pricing, so that I can resell products to my own customers. Acceptance: a reseller can complete a transaction on behalf of a buyer and it is recorded under the reseller's activity. Failure/recovery: a failed reseller transaction is recorded as failed and is eligible for the refund guarantee. Continuation: the resale appears in Reports.

FR-16 — Discount codes and promos (explicit) As a Pembeli / Pelanggan or Reseller, I should be able to apply discount codes and promos to a transaction, so that I pay less. Acceptance: a valid code or promo reduces the amount payable at Checkout. Failure/recovery: an invalid or expired code produces an inline message and the original price stands. Continuation: the discounted amount is carried into payment.

FR-17 — Daily flash sale (explicit, hard constraint) As a Pembeli / Pelanggan or Reseller, I should be able to find and use flash sales that run every day, so that I can buy at flash-sale prices. Acceptance: flash-sale offers appear daily with discounted prices and can be purchased. Failure/recovery: if no flash sale is active at a given moment, the surface states so rather than showing stale offers. Continuation: a selected flash-sale offer proceeds to its Product Details or Checkout.

FR-18 — Customer reviews and ratings (explicit) As a Pembeli / Pelanggan, I should be able to give a review and rating after a transaction, so that I can share my experience of the product. Acceptance: a review and rating submitted for a completed transaction is recorded and displayed. Failure/recovery: a failed submission retains the input for retry. Continuation: the review remains visible against the transaction.

FR-19 — Refund guarantee for failed transactions (explicit, hard constraint) As a Pembeli / Pelanggan or Reseller, I should be able to claim a refund under the guarantee when a transaction fails, so that I do not lose money on a failed purchase. Acceptance: a refund claim can be raised only for a transaction whose status is failed, and the claim is processed. Failure/recovery: a claim submission failure retains the claim for retry. Continuation: the claim status is visible in Refunds. Bound: the guarantee applies only to failed transactions; it does not extend to successful transactions.

FR-20 — Self-service registration (required_inference) As a Pembeli / Pelanggan or Reseller, I should be able to register myself before using protected transactions, so that my purchases, balance, and history are bound to me. Acceptance: a new identity can be established through Sign Up and then used to access protected state. Failure/recovery: validation failure or a duplicate identity produces an inline message with entered data retained. Continuation: the actor proceeds to verified access.

FR-21 — Returning verification (required_inference) As a Pembeli / Pelanggan, Reseller, or Pemilik / Admin Operasional, I should verify myself again through Login to continue to my stored data and activity, so that my wallet, history, and operational state remain mine. Acceptance: verified credentials grant access to the actor's protected destinations; unverified attempts expose no protected state. Failure/recovery: invalid credentials produce an inline message with the form retained. Continuation: the actor reaches the protected destination it was seeking.

FR-22 — Admin provisioning (required_inference) As a Pemilik / Admin Operasional, I should receive access through internal provisioning or invitation before operational management is available, so that operational control is not self-granted. Acceptance: operational management surfaces are reachable only by a provisioned admin identity. Failure/recovery: an unprovisioned attempt is refused without exposing operational state. Continuation: the provisioned admin reaches Catalog Admin, Membership, Promotions Admin, Flash Sale Admin, and Refund Admin.

FR-23 — Backend automation of payment, fulfilment, deposit, and notification (required_inference) As the rapid-top platform, I should run payment processing, 24-hour automated transaction fulfilment, automated balance deposit, and automated WhatsApp notification as backend processes, so that the accepted automated behaviour happens without manual handling. Acceptance: each of these processes executes automatically and its outcome is reflected in the actor-visible state (transaction status, wallet balance, notification). Failure/recovery: a failed process leaves the corresponding actor-visible state truthful (failed transaction, unchanged balance) and eligible for the accepted recovery path. Continuation: the actor-visible outcome is available in Transactions, Wallet, or the WhatsApp message.

FR-24 — Refund processing limited to failed transactions (required_inference) As a Pemilik / Admin Operasional, I should process refund claims only for transactions that failed, so that the refund guarantee is honoured exactly as scoped. Acceptance: only failed transactions appear in the refund claim queue and only those can be processed. Failure/recovery: a processing failure retains the claim for retry. Continuation: the processed claim status is visible to the claimant in Refunds.

4. User Personas

Pembeli / Pelanggan (Buyer / Customer)

Product context. An Indonesian gamer or everyday buyer who comes to rapid-top to buy game currency and passes, pulsa and data packages, e-wallet balances, or to pay PLN electricity tokens and bills. They arrive from the public Landing surface, often on a phone, and expect the purchase to feel like opening a loot crate rather than filling a form.

Primary goal. Get the exact currency, package, or bill paid quickly, at the best price their membership level allows, with the outcome confirmed automatically.

Distinct accepted responsibilities. Choosing a product and its denomination or variant; entering the destination account identifier; paying through one of the automated payment methods or from wallet balance; depositing balance automatically when they want to fund from wallet; applying a discount code or promo; catching a daily flash-sale offer; monitoring transaction status; reviewing their complete transaction history; giving a review and rating after a transaction; claiming a refund under the guarantee when a transaction fails.

Relevant inputs and decisions. Which product and denomination; which destination account; which payment method or wallet balance; whether to apply a code or promo; whether to buy now or wait for a flash sale; whether to review; whether to claim a refund.

Interactions with other accepted participants. The customer's purchase is fulfilled by the platform's automated backend and confirmed by automated WhatsApp notification. When a transaction fails, the customer's refund claim is handled by the Pemilik / Admin Operasional in Refund Admin. The customer's review and rating become visible against the transaction.

Observable success. The order is delivered automatically, the transaction appears in Transactions with a successful status and a stamped "BERHASIL" badge, the WhatsApp notification arrives, and — if the transaction failed — the refund claim is processed.

What makes this role different. The customer is the only role that consumes the catalogue as an end buyer, the only role that gives reviews and ratings, and the only role whose refund claims are raised purely on their own behalf.

Reseller

Product context. A partner who joins the reseller program and resells rapid-top's products and services to their own customers, using reseller pricing and their membership level (Member, Basic, Gold, Platinum) to earn a margin.

Primary goal. Complete transactions on behalf of buyers at reseller pricing and see the resale margin clearly in real-time sales reports.

Distinct accepted responsibilities. Performing transactions on behalf of buyers; using reseller pricing and membership-level pricing; applying discount codes and promos to resale transactions; monitoring real-time sales reports to judge margin; claiming refunds under the guarantee when a resale transaction fails.

Relevant inputs and decisions. Which product and denomination to resell; the buyer's destination account; which price applies at the reseller's level; whether to apply a code or promo; whether a failed resale warrants a refund claim.

Interactions with other accepted participants. The reseller transacts on behalf of buyers who are not themselves users of the product; fulfilment and WhatsApp notification are handled by the platform's automated backend; failed resale transactions are handled by the Pemilik / Admin Operasional in Refund Admin; the reseller's sales appear in the same real-time reporting surface the admin monitors.

Observable success. The resale transaction is recorded, the margin is visible in Reports, and any failed resale is refunded under the guarantee.

What makes this role different. The reseller is the only role that transacts on behalf of third parties and the only role whose primary success measure is margin rather than the goods received. The reseller shares the Reports surface with the admin but reads it for a different purpose.

Pemilik / Admin Operasional (Owner / Operational Admin)

Product context. The operator of rapid-top, responsible for keeping the automated service running and the catalogue current.

Primary goal. Keep every transaction completing automatically and keep the sales reports accurate, while managing the catalogue, membership pricing, promotions, flash sales, and refunds.

Distinct accepted responsibilities. Monitoring real-time sales reports; managing the catalogue of products and services as it continuously grows; configuring membership levels Member, Basic, Gold, and Platinum and the lower price granted at each level; managing the reseller program; managing discount codes and promos; managing the daily flash sale; processing refund claims for failed transactions; ensuring automated 24-hour transactions, automated balance deposit, and automated WhatsApp notification operate.

Relevant inputs and decisions. Which products to add or change; what price each membership level grants; which promos and flash sales to run; which refund claims to process; whether the automated pipeline is behaving.

Interactions with other accepted participants. The admin's catalogue, membership, promo, and flash-sale configuration determines what customers and resellers see and pay. The admin processes the refund claims raised by customers and resellers. The admin's operational monitoring shares the Reports surface with resellers.

Observable success. All transactions complete automatically, the sales report is accurate, the catalogue reflects the current product set, and every eligible refund claim is processed.

What makes this role different. The admin is the only role that configures the product rather than consuming it, the only role that processes refunds rather than claiming them, and the only role whose access is provisioned rather than self-registered.

5. Core User Flows

Flow 1 — Customer discovers the catalogue and buys a game top-up

1. Starting context: an unauthenticated visitor opens the Landing page.
2. The visitor reads the headline and the explanation of the catalogue, automated payment methods, and service benefits, and sees the live transaction ticker and the daily flash-sale strip.
3. The visitor drags horizontally across the hero's low-poly kiosk scene to rotate the camera, or clicks an orbiting currency prop (diamond, coin, crystal, UC) to jump straight to that game's top-up page.
4. The visitor moves through the colour-coded category rail to Top Up Game and selects a title, for example Mobile Legends: Bang Bang.
5. Result: the Catalog shows the game's tiles with the cheapest denomination and "Mulai dari Rp…".
6. The visitor opens Product Details for that title and chooses a denomination — Diamond, Starlight, or Weekly Pass — and enters the destination account identifier.
7. Result: the chosen denomination, destination identifier, and the membership-adjusted price are shown, ready to proceed.
8. The visitor proceeds to Checkout, reviews the order summary, and chooses one of the automated payment methods (or wallet balance).
9. The visitor confirms the purchase.
10. Result: automated payment completes, the order is handed to automated 24-hour fulfilment, and the confirmation is shown.
11. Failure/recovery: if payment fails or the wallet balance is insufficient, an inline message appears, the order is not fulfilled, and the visitor can retry with another method, top up the wallet, or return to the Catalog.
12. Continuation: the visitor opens Transactions and sees the transaction with its status; a successful top-up carries the stamped "BERHASIL" badge. An automated WhatsApp notification confirms the outcome.

Flow 2 — Customer funds a wallet and pays from balance

1. Starting context: a verified customer is in the protected area.
2. The customer opens Wallet and sees the current balance and deposit history.
3. The customer initiates an automated balance deposit, choosing an amount and a payment method.
4. Result: the deposit completes automatically and the balance increases.
5. Failure/recovery: if the deposit fails, an inline message appears, the balance is unchanged, and the customer can retry or instead pay directly at Checkout.
6. Continuation: the customer returns to Checkout and pays for the order from the wallet balance.

Flow 3 — Customer applies a discount code or catches a flash sale

1. Starting context: a verified customer is choosing what to buy.
2. The customer opens Promotions, browses the active discount codes and promos, and copies a code.
3. Alternatively, the customer opens Flash Sale and selects a daily flash-sale offer, which proceeds to its Product Details or Checkout.
4. At Checkout, the customer applies the code or promo.
5. Result: the amount payable is reduced and the discounted amount is carried into payment.
6. Failure/recovery: if the code is invalid or expired, an inline message appears and the original price stands; the customer can try another code or continue at the original price.
7. Continuation: the customer confirms and pays.

Flow 4 — Customer reviews a completed transaction

1. Starting context: a verified customer has a completed transaction in Transactions.
2. The customer opens Reviews and sees the completed transactions available to review.
3. The customer selects a transaction, sets a rating, and writes a review.
4. Result: the review and rating are recorded and displayed against the transaction.
5. Failure/recovery: if the submission fails, an inline message appears and the input is retained for retry.
6. Continuation: the review remains visible; the customer returns to Transactions.

Flow 5 — Customer claims a refund for a failed transaction

1. Starting context: a verified customer has a transaction whose status is failed.
2. The customer opens Refunds and sees only the failed transactions eligible under the refund guarantee.
3. The customer selects the failed transaction and submits a refund claim.
4. Result: the claim is submitted and its status is shown.
5. Failure/recovery: if the submission fails, an inline message appears and the claim is retained for retry.
6. Continuation: the claim is handled by the Pemilik / Admin Operasional in Refund Admin (Flow 9), and the customer sees the updated claim status in Refunds.

Flow 6 — Reseller transacts on behalf of a buyer

1. Starting context: a verified reseller is in the protected area.
2. The reseller opens Reseller and sees their reseller standing and reseller pricing at their membership level.
3. The reseller selects a product and denomination and enters the buyer's destination account identifier.
4. The reseller optionally applies a discount code or promo, then proceeds to Checkout and confirms.
5. Result: the resale transaction is recorded under the reseller's activity and fulfilled automatically.
6. Failure/recovery: if the resale transaction fails, it is recorded as failed and the reseller can raise a refund claim in Refunds.
7. Continuation: the reseller opens Reports and sees the resale reflected in the real-time sales figures with the margin.

Flow 7 — Reseller monitors real-time sales

1. Starting context: a verified reseller has completed resale transactions.
2. The reseller opens Reports.
3. The reseller reviews the real-time sales figures and filters by period or product.
4. Result: current sales and the resale margin are visible as they occur.
5. Failure/recovery: if the report fails to load, a retry affordance restores it.
6. Continuation: the reseller adjusts what they resell based on the margin shown.

Flow 8 — Admin manages the catalogue, membership, promotions, and flash sales

1. Starting context: a provisioned admin verifies through Login and reaches the operational area.
2. The admin opens Catalog Admin and adds, edits, or removes products and their denominations, including new game titles as the catalogue grows.
3. Result: the change is saved and reflected in the catalogue that customers and resellers see.
4. Failure/recovery: if the save fails, an inline message appears and the edits are retained for retry.
5. The admin opens Membership and configures the levels Member, Basic, Gold, and Platinum and the lower price granted at each level.
6. Result: accounts on a higher level see lower prices.
7. The admin opens Promotions Admin and creates, edits, or deactivates discount codes and promos.
8. The admin opens Flash Sale Admin and creates, edits, or ends the daily flash sale and its offers.
9. Result: the flash sale runs daily with its discounted prices.
10. Continuation: the admin opens Reports to monitor the effect in real time.

Flow 9 — Admin processes a refund claim for a failed transaction

1. Starting context: a provisioned admin is in the operational area and a refund claim exists from a failed transaction.
2. The admin opens Refund Admin and sees the claim queue, each claim tied to a failed transaction.
3. The admin reviews the claim detail and the underlying failed transaction.
4. The admin processes the claim.
5. Result: the claim status is updated and the refund is honoured under the guarantee.
6. Failure/recovery: if processing fails, an inline message appears and the claim is retained for retry.
7. Continuation: the claimant sees the updated status in Refunds.

Flow 10 — Customer or reseller establishes and verifies identity

1. Starting context: an unauthenticated visitor on the Landing page wants protected access.
2. The visitor proceeds to Sign Up and submits registration details, choosing customer or reseller.
3. Result: an application-owned identity is established and the actor moves to verified access.
4. Failure/recovery: if validation fails or the identity already exists, an inline message appears with the entered data retained; the actor can correct and resubmit or go to Login.
5. Continuation: on a later visit, the actor opens Login, submits credentials, and is verified.
6. Result: the actor reaches the protected destination it was seeking — Catalog, Wallet, Transactions, Reseller, or Reports.
7. Failure/recovery: invalid credentials produce an inline message with the form retained and no protected state exposed.
8. Admin variant: the Pemilik / Admin Operasional does not self-register; access is granted through internal provisioning or invitation, after which the admin verifies through Login to reach Catalog Admin, Membership, Promotions Admin, Flash Sale Admin, and Refund Admin.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. The muse is Bruno Simon: a bright low-poly world you physically explore, with toy physics and a minimal HUD. The headline idea is "Playable worlds for a top-up marketplace: a toy-box 3D storefront you can drive through."

Mode. Dark mode only. Never white-first; white appears only as text and as 1px HUD strokes.

Colour tokens by role.

Coral #FF5C3E is the action colour and is used on at most one element per viewport. Lemon #FFD23F is the currency/price and flash-sale signal. Body text #FFF8EC on #1B1440 is approximately 14.6:1. Muted #9A8FD6 is reserved for non-essential labels at 14px and above only.

Typography. Headings: Fredoka SemiBold/Bold at very large sizes with -0.02em tracking and near-1.0 line-height, set in sentence case (never all-caps), so it reads as a toy-box label rather than a poster. Numbers and prices get Fredoka Bold tabular-ish treatment with the Rp prefix at 0.6em size in muted colour. Body: Baloo 2. Scale: 1.333 modular, 1.25 for UI.

Shape language. Rounded toy geometry: 20–28px radii on cards, 999px capsule buttons and category chips, floating low-poly 3D props (faceted diamond, coin, crystal shard, UC hexagon) with flat-shaded faces and soft contact shadows. Cards sit on a visible 2px darker outline like plastic toy parts rather than drop-shadowed glass. Section boundaries are soft curves that dip and rise, and a thin dashed "circuit" line runs between category blocks like a play mat.

Spacing rhythm. A play-mat grid with generous ground between blocks; raised panels use a 1px #6F5BD6 inner glow instead of a drop shadow.

Imagery style. Low-poly 3D objects and environments rendered in-browser: a floating kiosk/pad, faceted gemstones for each game currency, a low-poly phone for pulsa, a low-poly wallet for e-wallet, a bolt for PLN. No stock photography, no glassmorphism, no gradient blobs. Game titles are represented by flat colour-block tiles with a bold monogram or icon, never by copyrighted key art. An optional tiny 3D character mascot (a rounded delivery bot) idles in the corner and reacts to cart additions.

Explicitly avoided: blue/indigo primary on a white ground; glassmorphism, frosted panels, and gradient blobs; Inter, Roboto, Arial, Poppins, system-ui, or any neutral grotesque for headings or body; a centred hero headline + subtext + button composition; a grid of identical hover-lift cards with drop shadows; real copyrighted game key art, logos, or character renders; photorealistic stock photography of people holding phones; heavy WebGL on the product grid.

7. Signature Design Concept

The play-mat kiosk. The public entry is a full-bleed dark-indigo play-mat scene, not a centred headline stack. On the left five columns sits an oversized Fredoka headline "Top Up, Tanpa Nunggu" at clamp(44px, 7vw, 96px) in #FFF8EC, with the words "Tanpa Nunggu" in coral #FF5C3E, sitting directly on the ground with no card behind it. Pinned beneath it is a capsule CTA "Top Up Sekarang" in coral with lemon text, and a one-line live ticker of recent transactions in muted #9A8FD6.

The right seven columns is a real-time 3D scene (React Three Fiber) of a low-poly kiosk pad with faceted diamond, coin, crystal, and UC props orbiting above it, lit by two coloured lights — a coral key and a sky fill — with a thin dashed lemon HUD ring and small floating price tags. Dragging horizontally rotates the camera, and each prop is clickable to jump straight to that game's top-up page. A lemon flash-sale strip runs edge-to-edge across the very bottom of the hero as a marquee.

Below the hero, the play-mat continues: a horizontally scrollable category rail of colour-coded capsule chips (mint for game top-up, sky for pulsa & data, hot pink for e-wallet, coral for tagihan) with snap points that re-colours the page's accent stripe as you move through it; a dense but playful 2/3/4-column product grid of flat colour-block tiles with a bold monogram, the cheapest denomination, and "Mulai dari Rp…"; a membership-tier ladder drawn as four stacked toy blocks of increasing height and metallic sheen (Member → Basic → Gold → Platinum) with the price-difference badge clipped to the block edge, so the discount ladder is literally legible as a staircase; and a reseller panel styled as a HUD console.

Every SKU tile keeps its name, price, and CTA fully inside the tile at 375px. The category rail scrolls horizontally with snap points and wraps to two rows under prefers-reduced-motion. No blue button, no gradient blob, no centred SaaS layout.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: cinematic Hero Dimensionality: webgl

Landing Hero Motion Brief

• Focal subject: the low-poly kiosk pad with faceted diamond, coin, crystal, and UC props orbiting above it, lit by a coral key light and a sky fill light, ringed by a thin dashed lemon HUD ring with small floating price tags.
• Input → transformation → outcome thesis: the visitor drags horizontally across the scene → the camera rotates around the kiosk and the orbiting props drift and rotate on their 12s loop → the visitor sees the catalogue as a shelf of toys and can click a prop to jump straight to that game's top-up page. The transformation uses only accepted behaviour: browsing the catalogue and entering a product's top-up page.
• Motion vocabulary: toy physics. Cards and chips scale in with a slight overshoot (cubic-bezier(.34,1.56,.64,1), 220ms); hovering a tile tilts it up to 4deg toward the cursor while a small low-poly prop of that game's currency rises out of the tile; the hero's props drift and rotate slowly on a 12s loop; the flash-sale strip is a continuous marquee at roughly 40px/s that pauses on hover; a successful top-up plays a 600ms burst of low-poly confetti and stamps a lemon "BERHASIL" seal with a slight rotation onto the receipt card, which stays in the transaction history as a small stamped badge.
• Composed first frame: the kiosk pad centred in the right seven columns, props already orbiting at their loop positions, the dashed lemon HUD ring drawn, the coral headline and capsule CTA resting on the ground at left, the live ticker running beneath, and the lemon flash-sale marquee already moving across the bottom edge.
• Reduced-motion state: props hold a static pose, the marquee becomes a scrollable row, and entrance animations become instant opacity swaps. The category rail wraps to two rows so every chip can be brought fully into view.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

A single crafted real-time scene: a low-poly kiosk pad on a deep twilight-indigo ground, with four faceted currency props — a diamond, a coin, a crystal shard, and a UC hexagon — orbiting above it on a slow 12s loop. Two coloured lights define the scene: a coral key light (#FF5C3E) and a sky fill light (#4FB8FF). A thin dashed lemon (#FFD23F) HUD ring encircles the pad, and small floating price tags hover near each prop. The scene shows the product's defining state — a catalogue of game currencies presented as physical toys you can reach into. Dragging horizontally rotates the camera; clicking a prop navigates to that game's top-up page. The 3D budget stays in this hero and one small mascot so 375px devices stay smooth; the product grid remains flat colour blocks.

9. Non-Functional Requirements

• NFR-01 — 24-hour automated availability (explicit): transactions must be processed automatically around the clock, so the service must operate continuously without manual intervention for fulfilment.
• NFR-02 — Automated payment breadth (explicit): the payment layer must support multiple automated payment methods so that a range of methods is genuinely available at Checkout.
• NFR-03 — Automated WhatsApp delivery (explicit): the platform must send automated WhatsApp notifications to the actor's registered contact on transaction outcomes; WhatsApp is an outbound external recipient owned outside rapid-top.
• NFR-04 — Complete and truthful transaction history (explicit): the transaction record must be complete, so that every recorded transaction appears with its status and no transaction is silently dropped.
• NFR-05 — Real-time sales reporting (explicit): sales figures must reflect sales as they occur, so that resellers and the admin see current data rather than a stale batch.
• NFR-06 — Refund guarantee scoping (explicit, hard constraint): the refund guarantee must be enforced so that only failed transactions are eligible for a refund claim and only those can be processed.
• NFR-07 — Membership price integrity (explicit, hard constraint): the price shown must reflect the actor's membership level, and a higher level must yield a lower price; if the level cannot be resolved, the standard price is shown rather than an incorrect discount.
• NFR-08 — Daily flash-sale cadence (explicit, hard constraint): flash sales must run every day.
• NFR-09 — Readable text and controls at every viewport (explicit design constraint): headlines, wordmarks, labels, numbers, card text, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element may cover any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control. Moving and scrollable content (marquees, tickers, carousels, horizontally scrollable rows) may cross the viewport or container edge by design and is judged by whether it actually moves or scrolls and whether every item becomes fully readable as it passes.
• NFR-10 — Reduced-motion usability (explicit design constraint): under prefers-reduced-motion, a usable static arrangement must be provided — props hold a static pose, the marquee becomes a scrollable row, entrance animations become instant opacity swaps, and the category rail wraps to two rows so each item can be brought fully into view.
• NFR-11 — Mobile performance budget (explicit design constraint): heavy WebGL must stay out of the product grid; the 3D budget stays in the hero and one small mascot so 375px devices stay smooth.
• NFR-12 — Identity continuity for protected state (required_inference): wallet balance, transaction history, membership level, reseller standing, reviews, refund claims, and operational management must remain bound to the correct participant, so protected destinations require verified identity and expose no protected state before verification.

10. Tech Stack

• Frontend: React, with React Three Fiber for the real-time WebGL hero scene and the small mascot. The product grid remains flat DOM/CSS colour blocks, not WebGL.
• Backend: Python / FastAPI, owning payment processing, 24-hour automated transaction fulfilment, automated balance deposit, automated WhatsApp notification dispatch, catalogue and pricing, membership levels, promotions, flash sales, reviews, and refunds.
• Storage: a relational database for accounts, catalogue, denominations, orders, transactions, wallet balances and deposits, membership levels and level prices, discount codes and promos, flash sales, reviews and ratings, and refund claims.
• Containerization: Docker and docker-compose for local and single-host deployment.
• Orchestration: Kubernetes only if the deployment requires it; not otherwise.
• External integrations: payment providers for the automated payment methods, game publisher/operator/biller systems for fulfilment, and WhatsApp for outbound notification. These are external services owned outside rapid-top.

11. Assumptions and Constraints

Constraints (binding).

• The refund guarantee applies only if a transaction fails. It is not a general cancellation right and does not extend to successful transactions.
• Lower prices are granted according to membership level (Member, Basic, Gold, Platinum).
• Flash sales run every day.
• The catalogue is limited to the four named families and their named items, plus additional game products that are added continuously.
• WhatsApp is an outbound notification recipient only; it is not a persona and owns no product surface.
• Payment providers, game publishers, operators, and billers are external services owned outside rapid-top.

Assumptions (narrow, labeled).

• Assumption: customers and resellers establish their own identity through Sign Up, and all three roles verify again through Login before reaching protected state. This is required_inference from the accepted need for wallet balance, transaction history, membership level, reseller standing, reviews, and refund claims to remain bound to the correct participant.
• Assumption: admin access is granted through internal provisioning or invitation rather than self-registration. This is required_inference from the accepted need for operational management to be controlled rather than self-granted.
• Assumption: payment processing, 24-hour automated transaction fulfilment, automated balance deposit, and automated WhatsApp notification run as backend processes. This is required_inference from the accepted automated behaviour; the human-facing side of each remains owned by the pages in section 2c.
• Assumption: the destination account identifier required for fulfilment is captured at Product Details and carried into Checkout. This is required_inference from the accepted need for a top-up to reach the correct account.
• Assumption: a flash sale may not be active at every instant even though flash sales run daily; the Flash Sale surface states this rather than showing stale offers.
• Assumption: the reseller transacts on behalf of buyers who are not themselves users of rapid-top; the reseller's own identity carries the transaction.

Defaults — not specified by user.

• [Default — not specified by user] Exact payment provider integrations, game publisher/operator/biller APIs, and the WhatsApp messaging provider are not named in the source; the platform integrates with providers that support the accepted automated behaviour.
• [Default — not specified by user] The precise mechanism by which membership level is assigned to an account is not specified beyond the admin configuring the four levels and the price per level.
• [Default — not specified by user] The precise conditions attached to individual discount codes and promos are not specified beyond the admin creating and managing them.

12. Glossary

• rapid-top — the Indonesian digital top-up marketplace described in this document, operated by Xyz_Games.
• Top Up Game — the catalogue family of game currency and pass products.
• Pulsa & Paket Data — the catalogue family of mobile airtime and internet packages.
• E-Wallet & Saldo — the catalogue family of e-wallet and balance top-ups.
• Tagihan & Lainnya — the catalogue family of bill payments and digital vouchers.
• Denomination / variant — the specific amount or item of a product that a buyer selects (for example a Diamond amount, a Starlight pass, or a data package).
• Destination account identifier — the game account, phone number, or bill identifier that the purchased item is delivered to.
• Automated 24-hour transaction — fulfilment of a confirmed order by the platform's backend without manual handling, at any hour.
• Automated payment — completion of payment through one of the supported payment methods without manual handling.
• Automated balance deposit — completion of a wallet top-up by the platform's backend without manual handling.
• Automated WhatsApp notification — an outbound WhatsApp message sent by the platform on a transaction outcome.
• Wallet — the actor's stored balance, funded by automated deposits and usable at Checkout.
• Membership level — one of Member, Basic, Gold, or Platinum; a higher level grants a lower price.
• Reseller program — the program through which a Reseller resells rapid-top products to their own customers at reseller pricing.
• Discount code / promo — a code or offer that reduces the amount payable at Checkout.
• Flash sale — a discounted offer that runs every day.
• Refund guarantee — the guarantee that a refund is provided when a transaction fails; it applies only to failed transactions.
• Failed transaction — a transaction whose automated fulfilment did not succeed; the only transaction state eligible for the refund guarantee.
• BERHASIL seal — the lemon stamped badge applied to a successful top-up's receipt card and retained in transaction history.
• Pembeli / Pelanggan — the buyer/customer persona.
• Reseller — the reseller persona.
• Pemilik / Admin Operasional — the owner/operational admin persona.