# WOW Payments — Owner's Guide

This is the day-to-day guide for running the gateway once it's deployed (see `README.md` for the one-time setup steps).

## Logging in as admin
Go to `yourdomain.com/wow-gateway/admin/login.php` and use the username/password you baked into `admin/login.php`. This is a single hardcoded admin account — fine to start, but if you ever bring on a second admin, move to a real `admins` table with hashed passwords first (flagged in the README's known limitations).

## Daily things to check
- **System Wallets tab** — this is where your actual deposit addresses live for each coin/network. If you ever rotate a wallet (new hardware wallet, exchange address, etc.), update it here — every new payment link will use the new address immediately. Existing unpaid payment links keep the old address until they expire.
- **Payouts tab** — merchants request withdrawals here. Each request shows amount, coin, and destination address. You:
  1. Change status to **Approve** once you've sanity-checked the request (does the merchant have that much confirmed balance? does the address look valid for that network?).
  2. Manually send the crypto from your own wallet.
  3. Come back, set status to **Mark paid**, and paste the TXID of your outgoing transaction. This emails the merchant automatically.
  4. Use **Reject** with a note if something's wrong (e.g. balance doesn't match, suspicious address).
  - Nothing here is automated — the platform does not hold or move funds on its own. You are the one manually approving and sending payouts. That's a safety feature, not a bug, until you've built real confidence in the flow.
- **Tickets tab** — merchant support requests land here. Reply inline; it emails the merchant and flips the ticket to "pending" until they reply back (which flips it to "open" again for you). Close a ticket once resolved.
- **Merchants tab** — see everyone who's registered, change their fee tier, or suspend an account (e.g. for abuse or non-payment) — suspending blocks their API keys and login immediately.

## Fee tiers
Two tiers ship by default: `standard` (1%) and `pro` (0.5%). Edit percentages/flat fees directly on the System Wallets page. Assign merchants to a tier from the Merchants page — e.g. give a high-volume merchant the `pro` rate manually once you've built a relationship.

## Keeping the chain-verification cron alive
Nothing gets confirmed without the cron job running (`cron/check-transactions.php` every 1–2 minutes via cPanel Cron Jobs). If merchants report payments stuck in "confirming" for a long time, check that:
1. The cron job is actually still scheduled (cPanel sometimes drops these on plan migrations).
2. Your Etherscan/BscScan/Tronscan/BlockCypher API keys haven't hit a rate limit — check `error_log` for `SMTP send failed` or explorer API errors.

## Email deliverability
All system email goes through the SMTP mailbox you configured in `includes/config.php`. If merchants say they're not getting emails:
- Check the mailbox isn't over its sending quota (shared cPanel mailboxes often cap at 100–500/hour).
- Make sure SPF/DKIM are set up for your domain in cPanel → Email Deliverability, or mail will land in spam.

## Growing beyond one shared deposit address per coin
Right now, all merchants share one deposit address per coin/network, and payments are matched by exact amount rather than a unique address. This is simple and works fine at low-to-medium volume, but if two customers pay the same amount at the same moment, or you want cleaner accounting, the next real upgrade is per-order HD wallet address derivation. Worth planning for once volume picks up.

## Customer-facing pages you might want to keep updating
- `public/index.php` — the landing page (About, fees, contact form). Update copy here as your fee structure or coin support changes.
- Contact form submissions email `ADMIN_NOTIFY_EMAIL` directly — there's no queue or dashboard for these, so check that inbox.