Never Trust the Browser's Payment Confirmation

A common e-commerce bug isn't really a bug — it's a design choice that ages badly. The checkout page calls the payment provider, gets a success response in the browser, and the frontend tells the server "charge this order as paid." Intercept or fake that one client-side call and you've got a free order. It works fine until someone notices.

PagezTech sells physical goods, but also two things you can't just cancel and refund cleanly: data bundles and WAEC/WASSCE voucher codes, both delivered near-instantly. That made trusting a client-side payment confirmation a worse idea than usual, so we didn't. Every order, data bundle purchase, and WAEC voucher purchase is verified server-side — via a Supabase Edge Function talking directly to Paystack — before the order is created or anything is delivered. The browser gets to say "the user tried to pay," never "the user did pay."

The same instinct shows up in how the affiliate program handles money. Commission payouts go out via Paystack Transfers rather than a manual process someone has to remember to run, and withdrawal requests go through the same server-side verification path as a purchase.

It extends to secrets, too: the Paystack secret key, the Resend API key, and the Supabase service role credential never enter the client bundle. They live only in Edge Function environment secrets — so even a fully compromised frontend build can't leak them.

PagezTech is live at pageztech.com, in active production use.