#oznerol92
1 messages · Page 1 of 1 (latest)
hi! when you say "a different app", is it a different Stripe account?
hi, no it's another frontend app but same stripe account
but in general this is banned on most accounts and unless you are PCI certified you should never be writing code like this that handles raw numbers
do you have some request IDs req_xxx from failing and succeeding requests so I could compare?
so I shouldn't pass the card with number, cvc to my server where I call stripe api? even though I'm not saving any of that?
I'll try to get them one sec
no, since then your server code has access to raw card details
so then there are all sorts of risks like every engineer at your company needs training and certification since they could write code that inadvertently leaks the numbers; or you might log them in your access logs, all sorts of stuff
hence why you should always integrate with Elements/Checkout unless your business is a PCI-certified entry that can comply with the regulatory burdens on card data
ok perfect I need to do that then, the thing is I wanted to create my own checkout process because I'd like to create a QR code for online and in-person payments using my own API service and I thought that using checkout elements and so on it didn't give me the full access of data and freedom. But I'm going to re-write the code since I don't want any legal trouble lol.
the failed req is this one req_VvsEavzZ3kUrVa
and this one should be succeeded one req_BXJQG8X6xzNlG5
well the example where it worked is using a payment method created in August, but since then we have had a workstream to become a lot more strict in blocking "raw card" requests like this, for example that article https://support.stripe.com/questions/enabling-access-to-raw-card-data-apis was only published in the last couple of months
you could have a QR code that links to the page on your site where you're using Elements, that would work fine
ok perfect thank you so much for your time