We bouwden Stackable omdat kortingen keer op keer faalden op het enige moment dat telt

Lees genoeg reviews van kortingsapps en er duikt keer op keer hetzelfde patroon op: een prijs klopt in de winkelwagen, maar bij de checkout wordt er iets anders afgerekend. Een klant betaalt de volle prijs voor iets waarvoor een handelaar korting had beloofd, of twee kortingen die zouden moeten stapelen doen dat stilletjes niet, en niemand merkt het totdat er een terugbetalingsverzoek binnenkomt bij support.

Het patroon wordt erger op precies de momenten die het meest tellen voor handelaren. Rond Black Friday en Cyber Monday, wanneer het verkeer piekt en elke bestelling telt, is het moment waarop deze bugs het vaakst opduiken, omdat winkelwagentjes dan het volst zitten en kortingsregels het zwaarst worden gestapeld. En versnelde checkouts, Shop Pay, Apple Pay, Google Pay, PayPal, volgen elk hun eigen codepad, waardoor een korting die perfect werkt in een normale checkout stilletjes kan verdwijnen in een betaalflow met één tik die een handelaar zelf nooit test.

Er is een tweede storingspatroon dat net zo schadelijk is voor vertrouwen: apps die de werkelijke prijs van een product wijzigen om een korting te tonen, en die wijziging laten staan nadat de handelaar de app verwijdert. Een schone deïnstallatie zou moeten betekenen dat de winkel er precies zo uitziet als voordat de app ooit werd toegevoegd. Dat hoort geen extraatje te zijn, dat hoort de basis te zijn.

Stackable draait om één idee: de enige taak van een kortingsapp is overal, altijd, kloppend te zijn. Niet kloppend in de winkelwagen en hopen dat het bij de checkout ook klopt. Kloppend in de winkelwagen, kloppend bij de checkout, en kloppend in elke versnelde betaalflow, omdat Shopify ze allemaal berekent vanuit dezelfde serverside regel, als u de app zo bouwt.