Learn how to use Stripe Payment Links with Twilio and Airtable to prevent customers from sharing credit card numbers over the phone.
Developer Advocate CJ Avilla (@cjav_dev) returns to the stream to teach me new ways of using Stripe Payment Links to keep credit card numbers secure. We had fun recreating a scenario where a customer calls a small business to order a bike. The business owner — me in this hypothetical case — sends a text message to the customer using Airtable’s Twilio integration. The customer then pays via the browser on his / her phone and the sale is logged in Stripe and also Airtable. All joking aside, using Stripe Payment Links to collect customer credit card information is safer than asking customers to share credit card details by phone or in an email.
Stripe empowers businesses around the world to accept payments and make payouts.
Stripe Payment Links are persistent ways to collect money for a given product over and over. They can be shared on a website, via Twitter, a Slack message, or text message. It’s quick and easy for recipients to then provide their credit card information via the link.
Stripe continues to launch more and more no-code friendly tools and services.
From florists, to restaurants, to fuel delivery companies where CJ lives, many businesses still take credit card information over the phone. If you are a business who does, this workflow can help you streamline your business. This workflow is also for anyone who currently uses Stripe and would like to learn how to send information to another system via webhooks.
To follow the featured workflow, you will need accounts on the following services:
This scenario can be adapted to send a message via email or Slack instead of via a text message.
While it may look like a lot of steps, it’s possible to build this workflow in under 45 minutes. We’ll be building, refining, and testing as we go.
Our base initially consists of four tables:
Prices are the fundamental building block in Stripe and our goal should be to ensure that the products in Stripe mirror what’s in our base.
We then created a Payment Link in Stripe.
After creating a Payment Link, it was time to update our bike in the Products table in Airtable. We also worked on linking the various tables to one another so that we could track conversations with our customers and ultimately tie received payments to a customer.
With a customer phone number and Payment Link, it was now time to create an Airtable automation to text customers using Airtable’s Twilio integration. As much as I like buttons, we are using a checkbox field as the trigger due to a limitation with how Airtable automations run.
Since we want to tie a payment back to a customer and a conversation, we need to add a query parameter to the Payment Link sent to the customer. In this case, we use “?client_reference_id=” and the Airtable Record ID.
Our customers are making payments in Stripe, but all our other information is kept in Airtable. So that we don’t have to go back and forth between Airtable and Stripe, we’ll use a webhook to programmatically listen for events taking place in Stripe and then send relevant updates to Airtable. To do this, we’ll start creating a "when webhook received" automation in Airtable. We’ll then take the URL provided by Airtable and paste it into Stripe as a new webhook endpoint.
For the purposes of the stream, we chose to watch for “checkout.session.completed” events. Depending on your use case, you may also want to watch for “checkout.session.async_payment_succeeded” events.
Tip: Create a new webhook in Airtable for each unique payload. Do not try to use the same Airtable webhook if payloads are in different formats.
Before moving on, we ran tests to ensure that data was flowing properly. This included looking to ensure that the “client_reference_id” value was being passed.
In the prior step, we started a “when webhook received” automation, but didn’t specify what should happen when data was returned. Now that Airtable and Stripe are connected, it’s time to finish the automation so that our Payments table contains the reference ID, amount, email, payment intent ID, and a link to the relevant conversation.
With data flowing into the “Conversations” table, it was time to turn the “Name” field into a meaningful primary field. We also wanted to be able to see the amount paid in US dollars, instead of pennies. Last, but certainly not least, we added in a payment status.
After all the building, it was time for one end-to-end test to ensure everything worked. We also talked about limitations and ways to adapt the workflow.
If you use this workflow to accept payments or help another business more securely handle payments, let me know. If you'd like to learn more about webhooks, check out Code Meets No-Code.
Additional links in the YouTube description for this video.
.svg){kind=icon}
