Incoming transmission

Let's simplify our shop

As you may have noticed, we're in the middle of cleaning up our website. We started with CSS then tackled the RSS feed. We haven't mentioned it here, but we also revamped the directory listing, then the article list and the blogroll. Anyway, we're having fun1.

Riding the momentum, and because we'd been wanting to tackle it for a while, we just finished migrating the shop. After a few years on PrestaShop, our store is back on the site.

And we figured it would be worth documenting.

Why PrestaShop?

The first shop we put on the site used a simple static page with paypal buttons. We listed the LARP scenarios on it and, for each, a small button to buy it, shipping included to save us the headache2.

To get back to shipping costs, the problem is that it depends on a lot of parameters. The destination country, the book's weight and additional services (with or without signature?). Embedding all these choices in a PayPal button isn't the most practical.

So, shortly before releasing our book on shellcodes, we shopped around for solutions to sell it and wanted to try the adventure with a real shop. A more fully-featured site so our fans can easily buy our stuff and get our books delivered where and how they want.

So we installed a PrestaShop at home. We created a DMZ in our network to host this server accessible from the outside. We set up the machine, configured the web server, installed PrestaShop properly and set it up (e.g. email accounts to notify us of shop activity).

We disabled a bunch of modules designed to spy on track our visitors and installed others to make their lives easier; PayPal for payments and Colissimo, the French parcel service, for shipping.

If I had to take away something positive from this story, it's the payment and printing shipping label. When a visitor makes a purchase and enters their address, on my side, I just have to click a button to get a PDF to print.

I may be dysgraphic3, but if a machine can print an address for me, it saves us all time. It saves me from writing it three times, saves the postal service from having to decipher it, and saves my visitor from waiting for the package to find its way through.

Why drop PrestaShop?

You can probably guess, if we're dropping PrestaShop, it's because, for us, the drawbacks outweigh the benefits.

Warning before reading further. To give you an idea of our use case, we made less than 10 sales over the period (a bit more than a year). The situation would surely be quite different for a different content and audience.

Colissimo

As much as the colissimo module was handy for printing labels, that's where it ends because overall, we're not happy with it.

First, there are surprise fees. I naively thought postal rates were unique but no… within the PrestaShop module, I have to pay 20% VAT and an "energy adjustment" (11% excl. VAT), things that don't exist if I go to the post office counter. The difference isn't huge in absolute value, but the surprise was bitter.

Then, the module doesn't know the rates4 and we have to manually enter everything. That means for each weight range (and if we forget one, delivery will be considered free), for each country (so we have to translate between PrestaShop zones and postal zones) and each service… And rates sometimes change which forces us to start over5.

Continuing… There was historically a special French rate "Livres et brochures", very advantageous for book shipments outside France (for cultural outreach) but it was removed in July 2025. Sending the book about shellcodes (which weighs a little over 500g and thus falls into the kilo rate6) goes from €2 to €20. Not to mention those customs rules I still haven't figured out.

So let's stick to shipments within France. In that case, the rate to send the shellcodes book is €10. For a €35 book, we add almost a third. Just for shipping. It's as much as the printer. In comparison, Amazon does it for free (or nearly)…

PrestaShop

The problem is that even if the Colissimo module was improved and postal rates favored knowledge dissemination, we're still on the fence about the tool for our use case.

First, notifications. The shop notifies everyone of everything but I never managed to get it to notify me that a purchase was made. That's a shame because it's the only information I really need. If payment is made via PayPal, I'm notified by PayPal but otherwise, nothing. I need to frequently check the interface to know that, oh, nope, still no purchase7.

Then, European Union rules mean that if my client is in Europe but outside France, I have to charge them their country's VAT. I'll skip the maze of formalities (administrative but also PrestaShop configuration). It's complicated, I don't remember how anymore and I ultimately chose not to apply the rules8.

Not to mention that if the client is a professional, I can't collect VAT because they are the ones required to pay it in their country. However, prestashop doesn't cover this case. Or at least not without adding a new module UnknownModule.

