PrestaShop is gebouwd rond een eenmalige handeling: een winkelwagen, een bestelling, een betaling. Het abonnement veronderstelt het omgekeerde, een verbintenis die betalingen in de tijd produceert zonder dat de klant terugkomt. Deze twee modellen komen niet vanzelf samen.
Dit is de architectuur die werkt, en de punten waarop implementaties breken.
Wie de waarheid bezit
De eerste beslissing, en ze bepaalt al de rest.
Een betaalplatform als Stripe beschikt over een complete engine voor terugkerende facturatie: abonnementen, vervaldagen, herinneringen, beheer van verlopen kaarten. Dat herbouwen in PrestaShop zou een fout zijn.
De verdeling die standhoudt: Stripe bezit het abonnement, dus de cyclus, de vervaldagen en de inning. PrestaShop bezit de catalogus, de klant en de bestellingen die bij elke vervaldag worden gegenereerd.
Concreet: elke geslaagde afschrijving maakt een bestelling aan in PrestaShop, die vervolgens uw normale voorbereidings- en verzendproces volgt. Zo blijven uw statistieken, facturen en logistiek samenhangend.
De webhooks om te beluisteren
Het hart van de integratie, en het punt waar het echte werk zit.
Vijf events moeten worden verwerkt, elk met een precies gedrag.
- De geslaagde termijnbetaling. Maakt de bestelling aan in PrestaShop, boekt de voorraad af, verstuurt de bevestigingsmail.
- De mislukte betaling. Maakt geen bestelling aan, zet het abonnement in wacht, start de herinneringssequentie.
- Het bijgewerkte abonnement. Wijziging van formule, hoeveelheid of datum. Moet aan shopzijde worden doorgevoerd.
- Het geannuleerde abonnement. Sluit de toegang af als u content verkoopt, stopt de verzendingen als u fysiek verkoopt.
- De verlopende betaalmethode. Start een herinnering vóór de mislukking, wat de onderbreking vermijdt.
Drie technische regels voor de webhooks. Verifieer de handtekening van elke notificatie, anders kan om het even wie bestellingen bij u aanmaken. Verwerk ze idempotent: hetzelfde event kan meerdere keren worden afgeleverd, en u mag geen twee bestellingen aanmaken. En antwoord snel met een ontvangstbevestiging, verwerk daarna in de achtergrond, anders beschouwt het platform de aanroep als mislukt en speelt het hem opnieuw af.
DataFirefly Subscriptions: Abonnementen en Terugkerende Betaling via Stripe voor PrestaShop 8 & 9De abonnementsmodule voor PrestaShop 8 en 9: Stripe card on file, dunning en self-service voor de klant.€169,00
De verlopen kaarten, eerste verliespost
Bij een abonnement komt de meerderheid van de ongewilde opzeggingen van een ongeldig geworden betaalmethode, niet van een klantbeslissing.
Drie mechanismen stapelen zich op om de schade te beperken. De automatische kaartupdate, aangeboden door de netwerken en doorgegeven door de betaalplatformen, die het nieuwe nummer zonder tussenkomst ophaalt. De herinnering vóór het verlopen, een maand voor de einddatum. En de hernieuwde-pogingssequentie na een mislukking, gespreid over een tot twee weken in plaats van de dag erna herhaald.
Voorzie een respijtperiode waarin de dienst actief blijft ondanks de mislukking. Onmiddellijk afsluiten verandert een bancair incident in een definitieve opzegging.
Het bestelproces: niet mengen
Een ontwerpvraag die vaak te laat wordt beslecht. Een winkelwagen met een abonnement en producten in eenmalige aankoop stelt een probleem: het eerste creëert een terugkerende verbintenis, het tweede niet.
Twee aanvaardbare benaderingen. Het aparte bestelproces, waarin het abonnement alleen wordt afgesloten, zonder mogelijkheid er iets aan toe te voegen. Eenvoudiger, duidelijker voor de klant, en de aanbevolen standaardkeuze.
Of de gemengde winkelwagen, waarin de initiële bestelling beide bevat, met één betaling die de producten dekt en het abonnement start. Technisch zwaarder, en u moet heel duidelijk zijn over wat daarna wordt afgeschreven.
Wat u niet moet doen: twee verschillende abonnementen in dezelfde winkelwagen laten. De facturatiecycli lopen onmiddellijk uiteen en het beheer wordt onontwarbaar.
De sterke authenticatie
De Europese betalingsregelgeving legt voor veel transacties een authenticatie van de kaarthouder op. Bij een abonnement wordt de eerste betaling door de klant geauthenticeerd, de volgende vallen onder een ander kader omdat ze door de verkoper worden geïnitieerd.
Twee praktische gevolgen. Het mandaat moet correct worden geregistreerd bij de eerste betaling, wat de platformen verzorgen op voorwaarde dat de betaalintentie met de juiste parameters is aangemaakt. En sommige vervaldagen kunnen toch een authenticatie vereisen, wat een voorzien traject veronderstelt om de klant naar een authenticatiepagina terug te brengen, in plaats van een stille mislukking.
Het wettelijke kader
Drie verplichtingen, gecontroleerd en regelmatig gemist.
De informatie vóór het afsluiten: duur, bedrag, periodiciteit en opzegmodaliteiten moeten zichtbaar zijn op de aankooppagina, niet alleen in de algemene voorwaarden.
De online opzegging, even eenvoudig als het afsluiten, bereikbaar vanuit de klantomgeving zonder te moeten schrijven of bellen.
De informatie vóór de verlenging voor stilzwijgend verlengde abonnementen, binnen een termijn die de klant de tijd laat om te weigeren.
De drie cijfers van het model
De maandelijkse terugkerende omzet, die de economische basis geeft. Het maandelijkse verlooppercentage, met onderscheid tussen vrijwillige opzeggingen en betalingsmislukkingen, omdat de remedies verschillen. En de gemiddelde levensduur van een abonnee, die uit het tweede volgt en bepaalt hoeveel u mag uitgeven om er een te werven.
De Subscriptions module voor PrestaShop zet deze architectuur op op PrestaShop 8 en 9: abonnementen gekoppeld aan Stripe, automatische aanmaak van de bestellingen bij elke vervaldag, verwerking van de webhooks met handtekeningverificatie, beheer van betalingsmislukkingen en klantomgeving om te wijzigen of op te zeggen.