Tilaaja vaihtaa tuotteen, näkee päivitetyn loppusumman ja odottaa seuraavan laskutuksen täsmäävän. Juuri tässä odotuksessa Shopifyn tilausten hallinta voi tulla kalliiksi: tiliotsikon, tilaussovelluksen ja laskentaperusteiden on oltava keskenään linjassa. Shopifyn uusi SubscriptionContractCalculation-rajapinta antaa kehittäjille paremman tavan laskea tilaussopimuksen muutokset ennen niiden tallentamista. Kauppiaalle hyöty on käytännönläheinen: vähemmän selittämättömiä veloituksia ja vähemmän manuaalista korjaustyötä. Tässä on kysymykset sovellustoimittajallesi ja ohjeet muutosten testaamiseen vaarantamatta tilauksien uusiutumista.
Mikä muuttui Shopifyn tilausten hallinnassa
Shopifyn lokakuun alustapäivitykset sisältävät muutoksen, joka vaatii huomiota jokaiselta toistuvia toimituksia myyvältä brändiltä. SubscriptionContractCalculation-rajapinnan julkistuksen mukaan tilaussopimusten muutokset kulkevat nyt Shopifyn kassamoottorin läpi.
Uusi rajapinta tukee Shopify Functions -toiminnallisuuksia sopimuslaskelmien aikana, mukaan lukien ostoskorimuunnokset ja toimitusmuokkaukset. Kehittäjät voivat myös esikatsella laskettua sopimusta loppusummin, toimitusvaihtoehdoin ja varoituksin ennen muutosten tallentamista.
Tilaussopimus tallentaa toistuvia ostoksia koskevan sopimuksen. Sopimuslaskelma esikatselee muutoksen vaikutusta ennen kuin siitä tulee tallennettu sopimus.
Shopify suosittelee, että SubscriptionDraftia käyttävät kehittäjät siirtyvät SubscriptionContractCalculation-rajapintaan. Vanhempi rajapinta on yhä saatavilla, mutta se ei tue uusia ominaisuuksia. Kyseessä on suunnitelmallinen siirtymä, ei merkki siitä, että nykyiset tilaustoteutukset olisivat lakanneet toimimasta.
Näkemyksemme: esikatselu on kaupallisesti hyödyllisin osa. Se luo mahdollisuuden näyttää asiakkaalle laskettu lopputulos ennen kuin hän vahvistaa tilauksen. Rajapinnan ominaisuudet auttavat kuitenkin vain, jos tilaussovelluksesi ja asiakaskokemuksesi hyödyntävät niitä oikein.
Miksi tavallinen tuotevaihto vaatii huolellista käsittelyä
Ajatellaanpa kahvitilausta. Asiakas saa pussin kuukaudessa ja päättää vaihtaa isompaan kokoon. Muutos voi vaikuttaa toimituskelpoisuuteen tai olla yhteydessä niputussääntöihin. Portaali, joka vain korvaa tuotteen hinnan, voi antaa puutteellisen vastauksen.
Kauppiaalla on tällöin kaksi ongelmaa. Asiakas saattaa hyväksyä muutoksen ymmärtämättä sen kustannuksia, ja asiakaspalvelun on selitettävä veloitusta tiedoilla, joita asiakas ei koskaan nähnyt.
Uusi laskentarajapinta tarjoaa reitin luotettavampaan muutosprosessiin. Se ei tarkoita, että jokainen asennettu sovellus näyttäisi välittömästi tarkat esikatselut tai että mikään kassan räätälöity sääntö toimisi automaattisesti tilausten kanssa.
Kysy palveluntarjoajaltasi, mitä Functions-toimintoja kauppasi käyttää ja mitkä niistä vaikuttavat tilauslaskelmiin. Pyydä heitä näyttämään todellinen tuotevaihto käytännössä. Yleinen demo-kauppa ei paljasta tuoteluettelosi erityisehtoja.
Me sijoittaisimme tähän työhön ennen tilausportaalin ulkoasun hiomista. Selkeämpi käyttöliittymä auttaa, mutta vahvistuspainikkeen takana olevan summan on oltava luotettava.
Tarkasta Shopifyn tilausten hallinta ennen siirtymää
Aloita reiteistä, joita pitkin sopimukset muuttuvat. Asiakkaat voivat muokata tilauksia sovellusportaalin kautta, kun taas asiakaspalvelu käyttää erillistä ylläpitonäkymää. Yritykselläsi voi olla myös räätälöityjä skriptejä poistuneille tuotteille tai massahinnoittelumuutoksille.
Kirjaa ylös jokainen reitti ja sen tekninen vastuuhenkilö. Merkitse sitten, mikä järjestelmä laskee päivitetyn sopimuksen ja mikä järjestelmä tallentaa sen. Tämä paljastaa usein, että näennäisesti yhtenäisessä tilauskokemuksessa on useita erillisiä toteutustapoja.
Esitä sovellustoimittajallesi nämä kysymykset
- Käytättekö tällä hetkellä SubscriptionDraftia, SubscriptionContractCalculationia vai jotain muuta prosessia sopimusmuutoksiin?
- Käyttävätkö asiakkaiden itsepalvelumuokkaukset ja henkilökunnan tekemät muokkaukset samaa laskentareittiä?
- Mitkä Shopify Functions -toiminnoistamme olette testanneet sopimuslaskelmien aikana?
- Näkevätkö asiakkaat lasketut loppusummat ja sovellettavat toimitusvaihtoehdot ennen vahvistusta?
- Miten ilmoitatte varoituksista, epäonnistuneista laskelmista ja tallennusvirheistä?
- Mitä tapahtuu, jos sopimus muuttuu esikatselun jälkeen mutta ennen asiakkaan vahvistusta?
Pyydä todisteita testiohjelmistosta, älä vain tiekartan päivämäärää. Palveluntarjoaja saattaa tukea rajapintaa, vaikka sen portaali näyttäisi edelleen vanhaa, paikallisesti laskettua arviota.
Jos käytät hallinnoitua tilaussovellusta, anna palveluntarjoajan huolehtia rajapinnan toteutuksesta, ellei sinulla ole painavaa syytä räätälöidä sitä. Rinnakkaisen laskentapalvelun rakentaminen luo uuden järjestelmän, joka on synkronoitava. Räätälöity työ on järkevämpää silloin, kun tilaussääntösi ylittävät sovelluksen tukemat työnkulut.
Suunnittele muutosprosessi lasketun esikatselun ympärille
Suosittelemamme prosessi alkaa, kun asiakas ehdottaa muutosta. Integraatiosi pyytää laskelmaa ja vastaanottaa tuloksen. Käyttöliittymä näyttää tämän jälkeen asiaankuuluvat loppusummat ja toimitusvalinnat ennen kuin asiakas vahvistaa muutoksen.
Esikatselu ei ole tallennettu muutos. Käyttöliittymän tulisi tehdä tämä ero selväksi. Älä näytä onnistumisviestiä vain siksi, että laskelma palautui onnistuneesti.
Vahvistuksen jälkeen varmista, että tallennus onnistui, ja näytä päivitetty sopimus. Jos tallennus epäonnistuu, säilytä alkuperäinen sopimus ja kerro, ettei pyydetty muutos ole astunut voimaan.
Varoitukset vaativat myös tarkkaa käsittelyä. Rajapinnan julkistuksen mukaan esikatselut sisältävät varoituksia, mutta se ei määritä kauppasi vastetta jokaiseen mahdolliseen varoitukseen. Anna kehittäjän kartoittaa todelliset vastaukset asiakaskokemuksen kannalta. Jotkut vaativat selitystä; toiset voivat olla syy pysäyttää muutos, kunnes ongelma on ratkaistu.
Ole yhtä huolellinen ajoituksen kanssa. Esikatselun tulisi kertoa, mihin tulevaan toimitukseen tai laskutuskauteen muutos vaikuttaa, perustuen sovelluksesi tukemaan toimintaan. Älä lupaa välitöntä muutosta, jos kyseinen tilaus on jo siirtynyt toimitusvaiheeseen.
Vältä antamasta ymmärtää, että yksi esikatselu takaa jokaisen tulevan veloituksen. Myöhemmät muokkaukset tai muut tekijät voivat muuttaa sopimusta. Näytä se, minkä laskelma tällä hetkellä vahvistaa, kielellä, jota tilaaja ymmärtää.
Testaa hankalat tapaukset ennen onnistuneen polun hyväksymistä
Onnistunut tuotevaihto on välttämätön, mutta se ei riitä julkaisun hyväksymiseksi. Rakenna pieni testitaulukko säännöistä, joita kauppasi todellisuudessa käyttää. Nämä ovat suositeltavia testejä, eivät lupauksia automaattisesta rajapinnan kattavuudesta.
- Määrämuutokset: Vertaa yksinkertaista lisäystä muokkaukseen, joka ylittää toimitusrajasi.
- Tuotevaihdot: Testaa korvaamista erihintaisella tuotteella ja tuotteella, jolla on erilaiset toimitusrajoitteet.
- Toimintoriippuvaiset tuotteet: Varmista tuettujen nippujen tai ostoskorimuunnosten toiminta laskennan ja tallennuksen kautta.
- Poistuneet vaihtoehdot: Tarkista vaste, kun pyydetty toimitusvaihtoehto ei ole enää voimassa.
- Ristiriitaiset muokkaukset: Anna asiakkaan ja asiakaspalvelijan yrittää muutoksia samaan sopimukseen samanaikaisesti.
- Keskeytyneet pyynnöt: Kokeile uudelleen aikakatkaisun jälkeen ja vahvista, ettei integraatio tee samaa muutosta kahdesti.
- Laskutusrajat: Testaa muokkausta lähellä uusiutumisajankohtaa käyttäen sovelluksen dokumentoitua katkaisukäyttäytymistä.
Säilytä jokaisesta tapauksesta esikatselu ja tallennetun sopimuksen tulos. Jos testiohjelmistosi tukee sitä, vertaa niitä laskutuksen lopputulokseen. Kirjaa ylös mahdolliset erot ja niiden selitykset.
Julkaisun esteenä tulisi olla näiden vaiheiden välinen yhteensopivuus testatuissa olosuhteissa. "Pyyntö onnistui" on liian heikko peruste. Sinun on tiedettävä, että asiakas hyväksyi saman muutoksen, jonka järjestelmäsi tallensi.
Toinen päivitys auttaa yhdistämään tilaustilaukset sopimuksiin
Toinen lokakuun julkaisu käsittelee pienempää integraatio-ongelmaa. Shopify kertoo, että Orders-webkookien rivinimikkeet sisältävät nyt selling_plan_id-tunnisteen API-versiosta 2026-10 alkaen.
Kenttä yksilöi tilausriville sovelletun myyntisuunnitelman (selling plan). Se on tyhjä (null) rivinimikkeille, joihin ei liity myyntisuunnitelmaa. Aiemmin tätä tietoa tarvitseva integraatio joutui tekemään erillisen Admin API -kutsun; nyt arvo saapuu webkookin hyötykuorman mukana.
Kauppiaan kannalta hyödyllinen kysymys on, tekeekö tilaustenkäsittelyintegraatio yhä ylimääräisen kyselyn. Pyydä kehittäjää tarkistamaan asia siirryttäessä kyseiseen API-versioon. Turhan pyynnön poistaminen voi yksinkertaistaa käsittelyprosessia.
Pidä kentän merkitys rajallisena. Myyntisuunnitelman ID ei korvaa tilaussopimusta tai kattavaa laskutushistoriaa. Tarkista sekalaisessa ostoskorissa jokainen rivinimike erikseen sen sijaan, että käsittelisit koko tilausta yhtenä tilauksena.
Valitse siirtymän laajuus toiminnallisen riskin mukaan
Priorisoisimme kauppoja, joissa asiakkaat vaihtavat tuotteita säännöllisesti, joissa asiakaspalvelu korjaa tilausmuutoksia manuaalisesti tai joissa räätälöidyt toiminnot vaikuttavat sopimukseen. Näillä kauppiailla on konkreettinen työnkulku, jota parantaa.
Kaupassa, jossa on kiinteät tilaukset eikä itsepalvelumuokkauksia, työ voi olla vähemmän kiireellistä. Vahvista sovellustoimittajan suunnitelmat ja testausaikataulu, mutta älä tilaa räätälöityä uudelleenrakennusta vain siksi, että Shopify julkaisi uuden rajapinnan.
Pidä tämä siirtymä erillään suurista hinnoittelumuutoksista, jos mahdollista. Muutoin odottamattomien loppusummien diagnosointi vaikeutuu. Käytä hallittua julkaisua siellä, missä integraatiosi sen sallii, ja sovi tavasta keskeyttää muokkaukset säilyttäen samalla nykyiset laskutustoiminnot.
Seuraa epäonnistuneita muutoksia ja asiakaspalvelun yhteydenottoja, jotka koskevat odottamattomia uusiutumissummia ennen julkaisua ja sen jälkeen. Nämä ovat hyödyllisempiä mittareita kuin pelkkä rajapinnan käyttöönotto. Nimeä joku tarkistamaan Shopifyn kehittäjien muutosloki yhdessä sovellustoimittajan kanssa, jotta myöhemmillä versiopäivityksillä on vastuuhenkilö.
Yhteenveto
- SubscriptionContractCalculation esikatselee sopimusmuutokset Shopifyn kassamoottorin kautta ennen muutosten tallentamista.
- Pyydä tilauspalveluntarjoajaltasi demo kauppasi sääntöjen toiminnasta, älä tyydy pelkkään rajapintatuen vahvistamiseen.
- Testaa esikatselua tallennettua sopimusta ja laskutuksen lopputulosta vasten, erityisesti uusiutumispäivien kohdalla.
- Käytä uutta selling_plan_id-webkook-kenttää siellä, missä se poistaa ylimääräisiä kyselyitä, mutta älä sekoita sitä sopimustunnisteeseen.
Lähteet
- Orders webhooks now include selling_plan_id on line items
- New SubscriptionContractCalculation API for subscription management
- Recent changes to Shopify's platform
Haluatko meidän hoitavan tämän?
Olemme Shopifyn Premier-toimisto ja teemme tätä työtä päivittäin: suorituskykyä, konversio-optimointia ja kaupparakennelmia, jotka maksavat itsensä takaisin. Varaa ilmainen kaupan katselmus, niin näytämme kolme ensimmäistä korjausta, jotka toteuttaisimme.
Usein kysyttyjä kysymyksiä
Mikä on Shopifyn SubscriptionContractCalculation-rajapinta?
Se on rajapinta, joka ajaa tilaussopimusten muokkaukset Shopifyn kassamoottorin läpi. Kehittäjät voivat esikatsella laskettuja loppusummia, toimitusvaihtoehtoja ja varoituksia ennen muutosten tallentamista. Se tukee myös Shopify Functions -toiminnallisuuksia sopimuslaskelmien aikana, mukaan lukien ostoskorimuunnokset ja toimitusmuokkaukset.
Pitääkö Shopifyn kauppiaiden siirtyä SubscriptionDraftista välittömästi?
Shopify suosittelee siirtymistä SubscriptionContractCalculation-rajapintaan, mutta kertoo SubscriptionDraftin pysyvän saatavilla. Vanhempi rajapinta ei tue uusia ominaisuuksia. Kauppiaiden tulisi kysyä tilaussovelluksen tarjoajalta toteutuksesta ja testauksesta, sen sijaan että olettaisivat välittömän kauppakohtaisen muutoksen olevan tarpeen.
Näyttääkö tilaussovellukseni automaattisesti lasketut muokkausesikatselut?
Rajapinnan julkistus ei tarkoita, että jokainen tilaussovellus hyödyntää uutta ominaisuutta. Palveluntarjoajasi on toteutettava laskentaprosessi ja tuotava tulokset asiakas- tai ylläpitoliittymään. Pyydä demonstrointia kauppasi tilaussäännöillä.
Mitä selling_plan_id tarkoittaa Shopifyn tilaus-webkookeissa?
API-versiosta 2026-10 alkaen Orders-webkookin rivinimikkeet sisältävät selling_plan_id-tunnisteen, joka yksilöi käytetyn myyntisuunnitelman. Arvo on tyhjä (null) niille rivinimikkeille, joihin ei liity myyntisuunnitelmaa. Se voi poistaa tarpeen erilliselle kyselylle, mutta se ei korvaa tilaussopimusta.
