Abonnementsprijs in Shopify Checkout UI Extensions

Een Shopify checkout UI extension kan de terugkerende prijs die een abonnee bij het afrekenen ziet niet overschrijven. Dat bedrag komt uit het pricing policy van het selling plan, dus als het er na een productwissel verkeerd uitziet, hoort de oplossing bij het plan, niet in de extension.

Een verkoper met een kaarsenabonnement zag dat de Recurring Subtotal altijd de startprijs bleef tonen, zelfs nadat klanten overstapten naar een goedkopere navulvariant, zoals beschreven in een Shopify Community-topic. Wij zien dezelfde verwarring in onze eigen supportqueue: 13 vragen over abonnements-checkout in 90 dagen, waaronder verkopers die niet zeker weten wat de checkout belooft versus wat er echt in rekening wordt gebracht.

Waar de terugkerende prijs eigenlijk vandaan komt

Shopify organiseert abonnementsproducten in selling plan groups. Elk plan heeft een pricing policy, en die policy kent twee vormen: fixed, één aanpassing voor het hele abonnement, of recurring, een andere aanpassing zodra een beginperiode afloopt. De checkout leest rechtstreeks uit de policy die aan die regel hangt.

Checkout UI extensions staan naast dat bedrag, niet erin. Shopify documenteert ze als blokken of statische content die voor of na checkout-secties worden geplaatst. De prijsberekening wordt apart afgehandeld door Shopify Functions, niet door een UI extension.

Als je je checkout- en accountextensies sinds de laatste deadline nog niet hebt gecontroleerd, is dat een goed startpunt voordat je er nog eentje toevoegt.

Twee dingen die mensen "productwissel" noemen

Maak onderscheid tussen deze twee gevallen voordat je gaat troubleshooten: een in het plan ingebouwde cycluswissel, zoals startprijs van de kaars en daarna navulprijs zonder actie van de klant, en een handmatige productwissel door de koper tijdens het abonnement. De forumcasus hierboven is het eerste type. Een handmatige wissel is een andere actie, maar werkt hetzelfde pricing policy-object eronder bij.

De audit: zoek uit wat kapot is

1. Haal het selling plan achter het product op, vanuit het dashboard van je abonnementsapp of via de Admin GraphQL-query sellingPlanGroups, en bekijk de pricing policies.
2. Controleer of het één policy heeft of twee. Slechts één policy betekent dat beide cycli bewust hetzelfde bedrag tonen en factureren.
3. Verwacht je twee prijzen, voeg dan de ontbrekende recurring policy toe via je abonnementsapp, zodat cyclus één de startprijs factureert en latere cycli de wisselprijs.
4. Sla de wijziging op, plaats een echte test-abonnementsbestelling en controleer de eerste aankomende afschrijving in je abonnementsapp voordat je iemand vertelt dat het probleem is opgelost.
5. Zijn beide policies al correct en blijft de checkout toch onduidelijk, dan is het een formuleringsprobleem, geen prijsprobleem. Ga naar de volgende sectie in plaats van het plan opnieuw te bewerken.

Waarom dit oplossen voor de volgende migratie de moeite waard is

Een abonnee die bij het afrekenen de ene prijs ziet en op het afschrift een andere, zegt vaak op of dient een chargeback in. Dat komt vaak precies naar boven als winkels van abonnementsapp wisselen.

We hebben ook supporttickets gezien waarbij betaalmethoden onafhankelijk van de prijs kapotgingen, bijvoorbeeld een vraag over "iDEAL/Mollie payments not working" na een providerwissel. Dat is een aparte storing, die je apart moet controleren.

Twijfel je of een migratie het waard is, dan behandelt ons overzicht van abonnementskosten de kosten die de meeste winkels missen.

Als het bedrag klopt maar de tekst niet

Apps die zijn gebouwd op het native pricingmodel van Shopify slaan een wissel op dezelfde manier op als Shopify. Progus Subscriptions bijvoorbeeld bewaart de pricing policies van elk plan als paren van adjustment-type en adjustment-value, hetzelfde object waar de checkout uit leest, dus de audit hierboven werkt hetzelfde, ongeacht welke app het abonnement beheert.

Als het gefactureerde bedrag al klopt en je alleen extra context wilt voordat de wissel plaatsvindt, kan een developer een checkout UI extension toevoegen bij de ordersamenvatting. Die kan een opgeslagen toekomstige prijs uit een metafield lezen en als notitie tonen. Die notitie verandert de Recurring Subtotal-regel niet, hij beantwoordt alleen de vraag ernaast.

Shopify beperkt checkout UI extensions op de stappen informatie, verzending en betaling tot winkels met een Shopify Plus-plan. Extensies bij de ordersamenvatting volgen een ander target type, dus bevestig je exacte plaatsing voordat je dit aan iemand belooft.

Tot slot

Checkout UI extensions zijn een presentatielaag, geen prijsengine. Als een bedrag er verkeerd uitziet, controleer dan eerst de pricing policy van het selling plan, en bouw pas een eigen extension zodra je hebt bevestigd dat het gefactureerde bedrag zelf klopt.

Abonnementsapps veranderen door overnames, migraties en providers die functies uitfaseren, vaker dan de meeste merchants verwachten. Test de pricing policy en de configuratie van de betaalmethode apart na elk van die gebeurtenissen, want het ene kan kapotgaan zonder het andere.