Pamastore

A campus marketplace can look deceptively simple: show products, add a cart, accept payment. That model stops being useful the moment one payment contains products from multiple sellers, stock can change while the buyer is paying, and each seller eventually needs a payout.

I treated the financial lifecycle as a state machine rather than a collection of payment buttons. The server recomputes what should be paid, verifies the Paystack reference, currency and amount, then validates aggregate demand against the current physical stock pools before any seller order is created.

External payment APIs produce awkward states. A transfer request can time out after the provider has already accepted it. Retrying blindly is how a marketplace pays a seller twice.

Pamastore reserves deterministic transfer references before calling Paystack and treats ambiguous network outcomes as processing until they can be reconciled. Refunds, disputes and payout eligibility share the same principle: if the system does not know, it does not invent certainty.

Preparing Pamastore for release exposed work that had nothing to do with screenshots: release credential hygiene, fail-closed production configuration, buyer and seller account deletion, report/block controls in chat, and explicit retention rules for financial evidence.

That changed how I think about release readiness. A mobile product is not ready because the binary compiles. It is ready when the operating system, store policy, backend lifecycle and user-facing recovery paths agree.

The mobile home experience moved to Explore-first discovery with campus-aware products and native category navigation. Buying and selling conversations were brought into one inbox instead of making seller accounts mentally switch products.

The same release also kept campus choice server-canonical for authenticated users and introduced durable seller-onboarding email claims so reminders can be retried without becoming spam.