It worked.
And it’s saved.

Improve the confirmation screen and account history in my existing signed-in café app. Keep the current framework, backend and database. Inspect the payment model before changing it.

The return from checkout should open the contribution record owned by the current user. Treat the return as a navigation event, not evidence of payment. Read the real status from the server. Pending, confirmed test payment, failed, cancelled and expired must have distinct, plain-language states. A pending result needs a “Check payment status” action and a way to return later. Do not show a success animation before confirmation.

For a confirmed record, show the café, amount, payment status, date, reference and the note the user supplied. Keep TEST PAYMENT labels on payment receipts. Escape user input before displaying it. Never expose provider secrets or another user’s data.

Create an account dashboard backed by the database. It should list only the verified signed-in owner’s records, show their confirmed test-payment total separately from pending checkouts, and include a readable empty state. A reload or later sign-in should fetch the saved records again rather than depending on browser-local history. A shared backend must enforce both application and owner boundaries.

Keep the campaign’s public total and the account’s personal total clearly distinguished. Show loading, failed-fetch and retry states without clearing a good record into a misleading empty state.

Verify one pending record becoming confirmed through the real provider confirmation path; reload the receipt and account history; sign out and back in; verify a second user cannot read the record; verify a repeated provider event does not create duplicate history or credit. Report which checks ran and which still need external access.