Paddle vs Polar.sh za AI naročnine in obračunavanje na podlagi uporabe

Torej, zgradil sem ta mali SaaS imenovan GrandpaCAD. Ideja je preprosta: moj dedek obožuje 3D tiskanje, vendar sovraži kompleksno programsko opremo za modeliranje. Z GrandpaCAD preprosto opišeš, kaj želiš, in AI izpluje 3D model. Preprosto.

Da bi zaračunaval za to, sem potreboval naročnine plus obračunavanje na podlagi uporabe za AI kredite. Enostavno, mar ne? Narobe.

Zakaj ne bi uporabil samo Stripe?

Vsi to vprašajo. Poglej, prihajam iz Slovenije. Tukaj mora biti vsak posamezen račun "fiskalno verificiran." To pomeni integracijo z vladnim API-jem, ki je dokumentiran v 119-stranski PDF datoteki. Ne, ne hecam se. To je birokratska mora certifikatov, skriptov po meri in bolečine.

Da se izognem tem težavam, sem potreboval "Merchant of Record" (MoR). Oni uredijo vse davčne in izdajanje računov namesto tebe. Paddle je veliko ime, za katerega sem slišal že leta, zato sem začel tam.

Moj 5-dnevni potep v pekel s Paddle

Priznal bom Paddle-u naslednje: njihova dokumentacija je fantastična. Njihova "Setup checklist" in "Go-live checklist" sta resnično uporabna. Občutek sem imel, da sem v dobrih rokah.

Ampak potem sem poskusil implementirati obračunavanje na podlagi uporabe.

Preživel sem 4-5 dni v boju z njihovim sistemom in preprosto nisem mogel doseči, da bi deloval normalno. Webhooks so bili kompleksen nered. Ampak prava zadeva, ki je preprečila dogovor, je bila nekaj veliko slabšega.

Paddle-ovo obračunavanje na podlagi uporabe je fundamentalno pokvarjeno.

Tukaj je problem: ko uporabnik prekliče svojo naročnino, Paddle preprosto... oprosti vso uporabo, ki so jo nakopičili. Puf. Izginilo.

Njihova dokumentacija predlaga "rešitev": ko uporabnik klikne tvoj gumb "cancel", najprej sproziš takojšnjo zaračunavanje njihove uporabe in šele nato prekliceš naročnino.

V redu, ampak kaj pa portal za stranke? Paddle daje strankam portal, do katerega lahko dostopajo prek e-pošte, da upravljajo svojo naročnino. Če tam prekličejo, nimaš nadzora. Ne moreš injicirati svoje logike "najprej zaračunaj".

Torej bi lahko katerikoli uporabnik:

1. Ustvaril račun.
2. Uporabil kup dragih AI kreditov.
3. Preklical prek portala za stranke ravno pred datumom zaračunavanja.
4. Plačal nič za uporabo.
5. Ponovil.

To ni majhna napaka; to je izkorišček, ki lahko uniči podjetje in čaka, da se zgodi. Za AI SaaS, kjer uporaba stane resnični denar, je to bilo nesprejemljivo.

Vstopi Polar.sh

Frustriran in brez časa sem iskal alternative in naletel na polar.sh. To je novejši igralec in bil sem nekoliko skeptičen. Ampak, kakšna razlika.

Tukaj je kratek pregled mojih izkušenj:

• Preprostost: S Polar sem obdelal vso logiko naročnin z enim samim onSubscriptionUpdated webhook-om. Bilo je čisto in preprosto. Paddle se je zdelo, kot da potrebuje celo konstelacijo webhook-ov, da naredi isto stvar.
• Obračunavanje na podlagi uporabe: Preprosto deluje na Polar. Brez čudnih lukenj. Poročaš uporabo, oni zaračunajo. Konec. To je točno to, kar bi pričakoval.
• Developer Experience: Polar ima integracije za različne okvire. Uporabljam better-auth in imeli so knjižnico pomočnikov zanj, ki je zadeve še olajšala.
• Strošek: Polar.sh je 20% cenejši od Paddle. To ni nič.

Slabosti novinarja

Ni vse sončno in mavričasto. Lahko vidiš, da je polar.sh nov otrok na bloku. Naletel sem na nekaj čudnih napak.

Dobra novica? Njihova ekipa je noro odzivna na Discordu. Slaba novica? Njihova ekipa je noro odzivna na Discordu. To pomeni, da ko sem googlal svoje napake, nisem našel ničesar. Rešitve so bile zakopane v Discord pogovorih. Rajši bi našel odgovore v javni dokumentaciji, kot da moram vprašati na strežniku za klepet, ampak hej, vsaj hitre odgovore sem dobil.

Problemi novinca

V zadnjih nekaj mesecih sem naletel na več problemov, ki jih želim izpostaviti:

• V API-ju je več nedoslednosti in nedokumentiranih obnašanj. Porabil sem veliko časa za ugotavljanje. Na primer, naročnina z merjeno uporabo se obnaša drugače kot samo naročnina. Še posebej v primeru, kjer uporabnik želi najprej dopolniti nekaj kreditov in nato preklopiti na naročnino. Merjena naročnina bo ponastavila njihove kredite, nemerjena pa ne. In takšnih primerov je več.
• Sandbox deluje precej slabo - nikoli nisem dobil kreditov, ki so mi bili odobreni kot rezultat nakupa naročnine. Nisem prepričan, če je to le napaka sandbox-a, ampak tako sem se boril z implementacijo, da sem morал zadržati posodobitve cen, dokler ne rešijo tega. Preprosto ne morem razvijati, ko stvari delujejo drugače vsakič. In potem sem 10 minut kasneje dobil kredite?
• Checkout povezave spreminjajo obnašanja platforme. Iz nekega razloga sem dobil drugačne rezultate, ko sem izvajal checkout prek povezave, ki sem jo generiral prek nadzorne plošče, kot pa ko sem izvajal checkout prek povezav, ki jih je generirala moja integracija.
• Pomembno za ljudi, ki načrtujejo prodajo v Evropi: Ne moreš nastaviti cen z vključenimi davki. To pomeni, da bodo vaši uporabniki verjetno videli cenovnik "100.00 € + DDV" in ne "120.00 €", kot bi pričakovali. To je lahko precej nadležno, ko ljudje vidijo eno ceno na strani s cenami in drugačno na strani za blagajno.

Sodba

Potem ko sem zapravil teden s Paddle, sem Polar.sh integriral in spravil v delovanje v enem dnevu.

Paddle je morda zrela platforma z odlično dokumentacijo, ampak za moj primer uporabe - obračunavanje na podlagi uporabe za AI SaaS - ima usodno napako. Njihov sistem uporabnikom omogoča, da se enostavno izognejo plačilu za merjeno uporabo, kar je preprosto nesprejemljivo.

Polar.sh, kljub svoji mladosti in občasnim grobim robovom, ima osnove pravilno. Njihova implementacija obračunavanja na podlagi uporabe je trdna, izkušnja za razvijalce je boljša in je cenejša.

Če gradiš SaaS z obračunavanjem na podlagi uporabe, prihrani si glavobol. Resno preuči polar.sh. Ni popolna, ampak deluje, kjer je pomembno.

Edit: Od takrat sem želel posodobiti cenovno integracijo in se tako boril, da sem moral to zadržati, dokler njihova ekipa ne reši nekaterih težav. Ena od njih je dokumentirana v tem github issue