is just a popup window, it will come back to the App after closing
Yeah, it’s not a massive thing, however, it does change the user experience.
yes, a little… you can use PayPal, which allows embedding. I have a sample here:
BTW, if you are using the USC column to collect CC, and do not store that value, just pass it to the webhook… I don’t think you will be violating any rules.
USC column?
User Specific Column is only visible in the user device
@Robert_Petitto do you have any insight here too?
@Uzo Would that fall under the “transmitting” category?
Hmmm… I’m not a lower 
maybe…
Anyways… for regular people entering CC on a website will not ring an alarm… but for those with little knowledge … it might be a red flag if they don’t see the Processor website URL at the checkout…
If it were me, I’d collect payments through a webview, that way Glide isn’t the one collecting the payment. Only issue is that Stripe Connect can’t be embedded in a webview…
Honestly, as much as I would love to integrate Stripe Connect into an app to make a 2-sided marketplace, I haven’t ever done it because of the UX constraints.
2 Likes
Because of security? Or because of the glide restrictions? I don’t want to rock the boat with Glide at all. I HAVE NOT implemented this. Just incase anyone is listen 
1 Like
I thought this as well…not sure because that info, while not accessible to other users, is still technically collected on Glide’s servers, even if temporarily.
Maybe @Jeff_Hager knows more?
3 Likes
I always use the web view to collect sensitive data and store it in unconnected sheet
I would never collect CC info outside of an official authorized payment gateway. Even if stored temporarily in a glide table or google sheet, the fact of the matter is that it’s stored in clear text without any encryption. That is a massive security risk for the user and a liability risk for the developer. Without having a full grasp of what you are doing to keep a user’s personal data secure, or the requirements to keep it secure from a legal standpoint, I would avoid it at all costs.
I would never attempt such a thing, but if I did, I would only do it if I had full control of the code running on a back end server. With Glide, we don’t have that. Javascript columns run purely on the user’s device as well as a Fetch JSON column, so it’s easy to track down any API keys and abuse them. API keys should never be accessible to an end user, but with most processing happening directly in the end user device, it mostly unavoidable. Google app script macro urls are fully exposed and can lead to a user finding the macro url and calling it at will, outside of glide, to send or retrieve data in a malicious matter. Webhooks run on glide servers and pass along a password in the header, so in some respects they are a bit more secure as long as you utilize the password associated with that webhook, but I believe the contents of that webhook call are still accessible. However, the webhook password is never exposed to the user as it’s only stored on glide servers and the webhook is called from the glide server. So webhooks provide some added security it the password is utilized.
USC columns are not a security method. A developer can still see the contents of USC columns, and there is no sort of encryption while that data is stored in the table, or while it is on the user’s device. I believe glide does encrypt the data while it’s in transfer between glide and the user device, but it’s not encrypted while it’s sitting on either end, thus it’s clear text. For the same reason you should never build your own sign-in process outside of what’s provided by glide. Passwords are not encrypted and hashed. They are stored in clear text at some point in the flow. Things like that should only be controlled by a back end flow, which again, we don’t have that kind of control with glide.
If we think about why the integrated Buy button is so finicky, it’s because the glide server is handling the transaction with stripe. Not the user’s device. That’s why you can’t use computed columns with the integrated Buy button. It’s because the glide server does not have any knowledge of the values in a computed column. Those values only exist on the user’s device, but it’s the server that securely communicates with stripe. So, if the glide server has no knowledge of a computed value, then that’s why it says the item no longer exists or the buy button does not work correctly sometimes. For security reasons, the transaction is handled with a back end process only on the glide server.
My thought is that if a large corporation with several IT security staff can potentially suffer a security breach, then I honestly don’t feel confident that a single no-code developer can provide a more secure method. There is way too much on the technical side to be aware of. If I were to ever process any sort of payments, I would only do it through an official payment gateway without ever collecting financial data from a user myself.
9 Likes
Thank you for that explanation… I do a lot of payment integrations for customers, and I did come to the same conclusion… if I don’t see the processor URL on the checkout session… it is a red flag for me…that’s why I trust Stripe more than PayPal… but still both of them can be embedded and twist. It is just harder to do it with Stripe.
1 Like
But… do not get scared too much… 99.99% of sites are charging CC in a good way… and right now, if you check your online bank at least once a day… you can prevent any scam… most banks will cancel CC transactions if you react in 24 h. And I recommend seeing Kitboga or Boda on Youtube… just so much fun and satisfaction… and there are so many like them to fight back… I myself put to the ground a few scammers … and called their victims. (only one said thank you )
2 Likes