The only foreign client we've had is actually a professional. So I had to do everything manually: international transfer to refund the excess VAT, issuing a new invoice canceling the previous one. Fortunately, I don't have double-entry bookkeeping (it would have forced me to make journal entries to cancel and redo the transactions).

Security

Like all applications, PrestaShop can have vulnerabilities. And given the automatic web scans, as soon as there's one, I'm sure it will be exploited. To avoid getting my infra messed up, I have to isolate it as much as I can, make backups as often as I can, and update it.

So I've subscribed to PrestaShop's RSS feed. It only contains marketing communications but I can't put the feed on mute because you're never safe from a vulnerability announcement slipping through at that moment9.

By default, PrestaShop can't update itself. I would have loved a button that does it for me with the assurance that developers did a clean job, but no, I had to add a module. A module with thoroughly un-reassuring messages, warning it can break everything if something goes wrong10.

So each time, it's with apprehension that I click The Button11. Especially because sometimes, it disables some modules (e.g. shipping), sometimes it re-enables others (e.g. tracking) and sometimes nothing has changed. But since it doesn't tell me, I have to go over everything to double-check.

The worst is that even like this, even with proper and simple settings, I still got messed up by some scunners…

  1. I didn't want my customers to create accounts. I just need their address but you can't do it that way. At best, we can allow anonymous accounts, which I did.
  2. As a courtesy, I configured the welcome message for customers who create an account. And also so that in case of spoofing, the owner of the original email can know.
  3. Bots started creating fake accounts with real email addresses to whom I was sending messages, thus participating, quite unwittingly, in a distributed attack.

I want to say, the fix is easy:

Only create an account when a user has bought a product.

The fix

That way, every email going out from my server would cost them the price of a book. I mean, who needs to create an account on the arsouyes shop without buying anything?

But no, it's not designed that way. There is no menu option to apply this restriction. Official recommendations are to install even more tracking security modules. Filter IPs, add a captcha or use a cloud solution12.

Why not Amazon and co.?

Technically, it would be easy.

We print our books via Lulu and their interface has a small checkbox to be distributed globally. Once we've printed a proof of the book, we check that it's how we wanted and from there, it's available everywhere (or almost: Amazon, Ingram and Hachette).

Of course, our margin will be smaller on these books. For example for the shellcodes book, Lulu would sell the book at half price to these platforms (€17.50), then subtract the printing cost (€10) and their 20% margin, leaving us €6 (or €4.20 once VAT and contributions are subtracted)13.

Personally, it doesn't bother me that the bookseller selling the book makes a margin and that I have to cut into mine for it. That's the game, we all participate in this distribution chain and each take a little along the way.

But ethically, it's impossible.

There is NO WAY that Mr. Bezos makes a single cent on our work14.

Les arsouyes

There's first the economic model I don't endorse. Software exploitation is fun, human exploitation is less so. Then there's the training of their generative AIs. When it's sold on Amazon, it's printed on Amazon and they have the PDF.

My problem with Lulu is that I can't specify which channels to sell through. If I want to ban Amazon from selling my book, I have to give up global distribution. If I want Hachette to distribute it, I have to accept that Amazon can too… Anyway, it's a dead end15.

To get out of this deadlock, we'd either have to handle distribution ourselves (but that's not feasible) or find a publisher (but that breaks the DIY aspect we liked). If you have ideas, we're all ears.

How do we do it now?

So we brought the shop back to the site. It's a static page listing what you can buy to support us with buttons to get them.

Initially, we wanted a single "email us" button and to do everything by email. Rather than impersonal platforms that break the human connection, email allows for a more authentic human relationship (which does a world of good).

On the other hand, we realized that sites requiring you to send an email puts a lot of people off16. So we thought about what we could do and here's what we found:

  • lulu.com to make books available everywhere in the world,
  • leboncoin.fr for shipments within France (and some neighboring countries).

For us, that's far fewer administrative and tax headaches. And for you, it means less daunting shipping costs. Otherwise, you can always contact us. It always makes us happy.