Lessons Learned in Making Payments, Authentication, and Transactional Emails Actually Easy

I woke up today and had to write this post, as over the last few weeks my social feeds have exploded with a common message:

Integrating payments, authentication, and transactional emails is too hard.

This problem has clearly come to the forefront of the tech industry as of late for a simple reason—there’s been an explosion of non-technical people trying to build software. 

And as I’ve watched this all unfold, I’m seeing well intentioned Product Managers at big, heavily funded tech companies—many of them companies I admire very much—completely fumble the bag when it comes to how to solve this.

This is an opinionated post—and I know it’s also one that many (especially technical) people will scoff at. But I think this post will help someone or some company massively for two reasons:

• There’s a clear reason why everyone is fumbling with this problem
• If there’s any problem that we’ve solved at Outseta, this is it

As I’ve written before, the opportunity in solving this is massive.

I’m going to start with two paragraphs on my history with this problem, then we’ll get right into solution mode.

Solving the SaaS scaffolding problem for non-technical builders

When we started Outseta in 2016, we set out to make it easier for developers to launch a SaaS business. Everyone was cobbling together Stripe’s APIs, authentication tools like Auth0, transactional emails via Sendgrid, and also stuff like CRM and help desk solutions. While developers had the technical skill set to complete this work, setting up all the scaffolding required to build a SaaS product was still anything but easy. We saw the opportunity to build “Shopify for SaaS” and built it—software engineers were our initial target customer. 

Frankly, we struggled mightily—for about 3 years. But in the process, “no-code” building became popularized and we realized that non-technical builders had the same problems—but didn’t have the same technical abilities. Outseta was simply that much more valuable to them (good), but it was still a product built for developers (bad). We spent a solid year focused entirely on how to make it easy for non-technical builders to integrate payments, authentication, and transactional emails with their products. And we saw an immediate response once we solved it well—we hit our first major inflection point and revenue started to grow.

Now let’s get into why this has proven to be hard to solve, and how we solved it.

Technical people are bad at helping non-technical people solve technical problems

I’ll be very blunt here—technical people tend to be very bad at thinking like non-technical people. But to solve this problem, you must get into the mindset of a non-technical builder. 

Let me give you a reframe—while there’s certainly a sliding scale of “non-technical” abilities, you need to solve this problem for a user who doesn’t even know what a webhook or a transactional email is. 

Read that again.

You need to start with the assumption that “webhook” and “transactional email” are completely foreign terminology. They might as well be Swahili.

And I say this 100% seriously. I'd bet you that if I asked Outseta customers about transactional emails, probably 30%-40% them would reply with "What's a transactional email?" Yet 100% of our customers have products or sites that are sending out 17 transactional emails on their behalf. And I think that's what you actually want to be shooting for when building easier solutions for a non-technical audience—just make it work by default.

I know that if you’re a Product Manager at a Silicon Valley tech company, your head might have just exploded. I know you are well intentioned. I know that you know the benefits of user research. But it’s still just really—hard. You work at a software company and you think about these things on a technical level that the masses that you are trying to reach simply don’t. I know this because our team went through countless revisions of how to implement all this stuff and I was the non-technical bozo continually coming back to our engineering team and saying “Nope, not easy enough.” It became very apparent once it was.

So now on to solving the problem—let’s start with some constraints. These are the patterns that we’ve been able to prove at Outseta are actually “easy enough” for the non-technical masses. If you can build a way to integrate payments, authentication, and emails that doesn’t ask anything more of the end user—you’re cookin’.

This may sound very, very silly—but it works.

Appending links to buttons

The single biggest breakthrough in the history of our company came when we made integrating Outseta’s sign up and login forms as simple as tying a link to a button.

We ask our customers to add a “Sign Up” and “Login” button to their website, then link those buttons to links that we provide in their Outseta account.

‍

Yes, there are other ways you can integrate Outseta—everything from custom coding your own forms and calling our APIs, to using custom attributes to trigger pop-up forms, to embedding form code directly into your web pages.

But the magic happened when it was as simple as tying a link to a button—that’s a familiar pattern that a non-technical builder is comfortable with.

Copying and pasting scripts

The second pattern is copying and pasting scripts. This is where the really non-technical start to feel a bit of anxiety. We provide a single script that users need to add to the header of their projects or websites. This script enables almost all of Outseta’s functionality—it’s what makes the magic happen so to speak. All we ask of the user is that they drop a script into the header of their projects. This has also proven to be doable.

