Prenumerationspris i Shopifys Checkout UI Extensions

En Shopify checkout UI extension kan inte skriva om det återkommande pris som en prenumerant ser i kassan. Det beloppet kommer från selling plan-ens pricing policy, så när det ser fel ut efter ett produktbyte hör rättelsen hemma i planen, inte i extensionen.

En handlare med en ljusprenumeration såg att Recurring Subtotal hela tiden visade startpriset, även efter att kunder bytt till en billigare påfyllnadsvariant, enligt en tråd i Shopify Community. Vi ser samma förvirring i vår egen supportkö: 13 frågor om prenumerationskassa på 90 dagar, bland annat handlare som är osäkra på vad kassan lovar jämfört med vad som faktiskt debiteras.

Var det återkommande priset egentligen kommer från

Shopify organiserar prenumerationsprodukter i selling plan groups. Varje plan har en pricing policy, och den policyn har två former: fixed, en enda justering för hela prenumerationen, eller recurring, en annan justering när en inledande period tar slut. Kassan läser direkt från den policy som hänger på den raden.

Checkout UI extensions ligger bredvid det beloppet, inte inuti det. Shopify dokumenterar dem som block eller statiskt innehåll placerat före eller efter kassasektioner. Prisberäkningen sköts separat av Shopify Functions, inte av en UI extension.

Om du inte redan har granskat dina checkout- och kontoextensions sedan senaste deadline är det en bra startpunkt innan du lägger till ännu en.

Två saker som folk kallar "produktbyte"

Skilj på dessa två fall innan du felsöker: ett cykelbyte inbyggt i planen, som ljusets startpris och sedan påfyllnadspris utan någon kundåtgärd, och ett manuellt produktbyte som köparen gör mitt i prenumerationen. Forumfallet ovan är av den första typen. Ett manuellt byte är en annan åtgärd, men det uppdaterar samma pricing policy-objekt under ytan.

Granskningen: ta reda på vad som är trasigt

Hämta selling plan bakom produkten, från din prenumerationsapps dashboard eller via Admin GraphQL-frågan sellingPlanGroups, och titta på dess pricing policies.
Kontrollera om den har en policy eller två. Bara en policy betyder att båda cyklerna avsiktligt visar och debiterar samma belopp.
Om du förväntar dig två priser, lägg till den saknade recurring-policyn via din prenumerationsapp, så att cykel ett debiterar startpriset och senare cykler debiterar bytpriset.
Spara ändringen, lägg en riktig testprenumerationsorder och kontrollera dess första kommande debitering inuti din prenumerationsapp innan du säger till någon att problemet är löst.
Om båda policyerna redan är korrekta och kassan ändå känns otydlig är det ett formuleringsproblem, inte ett prisproblem. Gå till nästa avsnitt i stället för att redigera planen igen.

Varför det är värt att åtgärda innan nästa migrering

En prenumerant som ser ett pris i kassan och ett annat på sin kontoutdrag säger ofta upp eller gör en bestridning. Det brukar dyka upp just när butiker byter prenumerationsapp.

Vi har också sett supportiärenden där betalmetoder gick sönder oberoende av priset, till exempel en fråga om "iDEAL/Mollie payments not working" efter ett leverantörsbyte. Det är ett separat fel som är värt att kontrollera för sig.

Om du funderar på om en migrering alls är värt det går vår genomgång av prenumerationskostnader igenom de avgifter som de flesta butiker missar.

När beloppet är rätt men texten inte

Appar byggda på Shopifys inbyggda prismodell sparar ett byte på samma sätt som Shopify. Progus Subscriptions, till exempel, håller varje plans pricing policies som par av adjustment-type och adjustment-value, samma objekt som kassan läser från, så granskningen ovan fungerar likadant oavsett vilken app som sköter prenumerationen.

Om det debiterade beloppet redan är korrekt och du bara vill ha extra sammanhang innan bytet sker, kan en utvecklare lägga till en checkout UI extension nära ordersammanfattningen. Den kan läsa ett sparat framtida pris från ett metafield och visa det som en notis. Den notisen ändrar inte raden Recurring Subtotal, den besvarar bara frågan bredvid.

Shopify begränsar checkout UI extensions i stegen information, frakt och betalning till butiker på en Shopify Plus-plan. Extensions nära ordersammanfattningen följer en annan target type, så bekräfta din exakta placering innan du lovar något till någon.

Avslutande tankar

Checkout UI extensions är ett presentationslager, inte en prismotor. När ett belopp ser fel ut, kontrollera först selling plan-ens pricing policy, och bygg en egen extension först när du bekräftat att det debiterade beloppet i sig är korrekt.

Prenumerationsappar förändras genom förvärv, migreringar och leverantörer som fasar ut funktioner, oftare än de flesta handlare räknar med. Testa pricing policy och betalmetodens konfiguration separat efter varje sådan händelse, eftersom den ena kan gå sönder utan den andra.

FAQ

Kan en checkout UI extension dölja ett felaktigt återkommande pris?

Nej. Checkout UI extensions lägger till innehåll bredvid kassans kärnfunktioner; de kan inte ta bort eller skriva över den raden. Du kan placera en notis bredvid, men det ursprungliga priset förblir synligt.

Behöver jag en utvecklare för att fixa ett tvånivåprenumerationspris?

Oftast inte för själva policyn. De flesta prenumerationsappar låter dig ställa in ett startpris och ett förnyelsepris från den egna dashboarden; egen kod behövs bara för en extra notis inuti kassan.

Fixar en åtgärdad kassa även tacksidan?

Nej. Tacksidan (Thank you page) använder ett annat extension-target än kassan, så kontrollera den separat efter att du rättat pricing policyn.

Är det här bara en Shopify Plus-lösning?

Bara delvis. Plus krävs för extensions i stegen information, frakt och betalning; extensions nära ordersammanfattningen följer ett annat target, så bekräfta din exakta placering först.

Hur bekräftar jag att åtgärden faktiskt debiterade rätt?

Lägg en riktig testprenumerationsorder efter att du ändrat pricing policyn, och kontrollera sedan dess första kommande debitering i din prenumerationsapps dashboard innan du stänger ärendet.