Never Take a Credit Card Over the Phone Again

Learn how to use Stripe Payment Links with Twilio and Airtable to prevent customers from sharing credit card numbers over the phone.



Getting Started with Stripe Payment Links

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.

About Stripe

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.

Who this video is for and what you’ll learn

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.

How to follow along

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.

Let’s get into it

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.

Step 1: Set Up Our Airtable Base (10:51)

Our base initially consists of four tables:

  • Customers
  • Products
  • Conversations
  • Payments

Step 2: Create a Product in Stripe (13:18)

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.

Creating a Product in Stripe
While a product can have multiple prices, we ultimately want every product to have a price that is associated to a Payment Link.

Step 3: Create a Payment Link in Stripe (16:24)

We then created a Payment Link in Stripe.

Screenshot of Creating a Payment Link in Stripe
Stripe Payment Links can be customized to match your brand colors.

Step 4: Update Tables in Airtable (18:10)

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.

Step 5: Create the Text Message Automation (20:49)

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.

Screenshot: Creating a Text Message Automation
Setting up an automation to text customers. Including a client reference ID is important for connecting a payment to a customer conversation.

Step 6: Configuring Our Webhooks (33:51)

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.

Screenshot: When Webhook Received Automation
Starting a “When webhook received” automation in Airtable. We'll finish setting it up in a later step.
Screenshot: Setting up a new webhook endpoint in Stripe
Taking the webhook created in Airtable and adding to Stripe

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.

Screenshot: Examining Stripe Payload
We'll need the client reference ID to tie everything together. Testing as you go can save debug time later.

Step 7: Update Airtable with Payment Info (46:19)

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.

Screenshot: Finishing the "when webhook received" automation
Finishing the "when webhook received" automation

Step 8: Updating the Conversations Table (47:44)

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.

Step 9: An End to End Test (52:06)

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.

Key takeaways

Similar streams