How to open it, what each panel is actually telling you, which numbers to trust, and how to get the paid report the page itself cannot give you.
seetosee.org/BAIPC1/
Bookmark it. There is no link to it from anywhere on the site — the address is the only way in.The two unverified are both your own addresses — info@seetosee.org and techsupport@seetosee.org. They registered and never opened the verification email.
Live watch on audit_events for failed sign-ins in the last 20 minutes. Green means nobody is locked out. This is the panel to glance at daily.
Anyone whose sign-in is failing right now. Normally empty. A name here means a real person cannot get in — act on it.
Registered but never opened the verification email. Your follow-up list. Reads from email_verification_tokens.
Who · Joined · Answered email · Last signed in are all real, straight from users. The Prefix, Started to pay and Paid columns are not — see below.
These read zero for everyone, always, and that is a bug in the page — not a fact about your business. The page looks for tables named orders, subs and prefixes. Your database calls them commerce_orders, stripe_subscriptions and prefix_identities. It finds nothing, so it prints a dash.
Until the page is fixed, payment answers come from the database directly. This is read-only and safe.
u533774356_seetosee.DESCRIBE commerce_orders;That prints every column. Look for the one holding the member (likely user_id), the one holding state (status), and the amount. Then join it to the member list:
SELECT u.name, u.email, o.status, o.created_at
FROM commerce_orders o
JOIN users u ON u.id = o.user_id
ORDER BY o.created_at DESC;If that errors on a column name, the DESCRIBE output tells you what to swap in. Same pattern for the other two:
DESCRIBE stripe_subscriptions;
DESCRIBE prefix_identities;And the quickest possible answer to "has anyone paid at all":
SELECT COUNT(*) FROM commerce_orders;
SELECT COUNT(*) FROM stripe_subscriptions;Zero rows means nobody has reached checkout yet. Rows means the Back Office has been hiding real activity from you.
| Question | Table to read |
|---|---|
| Who are my members? | users |
| Who verified, who didn't? | email_verification_tokens |
| Who tried to buy? | commerce_orders |
| Who has a live subscription? | stripe_subscriptions |
| Who is a Stripe customer? | stripe_customers |
| Did Stripe tell us anything? | stripe_webhook_events |
| Who has access to what? | entitlements |
| Who claimed a prefix? | prefix_identities |
| Who failed to sign in? | audit_events · login_attempts |
The header clock is your local time but the row timestamps are UTC, four hours ahead. A sign-in that reads 08:11 AM actually happened at 04:11 AM your time. Nothing is broken — just subtract four.
That column is meant to fill in payment order. It is blank for everyone because the page cannot read the orders table — same root cause as the paid columns. It is not waiting on anything you need to do.
One change, in the Back Office page's own code: point its table resolver at the real names.
| It looks for | It should look for |
|---|---|
| orders | commerce_orders |
| subs | stripe_subscriptions |
| prefixes | prefix_identities |
No schema change, no data touched, one admin page. After it, the paid columns mean something and you stop needing phpMyAdmin for this.
Read-only throughout. Nothing in this guide changes data — the SQL above only selects and describes. Snapshot taken Sep 14, 2026.