The community has periodic questions, and sometimes detailed discussions with links to many other resources, regarding how to enable in-app purchases. It’s indeed possible, and can be pretty comprehensive, but complex, with Apps Script and the robust APIs offered by payment processors.
As @juanpa has outlined, it’s also possible to implement in a thoroughly no-code manner. Here’s an illustrated description of one barebones technique. It uses Stripe for processing payments and Make for managing the confirmation of payment submission. (While Make is clunkier to set up than the often recommended Zapier, Make’s free tier is far more generous. See more from @Fabian_Weller regarding using Make with AppSheet.)
Steps
Stripe: Payment links
Create a payment link for each type of in-app purchase you want to make available to app users. These might be, for example, an app subscription for x months or access to a premium app feature. A single link can include multiple distinct products as separate line items.
For each link, you can either fix the quantity of each line item or allow the user to adjust the quantity. If you fix the quantity, then in your app you’ll be able to reliably show the user the quantity that is pending payment. If you allow the user to adjust the quantity, you’ll have an additional detail to reconcile after payment is submitted.
In this example, each payment link is for a different fixed quantity of the same single product.
For each link, you can include custom metadata. This can be helpful in many ways–especially in the following use cases:
- Within your app, you need to process different types of purchases differently (e.g., some are in a subscriptions table and some are in a premium features table).
- You need some but not all payments made through your Stripe account to be processed within your app (e.g., some payments are for in-app purchases and some are not).
In this example, one payment link’s metadata reflects that the link is for in-app purchases that are part of a category named “…credits”.
AppSheet: Tables
Items available for purchase
Create a table with a row for each type of in-app purchase you want to make available to app users. Include columns at least for:
- Name
- Price
- Payment Link URL
Other columns can also help you provide useful app features, such as quantity.
User purchases
Create a table with a row for each purchase. Include columns at least for:
- ID (table key)
- Reference to the “Items available for purchase” table
- Status (e.g., Pending, Canceled)
- Payment Link URL with a row-specific parameter
- This column allows you to later match a submitted payment to its row’s specific purchase. Use an Initial value expression to concatenate the Stripe payment link with the following URL parameter:
client_reference_id=*ID*. A few additional URL parameters are also available to track or prefill information and can be helpful, includingprefilled_email. Here’s an example of a full template:[https://buy.stripe.com/](https://buy.stripe.com/)*{Stripe payment link ID}*?prefilled_email=*{user email}*&client_reference_id=*{row ID}*
- This column allows you to later match a submitted payment to its row’s specific purchase. Use an Initial value expression to concatenate the Stripe payment link with the following URL parameter:
Other columns can also help you provide useful app features, such as timestamps and user.
Make: Scenario
Create a scenario that comprises at least the following modules:
- Stripe Watch Events: Receive webhooks posted by Stripe’s Checkout Session Completed event
- AppSheet Edit a Record: Update the user purchase row’s status (e.g., from “Pending” to “Paid”)
- For the row’s key, reference the
client_reference_id, which Stripe extracts from the row-specific payment link URL’s parameters and then includes in the webhook sent to Make.
- For the row’s key, reference the
Filters, additional modules, and other Make features can also help you manage your process, such as:
- Limit the scenario to Stripe payments made for in-app purchases
- Route purchases of different types to different AppSheet tables
- Handle multiple Stripe events, such as expired checkout sessions or delayed ACH payments
Tips to keep in mind while creating the scenario:
- If you’re creating separate scenarios using Stripe test and live data, name your connections and webhooks correspondingly to keep them straight.
- After creating the trigger module connected to Stripe, run the scenario once to have it load the webhook schema so that you can then reference in subsequent modules the schema’s values, such as
client_reference_id.
In this example, the (partially represented) scenario detects completed checkout sessions, filters out events not for in-app purchases, routes the flow based on the purchase category, and updates AppSheet table columns.
AppSheet: Actions
The following actions constitute the minimum to enable a user purchase journey.
- Purchase: Add a row to the “user purchases” table.
- Pay: Go to a website - Launch the row-specific payment link URL.
Other actions can also help you provide useful app features, such as:
- Email payment link: Start an email - Generate a draft email for the user to send the payment link (e.g., to someone else responsible for paying).
- Cancel purchase: Set the value of a column - Update a row value to reflect the purchase is canceled (e.g., to exclude the row from a list of purchases pending payment).
In this example, a user selects the “Purchase credits” action and after adding a row via a form view can complete the payment as well as perform other actions.
