ITISYOU Products

What it is, in plain terms

ITISYOU Products is a private, in-development online storefront for toys, aimed at the UK market. It covers what a real toy shop needs underneath the browsing and buying: a catalogue with toy-safety compliance gates that a product has to clear before it can be listed, a cart and checkout that re-check stock and price rather than trusting whatever a browser last saw, a fulfilment state machine that moves a paid order through to dispatch, a returns and refunds process, a support system, and an administration area protected by multi-factor authentication.

It is built around the idea that a children's product storefront carries real obligations — correct age grading, the right hazard warnings, money handled correctly, a return that is genuinely reversible — and that those obligations belong in the software, not just in a policy document.

It is not open. There is no public address anyone can visit today, live payments are not switched on, and the supplier and email connections needed to actually run a shop are not yet in place. What exists is a working system tested against itself, not yet a shop.

Why I built it

I wanted to find out what it actually takes to build a storefront that could sell something as ordinary-sounding as toys without cutting corners on the parts that matter because they are inconvenient — age grading, hazard warnings, a refund that cannot silently be issued twice, a payment that is checked rather than assumed. Toys aimed at children carry compliance obligations that a lot of small storefronts treat as an afterthought, and I wanted the compliance gate to be a genuine blocker in the code, not a checkbox an administrator could skip under time pressure.

I also wanted to see how much of "the site works" turns out to be true on inspection versus true on paper — an earlier account of this project described every phase as complete, and going back through it with independent testing found real, exploitable defects underneath that description. Finding those, and fixing them with evidence rather than reassurance, became as much the point as the storefront itself.

The problem underneath

The general problem with e-commerce software that looks finished is that "looks finished" and "is safe to trust with real money and real children's products" are different claims, and the gap between them tends to be invisible until someone loses money or receives the wrong product. A checkout that trusts a price the browser sends back looks identical, in a screenshot, to one that checks it against the payment provider — right up until someone changes the price in their browser's own tools.

A returns form that always fails to refund because it submits a placeholder instead of the real item looks, in a demonstration, exactly like one that works. A compliance gate that exists as a field on a form rather than a genuine block on listing looks the same right up until the product it should have stopped goes live. The project's working assumption is that these gaps only close under real testing — concurrent requests, a real payment provider's test mode, a genuinely wrong return — not under a read-through of the code.

How it works, without the jargon

In practice, a toy has to pass a compliance gate — checking required marks, age grading and hazard warnings — before it can be listed in the catalogue at all. A shopper's cart is re-checked at each step: stock, price and whether an item is still active are all re-verified rather than carried over from when the page first loaded.

At checkout, the order is drafted on the server first, and the payment is only accepted once it has been independently checked with the payment provider — the order amount checked against what the provider actually recorded, not against whatever the browser reports. A paid order moves through a defined fulfilment state machine, from payment through validation to being routed to a supplier and on to dispatch, with each transition checked against the order's real state so that, for instance, a cancelled order cannot be sent on for fulfilment.

If something goes wrong for the shopper, a returns flow lets them pick from the real items on a real order rather than a placeholder, and an approved return triggers a refund that is checked against duplicate attempts. The whole thing sits behind an administration area that will not grant full access to an account that has not enrolled in multi-factor authentication.

What building it taught me

The clearest lesson was how much distance there can be between a phase history that reads as "complete" and a system that has actually been tested under adversarial conditions. Re-running the project's own inherited test suite confirmed the numbers it claimed, but going further — trying to break the checkout, the refund path, the payment-confirmation handling, the admin permissions — found genuine, exploitable defects that a passing test suite had not caught, because the suite tested what the code was written to do rather than what someone might try to make it do instead.

The returns defect was a good example of how quietly this kind of thing hides: the form submitted a hardcoded placeholder for which item was being returned, the refund calculation built on that placeholder was always zero, and every single return approval failed — and none of that showed up until someone tried to actually return something for a reason the code did not expect.

The other lesson was more general: fabricated-looking content is a specific, findable category of defect — a tracking page inventing a delivery timeline, for instance — and it is worth testing for on its own terms, separately from whether a feature technically executes without an error.

Where it stands today

ITISYOU Products is in development, private, and not open. Catalogue, compliance gating, cart, checkout, the fulfilment state machine, returns, support and an MFA-protected administration area are implemented, and nineteen of nineteen end-to-end payment journeys — success, decline, a correctly signed confirmation, a duplicate confirmation, a refund, and a rejected forged confirmation — pass against a deployed pre-production environment using the payment provider's test mode.

A number of genuine, exploitable defects found by independent testing since an earlier, overstated account of the project have been fixed and verified, including the returns flow described above and a tracking page that had been inventing its progress.

What remains before the storefront could open is not, by the project's own account, further engineering so much as a short list of things outside the code entirely: a verified domain to send email from, live payment keys, a public address bound to the running service, real supplier credentials, and the owner's approval to go live. Much of the most recent work had not yet been committed to the project's history at the point this record was written.

Where it may go

Next: verify a real supplier connection and a sending domain for order and support email, since only a reference connector and a placeholder sender exist today. Then: close the smaller follow-ups already recorded as outstanding, including moving rate limiting from a best-effort control to an exact one. Later, if the owner approves: enable live payments and bind the storefront to a public address for the first time.

None of this describes a business that is trading; it describes the specific, named steps between an in-development storefront and one that could open.