Shopify permite migrarea abonamentelor existente din Billing API către App Pricing prin Partner Dashboard sau comenzi CLI, iar trecerea se face la începutul următorului ciclu de facturare, fără reaprobare din partea comercianților. Pentru furnizorii de aplicații, asta mută discuția din zona tehnică în cea comercială: aceeași bază de clienți, alt mod de a o administra.

Ce s-a schimbat, concret

Anunțul din changelogul Shopify (29.09.2026) rezolvă o problemă veche: până acum, un app care factura prin Billing API și voia să treacă pe App Pricing avea de ales între a recrea planurile de la zero și a conviețui cu două sisteme paralele. Acum există o cale de migrare.

Mecanismul are două niveluri. Primul este instrumentul din Partner Dashboard: îți schițezi planurile App Pricing pornind de la planurile manuale existente, le testezi pe magazine de dezvoltare și apoi muți abonamentele simple, adică cele fără componente de tip usage, într-un singur clic. Al doilea este CLI-ul, prin comenzile shopify app subscription-migrations, gândit pentru cazurile complexe: abonamente cu facturare pe consum, ajustări de preț, planuri private. Cu CLI-ul poți lista magazinele și statusul migrării, poți programa mutări în bloc și poți anula migrări în așteptare, indiferent dacă au fost create din CLI sau din Dashboard.

Două detalii contează mai mult decât restul. Migrarea nu cere reaprobarea taxării de către comerciant, ceea ce elimină cea mai mare frică operațională. Și nu trebuie să schimbi modul în care aplicația facturează ca să poți folosi instrumentul. Ambele sunt detalii de care atârnă decizia de a începe sau de a amâna.

De ce contează pentru furnizorii de aplicații, nu doar pentru dezvoltatori

Este tentant să citești anunțul ca pe o notă tehnică pentru echipa de engineering. Greșit. Ce se schimbă aici ține de economia aplicației.

App Pricing, ca sistem de facturare nativ, simplifică modul în care vinzi: mai puține ramuri logice în cod, mai puține cazuri speciale în suport, mai puțină mentenanță pe partea de billing. Fiecare ramură eliminată este timp de dezvoltator pe care îl muți din întreținere în produs. Iar pentru o echipă mică, asta e diferența dintre a livra o funcție pe trimestru și a livra trei.

Al doilea efect ține de churn. Fiecare migrare de sistem de facturare este o fereastră de risc: dacă un comerciant trebuie să reaprobe un card, dacă un abonament se rupe la mijloc de ciclu, dacă o factură ajunge dublată. Anunțul spune explicit că abonamentele se mută la începutul următorului ciclu de facturare, fără reaprobare. Asta reduce suprafața de expunere, dar nu o elimină. Programarea rămâne programare, iar programarea se poate lovi de realitate.

Al treilea efect, și cel mai puțin discutat, este de măsurare. Când abonamentele trăiesc în două sisteme, orice calcul de MRR, de cohorte sau de expansiune devine o operațiune manuală. Iar calculele manuale se fac o dată, apoi se strică. Un singur sistem de facturare face ca datele de venit să fie coerente fără intervenție. Despre cât de fragil devine reportingul când depinde de exporturi manuale am scris și în analiza despre SMS marketing ecommerce 2026, iar logica se repetă aici la alt nivel.

Cum arată o migrare făcută corect

Nu există un singur mod corect, dar există unul care îți protejează venitul. Recomandarea mea, separată de ce spune sursa, arată așa.

Întâi, inventar. Listează toate abonamentele active, grupează-le pe tip: simplu, cu usage, privat, cu preț ajustat. Instrumentul din Dashboard acoperă doar prima categorie. Restul cere CLI-ul. Dacă nu știi în ce grupă cade fiecare abonament, nu poți estima nici volumul de muncă, nici riscul.

Apoi, planuri paralele. Creează planurile App Pricing astfel încât să reflecte exact planurile manuale existente. Aici e locul unde apar surprizele de mapare: un plan cu trei praguri de preț poate să nu se traducă 1 la 1. Testează pe magazine de dezvoltare înainte de orice contact cu un magazin real.

Apoi, val de probă. Migrează un grup mic, cu subscripții simple, și urmărește un ciclu complet de facturare. Nu te uita doar la statusul migrării, ci la bani: s-a emis factura corect, suma e cea așteptată, accesul în app a rămas activ, comerciantul nu a deschis tichet. Anunțul sugerează exact acest pas de confirmare înainte de extindere. El este obligatoriu, nu opțional.

