#rotogamer_code

1 messages ยท Page 1 of 1 (latest)

strong pollenBOT
#

๐Ÿ‘‹ Welcome to your new thread!

โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

๐Ÿ”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1227654794366292069

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

honest muskBOT
drifting crypt
#

Hello! The publishable key is an API that's designed to be public. You can include it in your app, or you can have your app fetch it from your server. It has very limited abilities, mostly focused around letting people provide sensitive payment details directly to Stripe so you aren't exposed to them and, thus, aren't on the hook for a higher PCI compliance burden.

#

A client secret belongs to a specific Setup Intent or Payment Intent. The client secret grants additional access and functionality to the Intent it belongs to, such as being able to confirm the Intent. Client secrets are always used with a publishable key to perform a particular operation.

grand ferry
#

It's very hard to figure out a clear workflow, tbh.

drifting crypt
#

In a payment scenario, you would typically create a Payment Intent server-side, pass the client secret to your client, then your client (like your iOS app) would confirm the Payment Intent using the publishable key and the client secret.

grand ferry
#

I knew about the PK, and about the Client Secret, scopes. I didn't know that Client Secrets and PK, had to be together.

#

Since the Client Secret is a way to identify my company, shouldn't it be more secured if it was "hardcoded" (or stored in a secret file) in the app, than me passing it each time from the backend to the app?

#

I've checked a bunch of documentation.

#

Because, another thing that is unclear is ...
When do I create the customer for Stripe? (I guess, is at the same time the user types its CC Details).
How do I know who the customer is? (so the app can send that identification to Stripe. I know I wont have StripeCustomerId, or StripeName, but probably something like StripeSessionId). But How can I tell the backend who the StripeCustomer is, the first time around?

#

for example. My backend, knows who our customer is, because we give it a user.Id, throught a jwot token during the log-in with the app.
And, I can understand, that we could have on the DB, the user.Id + StripeToken, to identify the user in stripe, later on... but how do we identify it the first time?

drifting crypt
#

Client secrets are unique to each Intent, and should never be stored anywhere as they're sensitive. It's not possible to include them in your app up front, as the Intents in question don't exist yet.

#

I recommend you follow the guide I linked to above end-to-end to get an idea for how the flow feels. It may not be the exact flow you want to implement, but it should help you get an understanding for how all the pieces fit together and how you can use those pieces to build what you want.

grand ferry
#

The guide you linked is exactly the same one I've linked

#

is the one I was following

drifting crypt
#

Have you completed the guide end-to-end?

grand ferry
#

I can see, in a "second reading" that I will always have to launch the "CreateCustomer" endpoint for Stripe in my backend, unless I pass something to the app first.
for example: Right before doing the payment intent, we would ask to the backend if that user.Id has a StripeToken attached to it, and if not, to create the customer.

grand ferry
#

I think i got confused mixing up "Client Secret" and "Secret key"

drifting crypt
#

Are you unblocked? Happy to help you get to the next step if there's anything else you need.

grand ferry
#

I'm slightly better than before. LOL
I'll try a few things, and I won't bother you anymore if things go well ๐Ÿ˜‰

#

if not, then ... I'll be back.

#

Thanks for the help

drifting crypt
#

Sounds like a plan, good luck with it!

grand ferry
#

Thanks! ๐Ÿคž