How we made billing backendless

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 Key

When 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:

1. 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.

2. 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.

3. 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 Actions

When we launched our Next.js library, we were excited to use server actions. The DX felt magical because users could:

1. Call them from the frontend like any normal function

2. The functions run on the server and can access our secret key stored as an ENV variable

3. No route set up needed, and the request is secure — nice!

Unfortunately we soon discovered our approach was flawed. Server actions are public, unauthenticated routes, and our API calls updates resources based on a customer_id field (eg. upgrade / downgrade requests, tracking usage for a feature, etc).

So if you got a hold of someone else’s customer ID, you could make requests to the public server actions as if you were that customer—making this method insecure.

Part 3: Server actions + encryption

We really really liked the DX of server actions though, and so we had to brainstorm a way to overcome the customer ID being expoed in server action routes.

A few options came to mind, like using a middleware, or registering an authentication function, but the cleanest and simplest method we thought of was simply encrypting the customer ID:

Here’s how it worked:

1. Our Provider was a server component, and so it’d take in a customer ID/user ID (server side), encrypt it using their API key, and pass it to context on the client side (see image below)

2. We wrap each server action with a client side function which grabs the encryptedCustomerId from context and passes it to the server action. These are all exported through a hook — useAutumn

3. Each server action first decrypts the customer ID then calls the Autumn API

Essentially, we baked our own layer of auth into the server actions, and this is how our Next.js library works today. I haven’t seen this approach by anyone else but essentially lets us fully handle secure payments, upgrades, downgrades, usage-based billing events — all from the frontend.

We’re still not fully satisfied since this only works with frameworks that support server actions and SPA / vite is kinda making a comeback. It also makes the implementation different across frameworks.

The future

Ultimately I think we’ll reach a point where we give up on this approach, and move towards a more framework agnostic approach. Rather than trying to abandon the backend route setup, we’ll just make it easy to do. Take better-auth and how they generate their backend routes in just a couple lines of code — they’ve standardised the backend and frontend installation, and is pretty hard to get wrong.

Other companies like Polar have a similar approach and are heavily praised for it. We probably don’t need to reinvent the wheel (as fun as it is).

Keep your files stored safely and securely with the SanDisk 2TB Extreme Portable SSD. With over 69,505 ratings and an impressive 4.6 out of 5 stars, this product has been purchased over 8K+ times in the past month. At only $129.99, this Amazon’s Choice product is a must-have for secure file storage.

Help keep private content private with the included password protection featuring 256-bit AES hardware encryption. Order now for just $129.99 on Amazon!

Help Power Techcratic’s Future – Scan To Support

If Techcratic’s content and insights have helped you, consider giving back by supporting the platform with crypto. Every contribution makes a difference, whether it’s for high-quality content, server maintenance, or future updates. Techcratic is constantly evolving, and your support helps drive that progress.

As a solo operator who wears all the hats, creating content, managing the tech, and running the site, your support allows me to stay focused on delivering valuable resources. Your support keeps everything running smoothly and enables me to continue creating the content you love. I’m deeply grateful for your support, it truly means the world to me! Thank you!