Week 008 — Stripe, Webhooks, and a phpMyAdmin Trap

Stripe is not something you just drop into a project. It has its own gravity.

Week of November 18, 2024

Progress

Started the week with a webhook endpoint that was returning 500 with no explanation — nothing in the container logs, nothing useful from the browser. Two problems, discovered in sequence: the Stripe PHP library wasn't in the autoload path because composer install hadn't been run from the project root, and the require path to the autoloader was wrong. Fixed both, and the webhook came to life. By end of Monday, it was receiving events and processing them — tested with both the Stripe CLI trigger command and an actual test subscription from the site.

The bigger question became which events to care about. Two things need to come out of a successful subscription: the plan the user subscribed to, and enough customer data to tie the Stripe-side transaction to the srchParty user.

That second point drove the next decision: every srchParty user needs a corresponding Stripe customer ID, created at account registration time. Without a stable, shared ID, matching webhook events to users requires expensive lookups. The change touches api-user.php, api-auth.php, and the subscription handler — but it's the right foundation.

By Saturday, the sending side of the equation was working: Stripe customer IDs get created during account creation, a customer session starts on login, and the client secret gets passed to the pricing table embed when the user clicks Subscribe.

The Hard Part

phpMyAdmin tried to eat the database. Attempting to extend a VARCHAR column's length through the GUI corrupted the table's datafile — the table became inaccessible. The fix: connect directly via the MySQL CLI and run the ALTER TABLE statement there. The operation succeeded immediately.

phpMyAdmin is convenient for browsing and quick queries. For schema changes, apparently it is not to be trusted.

Next Week

The plumbing between Stripe and srchParty is mostly in place. What remains is the fulfillment side: when the webhook fires for a successful payment, extract the subscription data from the payload and update the application's internal state accordingly.