‍

The magic of Outseta (and similar tools) is that we’ve already written all of the code that connects your payments, authentication, and transactional email tools—that’s all packaged up in this script. Users don't need to sign up for Sendgrid at all—and while they do need a Stripe account, they don't need to configure anything within it.

For example:

• When someone signs up, they’re automatically sent a transactional email prompting them to set a password.
• If someone’s free trial ends, they’re prompted to pay at login.
• If someone is past due on payments, they’re emailed to update their payment information and asked for their payment information at login.

These are a few of the many workflows that need to be built between these tools—developers will recognize that. But Outseta is accessible to non-techincal customers precisely because they don’t need to do any of this stuff! This is where the hell I’m hearing about on my social channels starts.

This script also enables things like Outseta’s protected content functionality, and it’s worth mentioning that the behaviors of your site can be customized significantly by further configuring this script with Javascript (for our technical customers). 

But for our non-technical customers, it just works—a script pasted into the site header is a second familiar pattern.

Entering obvious inputs

Finally, you should feel comfortable asking users to input values into what are otherwise very obvious input fields. For example, we ask our customers to enter a price for their subscription plans ($99/month in this case). 

We also ask them to specify a URL when the user will be redirected after login (we call this the “Post Login URL.”)

Again, this is simply a pattern that’s comfortable and familiar for the non-technical masses!

What about prompting?

At this point you’re probably wondering why you’re reading this post. I’ve delivered earth shattering insights like how appending links to buttons, providing pastable scripts, and asking users to input basic fields of data into your software are accessible to non-technical builders.

Wow!

But as you’ve been trying to simplify the setup of payments, authentication, and transactional emails have you really tried to solve these problems within the bounds of these constraints? From what I’ve seen, the answer is a resounding “no.” Every Product Manager I’ve seen is thinking about this at far too technical of a level. It’s the webhooks, and the DNS settings, and the code modifications, and the API calls that’s tripping users up—I’ve lived through it thousands of times.

And all of this begs the question—what about prompting? 

After all, isn’t the promise of prompt based tools that they are easier for non-technical users because you can just describe what you want in plain language?

While the new form factor of prompting is intoxicating in the sense that it’s more natural and familiar, I would push Product Managers to more closely consider when it’s actually better. There are absolutely instances where it is, but I seriously question whether typing into a chat inbox that you want a $99/mo plan is actually any better than inputting $99 into an input field like the one I showed above.

The more wiggle room that you have with a chat based interface, the more opportunity you provide for things to go awry.

I don’t mean for this to be a case against prompting, which I see as a major step forward in many ways. I mean for it to be a call to not blindly assume that a prompt is the best user experience. I’ve also made my case for templated prompts being a major factor in getting non-technical builders to vibe code more successfully.

What about databases? I’m building something real.

While we figured out how to make payments, authentication, and transactional emails just work for our non-technical customers within the constraints I mentioned above, the next question I always get from developers is “What about integrating with my database?”

Our most non-technical customers use Outseta CRM as their database. They capture whatever information they want from users at sign up and a lot of other customer data is automatically captured and stored in Outseta, too. Users can then do things like create segments based on this data within Outseta, and can even display user data on their pages. Outseta CRM is certainly not a robust database by any means, but this serves many types of customers, websites, and basic web apps perfectly well—without requiring the user to know anything about databases.

As our customers get slightly more technical or need something closer to a true database, they might use something like Google Sheets or Airtable. Proceed further up the technical scale, and you’re looking at something like a Xano or Supabase. 

This proceeds all the way to our technical customers that are building traditional SaaS products (like our own business—Outseta uses a SQL database). At this point we provide an in-app “Sign Up Callback URL” field that we send user data to when someone registers for the first time. Here’s more on how Outseta integrates with a backend database for more technical users.

Asking users to cobble together point solutions doesn't work

I genuinely hope someone reads this post and takes it seriously—the lofty proposals that I’ve heard on how this is going to be solved are simply missing the mark if the objective is to make setting up digital products easy for the non-technical masses.

Whether you are a payments provider, an authentication tool, or the hottest vibe-coding platform on the planet there are a bunch of different ways that you can solve this problem.

But I firmly believe the solution doesn’t look like stringing tools together—and you’ll need to step out of Silicon Valley and onto Main Street to figure it out.