Public App + Custom Cart + Buy Button

I’m allowing public users (not logged in) to use a custom cart feature where they can assign a ticket they are buying to a friend or family member and also choose a user to get credit for the sale, for multiple tickets.

The problem I’m coming across is that the buy button doesn’t work with user specific columns so I’m passing them via actions to a sheet column. The problem is that when those values are passed, whoever is currently checking out has their buy button information changed.

Is there any sly workaround allowing public users the ability to do this without having to log in?

I was thinking there may be a way to use a form page and hide some default value fields?

@Robert_Petitto @Lucas_Pires

To be honest, I don’t have too much experience with but button & stripe.

However, even if we need to make payments, we need to think about terms & privacy. That’s why I have customized carts in my apps not using buy button or stripe, but they’re all public (with sign in action) or public with email apps, because since you need a minimal information, I think we need to pick something from our users

I would think you can assign a unique ID to a cart item, but also store that unique ID in a user specific column elsewhere. That way, the current user can only see and access the row that has the info filled into basic columns, but based on filtering from the USC column.

I did that in one recent app using Jeff’s method.

When they first open the app and opens any items I assign them a unique ID. Obviously this is not as accessible as a user profiles column but you can get around it with filtering.

All I have is a single row to store user-specific columns, including that unique ID. I built all tabs: cart, order etc on that row so I can filter things by a screen column.

Say cart => have an inline list filtering by guest ID is screen’s unique ID. Same for orders.


@Jeff_Hager & @ThinhDinh,

I am having the person type in their email address to view their orders and to make a new order, since they are unique values…

Once an email in entered, they get an inline list of items to buy and when clicked, that item is added to a cart row with all their item choices and the email they used.

My issue is moving them to the checkout screen since they aren’t really singed in, all i seem to have access to is the relation that is created from the current Item screen they are on to the cart screen. Which I can not for the life of me figure out how to get them to and filter only their items.

The item screen has all the user specific columns and the cart screen has all the sheet columns. This would work if I could pass them to their cart screen without seeing anyone elses order information but I can’t make sense of how to filter it out.

They enter email address into the item screen then choose an item, that item is then added to a cart tab and related back to the email they entered on the screen they are currently on. The only way i can currently pass them to the items they ordered is through a relationship that forces the next screen to be an inline list instead of a details screen where i can have them checkout all the items at once.

I know i must be missing something here…

I’m trying to get a mental visual, but if you have screenshots, that would help a lot. Hard to give you a direct answer, but it’s easy to create dummy relations (true=true, or something like that) so you can get access to a related sheet that contains a user specific email or unique ID and use it throughout the app. You may even need some dummy sheets to use as drivers for your tabs and use them to hold some basic user specific data. The details view of those tabs could then contain your lists to your items, cart, etc. All filtered by the user specific data.

1 Like

I could turn the cart page into the users current page then filter from there I guess, instead of having them “log in” on the item page. At least then I could have them only change their own row… I’ll try this and get back. Thanks for the help.


@ThinhDinh, I got the checkout process handled with a one to one relationship. This allows for a details screen where a one to many forces a list… Thank you both for your time.