Stripe Connect POSSIBLE – Thoughts & Ideas

Hey Everyone,
Stripe Connect is a must for us so here is my thoughts on integration I’m pretty much there but I’d love to take it one step further.

• Users “set up payouts” by a Make.com integration I have with Stripe API creating the link :white_check_mark:
• Users create products and using Make.com they can create a product in stripe under their Stripe Connect account :white_check_mark:
• Stripe returns a customized payment link for that user and that product with photos :white_check_mark:
• Users can purchase that product BUT are taken to a separate link :x:

Not an awesome UX that they’re taken to a separate link. So here’s my thought, let me know if this is secure or your thoughts.

• Everything included above in this scenario except the last step.
• Users enter Credit Card upon registration (we’re selling tickets not products)
• Trigger webhook to send connect to Stripe API to create a charge on the card to purchase the product in Stripe
• Users Credit Card number clear immediately from glide for security purposes
• User and Seller are alerted of purchase…so on and so fourth.

Thoughts? Thanks in advance!

Create products in Glide, then just one Google script to take care of integrations… no need for going back and forth with Make

So is it secure to take the CC # through glide?

if you record them in row owners columns, then yes… or you can take CC in the google web app opened in a web view… but why do you need to record CC? Stripe will hold that for you when they pay.

Gotcha. Yeah I think you misunderstood my first message.

With Stripe payment links you of course have to open a new link. I’m building essentially a checkout form.

To clarify, the CC should be the row owner, not the row ID, or registering email?

I’m not sure what your process is, you are taking commissions from users in your App sailing tickets to your App visitors? That’s why you are using Stripe connect instead of regular API?

Boom. Nice deduction lol.

Sidenote, I see how active you are in these forums and want to say thanks. You’ve been helpful with quite a few things.

1 Like

Thank you… the sheet in which you are recording users’ transactions should have a row owner check in the User email column…
You can use an unconnected Google Sheet to record that through a fetch JSON column, but this is a complicated process.

That actually makes sense.

So I’ll set it up to have the row owner there. Then send the webhook and the visitor then get’s an email with their ticket information and receipt.

Upon completion of payment, user then gets added to the “attendee” column so the user (organizer) can see them.

yes… make two email row owner columns there… one for seller, and one for the buyer… so both of them can see it… add the third one with admin email too

Got it.

Thanks for help.

FYI, Collection of user financial records is prohibited in Glide’s User Data Rules and Restrictions

1 Like

@Robert_Petitto :wink:
If you want to follow that restriction, you might want to use the Google Web app to take care of that process.

Ah, THANK YOU.

That’s why I posted, because I was surprised someone hadn’t use this process before.

I’ll find another solution. Thank you for the heads up.

but in stripe connect, all you need is a connected ID. Why store CC numbers? Subscriptions?

I don’t need to STORE them. I just need to collect them at some
point to process the attendees payments. Attendees don’t have a user account until they register (pay).

Am I missing something in my workflow?

are you passing CC numbers in your process? instead of stripe API collecting them?

Stripe have a API to get CC number

Hm, maybe I’m misunderstanding your question sorry.

I have a glide pages form, where a visitor can register.

I was looking into them inputing the CC number and when clicking submit sending the CC to stripe using the STRIPE api. However, according to the above restriction, I can’t do that.

you do not need to collect CC before the checkout

Correct, but stripe payment links cannot be embeded in the webview and I was trying to avoid checkout opening in a new window.