Matrix Gaming Store
A production Laravel store for gaming top-ups with a reseller API, wallet ledger, signed webhooks, and an automated fulfilment worker.
Read as MarkdownArchitecture
Storefront / reseller API → Laravel order service → Wallet ledger + webhook outbox; paid orders → Node.js worker → Fulfilment
Problem
Customers buy gaming top-ups and other digital packages by entering their player details and paying online. Each paid order then has to be fulfilled on a supplier's site, which is repetitive manual work for store staff.
Storefront and order lifecycle
The Laravel application manages products, variants, configurable player-data forms, cart, checkout, and customer order history. Orders move from awaiting payment to processing and then to approved or rejected. Terminal states block further transitions, so a late update cannot reopen a finished order.
Reseller platform
Invite-only partners use live and test API keys with per-scope permissions and separate rate limits for reads, orders, and deposits. Prepaid wallets track available and reserved funds through idempotent ledger entries. Partner webhooks are signed with HMAC and retried from an outbox.
Controlled rollout
Ten reseller features, covering API access, bulk orders, wallets, credit limits, tier pricing, custom pricing, and webhooks, are disabled by default. A super administrator enables them through audited switches. Each feature declares its dependencies, so tier pricing cannot be switched on without tier management.
Automated fulfilment
A separate Node.js worker polls the store for paid orders, claims them, and fulfils each one through Playwright browser automation, then reports the result back. It stops claiming orders when the browser or the supplier session is unavailable, pauses after a failure instead of stranding more paid orders, and sends Telegram alerts. Every bot action is logged with a recovery path.
Evidence and limitations
The store and worker run in production. This note does not publish order volumes, revenue, or fulfilment times. The supplier session needs a one-time manual sign-in, so fulfilment pauses rather than fails silently when that session expires.