There comes a time in any young app’s life when it will have to monetize. There are a number of ways to become profitable, but accepting cash is a surefire way to make this more direct. In this four-part tutorial, we’ll go over how to set up a serverless function, make it talk to the Stripe API, and connect it to a checkout form that is setup as a Vue application. This may sound daunting, but it’s actually pretty straightforward! Let’s dig in.
What is Serverless?
We’ve covered serverless concepts before but, in case you haven’t read that article, let’s talk for a minute about what we mean by “serverless” because it’s a bit of a misnomer.
The promise of serverless is to spend less time setting up and maintaining a server. You’re essentially letting the service handle maintenance and scaling for you, and you boil what you need down to functions that run certain code when a request is made. For this reason, people may refer to this as FaaS. This is really useful because you pay for what you use, rather than a large container that you might not need in its entirety. You also primarily hunker down and focus just on the code you need to run instead of babysitting a server, which really appeals to a lot of people who’d like to get up and running quickly.
But FaaS isn’t always the right tool for the job. It’s really useful for small executions but, if you have processes that might hold up resources or a ton of computation, being able to communicate with a server as you normally do might be more efficient.
What we’re going to make is a perfect use case for going serverless. Stripe checkouts are pretty seamless to integrate on both the client and server side, but we do actually need to execute some logic on the server, so we’ll use Azure to help us with this. The portal and Github integration are pretty quick to manipulate, as long as you know where to go. So by all means, let’s make it happen!
Sign up for Stripe
First, we’ll create a Stripe account. We verify our new account via email and then we’ll head over to the API section, where we can retrieve two keys. You’ll note that we’re in test mode right now, which is good! We’ll keep it like that for testing, and unveil the testing key token to use while we set up the application.
Once you’re signed in, go to the API section of your dashboard to retrieve your key.
You may also want to add a phone number to your account for 2 factor auth as well.
Setting up Our Serverless Function in the Azure Portal
When we click on the Serverless Function app, we’ll be taken to a panel that asks for details to help with the setup. As you can see in the screenshot above, it will autofill most of the fields just from the app name, but let’s go over some of these options quickly:
- Add in a unique name
- A Resource Group (if you don’t already have one, create one)
- I use the Windows OS because the Linux is still in preview, so Windows will be more stable
- I use the Consumption Plan because this is the one that will have payments that scale with the use, and it will also scale automatically. The other option, App Service Plan, is good for people who prefer everything to be a bit more manual.
- Choose a location that is close to your customer base, or a midpoint between two customer bases
- Choose a storage, or create one as I’ve done
- I’ll also check Pin to Dashboard because I want to be able to retrieve my function quickly later
This will bring you back to the main portal dashboard and let you know that your function is deploying. Once it’s done, it take you to a main screen that has all of your options. From here, we’ll want to create our function, and it will be an HTTP trigger.
We’ll select Functions under our function name, and you’ll see a little table with a plus that says “New Function”:
Once we click here, we have a few options on what we can create. We’ll pick HTTP Trigger:
The Default Testing Function
From here, we’re given a default testing function which helps us see how this all works. If we open all of these panels and hit the Run button, we’ll see the output in logs.
Here’s the code we were given:
You’ll see here that we’re passing in the
context. That allows us to log, which will be shown in the lowest panel below. In the Test panel on the right, we can pass in a request body that can be used to test our application. When it runs, we see the output with a 200 status and know that everything is working. We also have a
context.log for the case that it gives us a 400 error. If you’d like to play around with a serverless function and see it in action for yourself, you can create one with a free trial account.
Now that we have the base of our serverless function, let’s set up what we’ll need to communicate with Stripe! More to come in the next post in this series.