PROTOKÓŁ REM
A merch shop for a fictional podcast, built in PrestaShop from scratch — with a real sandbox payment integration, to learn the architecture of real e-commerce instead of loose exercises.
PROBLEM
"I wanted to learn PrestaShop not through loose exercises, but by building a shop that actually works — from catalog to payment."
PREMISE
A fictional client brief: a podcast creator needs a clickable, credible-looking merch shop prototype to show to partners — with sandbox payments, before any decision on real sales.
LEARNING GOAL
PrestaShop's module and hook architecture, payment handling, the admin panel — not through docs, but through a real project with the constraints of a real client.
PAYMENTS
The client explicitly required that the payment flow look and work like a production one, without any risk of real transactions. Stripe fell out fast — the official PrestaShop module has been dead since 2023, so integrating it would mean writing a gateway from scratch just to get a working demo. PayPal Sandbox had native support, but Tpay — a Polish gateway with an actively maintained module and explicit PS9 support — turned out to be the better fit.
An actively developed module plus a fully self-service sandbox (no verification documents, just company details in a form) avoided writing a payment integration from scratch, while also being a more realistic choice for a Polish-language shop than Stripe or PayPal.
No document verification in Tpay's sandbox meant the whole integration could be done right away, instead of waiting on a test account to get approved.
CHECKOUT
A ready hi-fi checkout mockup was on the table for implementation — a flattened layout, one continuous view instead of steps. But PrestaShop's classic checkout runs entirely on AJAX tied to specific hooks and data-* attributes in the existing markup. Rebuilding the structure to match the mockup would mean recreating that mechanism from scratch just for a visual change.
Kept the native step accordion (Address → Shipping → Payment) — the only override is a new Smarty file adding a sandbox warning bar, everything else is plain CSS (e.g. highlighting the selected method via :has(input:checked)).
Look adapted to the project, mechanics left untouched — too much risk for a demo to rebuild the AJAX mechanism from scratch just for aesthetics.
ARCHITECTURE
The whole theme needed a deep restyle toward an original visual direction — "declassified case files" — but the shop had to stay fully manageable from the admin panel. That was genuinely the hardest part of the whole project.
Instead of editing PrestaShop core files, consistently used a child theme over classic, Smarty overrides (extends + block), and hooks in a custom module. No visual change ever hardcoded content that should stay editable.
When merging two header bars into one row, the menu, contact, and logo hooks were left untouched — menu items and contact details are still editable from the Back Office.
CHALLENGES
No major technical fights in the "something didn't work" sense — the real challenge was maintaining self-restraint: making sure every visual change stayed compatible with PrestaShop's existing mechanisms and didn't take away the ability to manage the shop from the admin panel.
REFLECTION
The biggest surprise was the pace of the work. Prior experience was mostly building things purely in code from scratch — it was unexpected how much a ready, mature PrestaShop management panel (catalog, orders, configuration) speeds things up. Instead of building all of that from scratch, effort could go into payment integration and the visual layer.
Outcome
The shop is public and can actually be walked through — from catalog to cart to a sandbox payment checkout — deployed via CI/CD (GitHub Actions → Cyberfolks). This is an experimental field, not a real business, so there are no hard sales numbers — the outcome is measured differently: a working, deployed e-commerce prototype as proof of understanding PrestaShop's architecture.