Checkout and payment safety
The presenter uses fictional payment successes and declines for demonstration. The customer app must not charge a card until server-owned prices, the correct venue Stripe account, PaymentSheet and signed webhook reconciliation are verified.
No PAN/CVC may be stored in HSLG's MariaDB or application logging. Five independent venue Stripe accounts and cross-account saved-method eligibility are still a product/provider decision.
What 'paid' must mean
The customer should not see a final paid or accepted state until the correct venue's server-side order and payment evidence agree. The WordPress presenter currently illustrates payment outcomes with fictional results. The genuine mobile app has no verified Stripe PaymentSheet or live transaction flow. Its checkout is intentionally disabled until pricing, merchant configuration, provider webhooks and tests are complete.
Planned customer steps
Review the venue, table, products, quantities, total and any charges. Obtain a fresh server quote. Open the provider's native PaymentSheet for the intended venue. Confirm or cancel in the provider interface. The app may show a pending state while the server awaits provider reconciliation; it must not mark an order completed solely because the PaymentSheet view closed. On a decline or cancellation, retain the basket and show a clear next action without inventing a charge.
Card data and saved methods
HSLG must not collect or store raw card numbers or CVC in its own inputs, logs or MariaDB tables. The payment provider handles sensitive entry and supplies approved references. Saved cards raise separate consent and merchant account questions. The user must decide whether a saved payment method is tied to an individual venue or can be offered across providers/accounts; the code must not assume cross-venue portability by default.
What happens after a timeout
If connectivity fails after confirmation, the card charge outcome might be unknown. Do not press a button that immediately creates a second payment attempt. Show a pending state and recover by looking up the existing transaction reference. The backend should verify signed webhooks and reconcile order and payment state. Repeated webhooks must be idempotent. Contact support with the non-secret order reference if the result remains uncertain.
Evidence required before rollout
A verified sandbox session is necessary for success, decline, cancellation, timeout, duplicate attempt, webhook replay, signature rejection, wrong-venue account and refund cases. Compare real server/provider identifiers with the displayed customer result. Test on an actual Android device and later iOS. Do not release live payment functionality from a browser demonstration or an isolated PHP unit test.