Buy button is invisible - why?

It works!

I have a new Google sheet now called Sales Summary and it is a clone of the hidden Sales sheet. I should be able to use this in a number of ways. For example, I can have an action that checks ‘IF the newest row contains User info THEN do something to unlock feature access’. Or I could have an Admin screen that simply reads the list in the Sales Summary; tapping on an item does something…

Thank you!

1 Like

Let us know if you need any further help.

Does each user purchase only once? If so you can use their email to make a relation, I guess.

Yes that’s right. They do. But I had the following in my mind:

I read on the threads there is a risk that users change their email just before payment. Honestly, it’s something I do all the time since the account where I run the app is likely to be different from where I manage payments.

Hence, I’m thinking a safer way is to pass the Row ID of the User (Template column:User’s row ID) to Stripe in one of the Buy Button’s fields, e.g. the Product description (SKU). When that lands in the Sales sheet I can relate it back to the User sheet in order to identify who just paid.

Just one question, since my User Sheet has row owners activated for the email column, won’t this make it impossible for an Admin to push a value into user’s row that confirms payment? Or is there a more automated way to trigger a change in the user’s sheet (corresponding to the user that just made a payment?)

So just discovered it’s impossible to pass the Row ID of the user (or other unique info) to Stripe and then into the Sales sheet. None of the button fields will accept a dynamic computed column. Shame. It will be risky to rely on just the email address since I don’t have a Pro App (yet) and cannot see email addresses!

The best workaround I can think of is to write a time-stamp when any user opens the buy screen. Since I don’t have many users, if someone makes a purchase I can probably identify the correct user by looking for the one that has a time-stamp that is closest to the payment confirmation time. That info plus any name clues in the email used should be OK. Not ideal!

2 Likes

This is more tricky, but I think there’s still a way out. I’m thinking it this way:

  • You have a button to add a row to a helper table. Let’s call the button “Start payment process”.
  • That row will contain the signed-in user’s email and ID, in normal columns (when you use an add row action you add those to the right columns). You also add whatever things you need for the buy button (title, price etc).
  • In the table linked to the screen you were having the button, have a relation using the user’s email/ID to the helper table, then a single value returning the last “whole row”.
  • After the add row action in the “Start payment process” button, show details screen of the last “whole row” returned above.
  • Show the buy button there, you should be able to have the user’s email and ID to use.

My only concern is if the relation is created in time for the navigation to work.

2 Likes

You have to write values to static columns using action, before showing the buy button… or use the custom buy button… and google scripts to connect with stripe…
i have a working script and webhook, that will write transactions back to google sheets and can be read by App… with no extra fees! :wink:
if anybody is interested… contact me. It comes with 2 scripts and 1-hour installation help over Zoom… $155

2 Likes

Ok I think I cracked it. How to get instant notification when a user buys something using Stripe (caveat: you need to have an App with a Google sheet).

  1. When the User completes the sign in process I add a row to Glide Table called BUY.
  2. I set columns in this new row with all of the info needed to buy an item (description, price, image, etc…) plus some USER ID data (Row ID from the user sheet).
  3. When the user enters the shop screen I show an in-line list that reads the data in the BUY table and presents the items that can be bought. Importantly this list is filtered by the current user using the USER ID column.
  4. If the user wishes to view the item then they tap the item in the list, which has the action to Show details screen for this item.
  5. The next screen is then beautifully focused on the current user. A buy button can be added to the screen, which crucially will use the USER ID as the Product Description (SKU).
  6. When the user buys the item, the product description - aka the USER ID - will be received by Stripe and the wonderful thing is that STRIPE passes this back to Glide pending a successful transaction (into a Google sheet)
  7. ThinDinh helped me clone the hidden Google sheet (see above thread)… I have a Google sheet called SALES RECORDS.
  8. Now my app can access all the sales data and filter by user. Hence, after purchase the User hits back key and the previous screen will now display an updated list of Purchase transactions using an in-line list that reads the SALES records (filtered for the current user and sorted Z-A by sheet order).

In my App there is only 1 thing to buy: Credits. I can simply count the number of credits bought and track via simple accounting if they have credits left to access features.

Thanks for everyone’s help!

3 Likes

you don’t need to add a user ID, stripe is passing user email… most important is to add an order ID to relate it with your record of sale in glide… if you have multiple items in the cart, you can add also joined row IDs for items to adjust inventory and shipping rates

Disagree. The user can modify the email field just before payment. Something quite likely to happen since people often use a different email for financial transactions. Much safer to use a row ID in a fixed field. Plus, what if you don’t collect real email addresses?

no, the user ID is irrelevant, once you have an order id… you can easily connect the user with glide order and stripe payment… the same user can pay multiple times… so you would have to create multiple user IDs

Nope. The order ID has no information in it that connects it to the buyer apart from a very risky email address. Think again.

order ID is the ID of the whore record of sale… that contains user ID in it… you gonna have problems with multiple orders

What user ID?

the USER ID as the Product Description (SKU). that is what you describe in your post

You have lost me. You are telling me to do what I described?

I have validated it for multiple test orders. It works perfectly.

ok… if it works for you… then good… I don’t know the details of your algorithm… I’m just saying from what you describe… it won’t work with multiple orders from the same user… it will always show the last one… and hopefully, they won’t check out 2 carts at the same time… keep in mind that stripe link has 24 expiration time… that’s why I always send expire order to stripe after 3 minutes from creating a link… and delaying actions in glide

Red herrings. The process works. All successful purchases are captured in the SALES RECORDS table and can be perfectly mapped back to the buyer.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.