Abia apoi, mutare în bloc. CLI-ul permite programarea în masă și, la fel de important, anularea migrărilor aflate în așteptare. Faptul că poți da înapoi înainte de a se produce schimbarea este cea mai bună plasă de siguranță din tot fluxul. Folosește-o: programează conservator, nu tot portofoliul într-o singură noapte.

Ce înseamnă pentru tine, ca antreprenor sau marketer român

Dacă ai un magazin pe Shopify și folosești aplicații care factura prin Billing API, nu ai nicio acțiune de făcut. Migrarea o face furnizorul aplicației, nu tu. Nu îți cer aprobarea, nu îți schimbă suma, nu îți schimbă data de facturare. Practic, pentru tine anunțul este invizibil, cu o singură excepție pe care merită să o urmărești.

Excepția este factura. Dacă în luna următoare vezi o linie de facturare de la o aplicație care îți apare diferit față de lunile anterioare, nu presupune că e o eroare de sistem și nu sări direct la "mi s-a mărit prețul". Verifică: aceeași aplicație, același plan, aceeași sumă, doar eticheta s-a schimbat. O diferență reală de sumă e altceva și merită tichet.

Pentru marketerul care administrează un portofoliu de magazine, există un câștig indirect. Cu cât mai puține aplicații se bat pe integritatea facturării, cu atât mai puține tichete de suport care ajung la tine și mai puțin timp pierdut pe reconciliere de facturi. Este un câștig mic, dar se cumulează. Dacă lucrezi pe ecommerce și pe automatizări, tiparul ăsta, automatizarea înlocuiește munca manuală recurentă, îl regăsești și în analiza despre YouTube CTR, Reels și noutăți de platformă.

Un alt unghi pentru antreprenorul care deține sau investește într-un app de Shopify: bariera de a schimba sistemul de facturare tocmai a scăzut. Asta înseamnă că furnizorii care amânau migrarea din frica de pierdere de abonați au acum mai puține scuze. Și înseamnă și că un app care rămâne pe Billing API începe să fie un semnal despre cât de mult investește în propriul produs.

Ce rămâne neclar și merită verificat

Anunțul rezolvă migrarea, nu toate consecințele ei. Câteva zone rămân deschise și nu ar trebui tratate ca rezolvate doar pentru că fluxul este documentat.

Acestea sunt întrebări de verificat în documentația de migrare și pe magazine de test, nu concluzii pe care să le prezinți ca fapte. O verificare incompletă nu dovedește că o funcție lipsește. Dovedește doar că nu ai testat-o încă.

FAQ

Trebuie să aprob migrarea dacă sunt comerciant? Nu. Abonamentele se mută la începutul următorului ciclu de facturare fără reaprobarea taxării, conform anunțului Shopify. Furnizorul aplicației decide migrarea, nu tu. Verifică doar că suma facturată în luna respectivă corespunde cu ce te așteptai.

Ce aplicații sunt afectate? Cele care facturau comercianți prin Billing API și aleg să treacă la App Pricing. Aplicațiile care folosesc deja App Pricing nu sunt afectate de anunț. Dacă un app folosește tipuri de abonament pe care instrumentul din Dashboard nu le poate migra, furnizorul trebuie să folosească comenzile CLI.

Pot migra abonamentele cu facturare pe consum prin Dashboard? Instrumentul din Partner Dashboard acoperă abonamentele simple, fără componente de usage. Pentru cele cu usage, planuri private sau ajustări de preț, este nevoie de comenzile shopify app subscription-migrations din CLI.

Când se face efectiv trecerea? La începutul următorului ciclu de facturare al fiecărui abonament. Din acest motiv, mutarea poate să apară eșalonat, nu simultan pentru tot portofoliul. Asta complică puțin reportingul pe o lună de tranziție.

Arcul final: AI-ul ajută, omul decide, agentia executa

Un instrument nou de migrare nu decide nimic singur. AI-ul te poate ajuta să clasifici rapid sute de abonamente pe tip, să extragi diferențele de preț între planurile vechi și cele noi, să pregătești tabelul de mapare. Ce nu face este să își asume riscul. Hotărârea că migrezi sau că mai aștepți o lună, că începi cu 50 de magazine sau cu 500, că anulezi un lot programat când apar primele semnale neplăcute rămâne la media buyer, la fondator, la omul care semnează. Iar pasul concret, de la inventar la migrarea în valuri și la verificarea primului ciclu de facturare, se face cel mai repede cu o echipă care a mai trecut prin astfel de tranziții. La ALLSoft Agency plecăm de la datele tale, nu de la slide-uri.