#cferry
1 messages · Page 1 of 1 (latest)
On the app side, you will be using either a public key, which is safe to share. They are basically only allowed to tokenize card details and confirm payments, so they can't make other modifications to things on your account that could happen with a secret key
OK, so this public key is safe to be stored on my .env or even sharedpreferences, right.
Just to clarify, and in order to be PCI complaint, it's recommended to do all the queries directly from Flutter, right? "List credit cards", "Add credit card", "remove" and so on.
the backend api server (express/node on my case) would not need to even see this info
is this correct?
I appreciate your support btw.
final question, does transactions (purchases) need callbacks? or can I make them directly from the app and await for a response?
PCI-wise I think the primary concern is how you handle the tokenization and making sure that your code is not handling raw credit card numbers. Listing cards is actually only possible on your server and won't affect your PCI compliance (as far as I know) because the card details are redacted at that point
What do you mean by callbacks here? Are you talking about basically how the client will know if the payment was successful?
that's correct, how to notify either success or failure
Hello 👋
Taking over for Pompey as they need to step away soon
We don't have an official flutter integration so our team wouldn't know much about this in detail. Typically you can retrieve the PaymentIntent client-side using the publishable key to check its status and know if it succeeded. However, as I mentioned earlier since we don't have a first-party integration we don't know for sure if that's supported with stripe-flutter