How we made billing backendless

Summary

We think handling payments on the frontend is a better developer experience.Typically, billing is a backend job and requires webhooks, state syncing, then passing the data to the frontend. We wanted to offer a more "out-of-the-box" experience when handling things like payment links, paywalls and up/downgrade flows, and spent a bunch of time thinking about how we can perform sensitive operations without needing to perform the "round trip" to the backend.This is a short write up of our exploration around the problem and why we ultimately are giving up.Part 1: The Publishable KeyWhen we launched, we had a secret key that could be used securely from the backend just as Stripe does. Many of our first users had actually never set up Stripe before, and immediately told us they wish they could just do it from the frontend.Our first solution was to create a "publishable key" which would let developers get payment links and check feature access (eg, does my user have any remaining credits) directly from the frontend, in an unprotected way. These functions alone can't really be abused.The initial response was good and people were happy to use it with their initial set up. But we quickly ran into a couple problems:It only worked with some endpoints (eg, tracking billable usage events had to be done via the secret key) and ended up confusing devs around which endpoints could be used with which keys.Most software billing flows allow you to automatically purchase something if you've made a purchase before. This automatic purchasing (eg for upgrades) definitely couldn't be done with a public key.Although it helped people spin up a sample integration fast, it quickly had to be ripped out anyway, so ended up being pretty pointless.This still exists in our docs today and constantly trips people up. Can't wait to get rid of it.Part 2: Server ActionsWhen we launched our Next.js library, we were excited to use server actions. The DX felt magical because users could:Call them from the fro...