Prepaid Gaming Sessions: Payment Before Play Guide

by Editorial Team 51 views
Iklan Headers

Hey guys! Let's dive into how we can revamp our gaming café management system to support a prepaid session workflow. This means customers pay before they play, which aligns perfectly with how things run in the real world. This article walks you through the changes and requirements to get this up and running.

Goals

Our primary goal here is to synchronize our software with the actual way our gaming café operates. Currently, the system assumes payments are made after a gaming session. This needs to change! By implementing a prepaid-first session model, we aim to prevent any potential revenue loss by ensuring payment is recorded before the session even begins. This also allows for better management of planned durations and controlled session starts. Think of it as moving from a 'play now, pay later' system to a 'pay first, play now' setup. This not only secures our revenue but also gives us more control over session management.

New Session Lifecycle

We’re introducing a new, streamlined session lifecycle. Forget the old ways; we're now rocking this flow:

PLANNED → ACTIVE → COMPLETED
  • PLANNED: The session is created, payment is received, but the gaming hasn't started yet.
  • ACTIVE: The session is in full swing; the customer is gaming away.
  • COMPLETED: The session has ended, and the customer is done.

Requirements

Let's break down what we need to make this happen.

1️⃣ Prepaid Session Creation

We need to allow the creation of a session before it officially starts. When creating a session, we need to capture the following details:

  • Customer Name: Who's about to game?
  • System Number: Which gaming rig are they using?
  • Planned Duration (minutes): How long do they plan to play? This is crucial for prepaid sessions.
  • Hourly Rate: What's the cost per hour for using the system?
  • Calculated Total Amount: Based on the planned duration and hourly rate, what's the total cost?
  • Payment Method (Cash / Online): How did they pay? Cash, card, or some other online method?

At this stage, the payment must be marked as PAID. No gaming until we get the green! The session state should be saved as PLANNED.

2️⃣ Start Session Action

We're adding a “Start Session” action or button. This is the gateway to the gaming world! When this button is clicked:

  • Record the login_time. This is the exact moment the session goes live.
  • Transition the session state to ACTIVE. The game is on!

3️⃣ End Session Logic

When the session ends, we need to record some crucial info:

  • Record the logout_time. This is when the session officially ends.
  • Calculate the actual duration using the login_time and logout_time timestamps. How long did they actually play?
  • Compare the actual duration versus the planned duration. Did they play exactly as long as they paid for?

We also need to handle a few scenarios:

  • Ends on Time: The actual duration matches the planned duration. Sweet!
  • Ends Early: The actual duration is less than the planned duration. By default, no refund is given (but we might consider loyalty system).
  • Exceeds Planned Duration: The actual duration is longer than the planned duration. This will be handled in a future update (think session extensions and additional payments).

4️⃣ Database Changes

To support all this new functionality, we need to add a few fields to our database:

  • planned_duration_min: The planned duration of the session in minutes.
  • paid_amount: The amount the customer paid for the session.
  • payment_method: How the customer paid (Cash, Online, etc.).
  • payment_status: The status of the payment (PAID).
  • session_state: The current state of the session (PLANNED / ACTIVE / COMPLETED).

Acceptance Criteria

To ensure we're on the right track, here are the key things we need to be able to do:

  • An operator can create a prepaid session without immediately starting it. This allows for flexibility in managing sessions.
  • Payment is recorded before the gaming begins. This is the core of the prepaid system.
  • The session does not have a login time until it's explicitly started. This ensures accurate tracking of session times.
  • Data persists safely across app restarts. We don't want to lose any data if the app crashes or restarts.
  • The UI clearly distinguishes between PLANNED and ACTIVE sessions. Operators need to easily see the status of each session.

Notes

Keep in mind a couple of things:

  • This initial update does not include session extensions or refunds. These will be addressed in future updates.
  • This lays a solid foundation for crash recovery and session resumption. If a session crashes, we can pick it back up where it left off.
  • Future updates will build on this new lifecycle, adding even more features and functionality.

Priority

🔥 High (Blocking for real-world use)

This is a top priority because it's essential for aligning the software with our actual café operations. Without this, we're potentially losing revenue and not accurately managing our sessions.