EXPI: from payment to active access
Billing, subscriptions and payment-to-access reconciliation. How I connected payment events to the subscription lifecycle while owning platform architecture, implementation and operations.
Challenge
I was the sole engineer at EXPI, responsible for architecture, implementation, infrastructure and releases. Billing needed more than a successful payment notification. A first purchase had to grant access, a renewal had to extend the paid period, and refunds and cancellation of auto-renewal had different consequences. These scenarios had to stay consistent across the payment provider, customer portal and access services while the migration from the legacy PHP system was still in progress.
Technical details
Solution
One owner of subscription state. I concentrated subscription status and paid-period changes in a dedicated module. The customer portal and administrative tools called its commands instead of writing statuses independently. A payment event and its subscription change were stored in the same transaction. A repeated notification for an already recorded payment must not extend access again. Different causes, different transitions. Renewing an active subscription, receiving a late payment for an expired subscription and processing a refund were not reduced to a single paid flag. Turning off the next recurring charge preserved access until the end of the paid period; cancellation following a refund was handled separately. This kept the rules explicit and shared across entry points. Checking beyond the callback. Separate reconciliation detected mismatches between payment and access. A successful HTTP response to the payment provider did not by itself prove that access had been granted. These exceptions left a trace for investigation, and risky processing branches were covered by automated tests. Detecting a mismatch did not mean unconditionally granting access or refunding money automatically.
Result
By the end of my work, initial payments, renewals, refund processing and payment-to-access reconciliation were running automatically in the system. Billing connected payment events to explicit subscription rules, while exceptions remained visible for investigation. This was an operational part of the platform; migration of the rest of the portal continued.