I'm using Stripe for in app payments in my mobile app project and I don't quite understand how any app is secure if the user inputs there card info (with or without stripe) if it's not over HTTPS the whole time.
From my understanding if you want to do any form (pun intended) of payments on a mobile device you have to create a token and send that token to a backend server that uses HTTPS (and has the private-key) to process said payment (with stripe, I'm not familiar enough with the others).
As stated by stripe:
It's worth noting that Checkout doesn't actually create charges—it only creates tokens. You can use those tokens to create the actual charge on your server.
Where the token turns into a charge when it's on the server-side that's over SSL
All submissions of payment info using Checkout are made via a secure HTTPS connection. However, in order to protect yourself from certain forms of man-in-the-middle attacks, we suggest that you also serve the page containing the payment form with HTTPS as well. This means that any page that a Checkout form may exist on should start with https:// rather than just http://.
My Question/Concern (TL;DR):
So you can create a token without without having it be over HTTPS, where it is only the payment that needs to be over HTTPS. However, is this token creation process secure (my first question)? I cannot help to think that anyone entering their card information where there information is sent over the wire to stripe and back to create a token is not secure and is prone to man in the middle attacks.
- Is it secure for token be created over HTTP and not HTTPS? Is it secure to then send that created token over the wire using HTTP?
- If so, couldn't the user's card info be jeopardized (e.g collected or scraped) in this process? As the card info being entered, sent to stripe, sent back, and then sent serverside all without HTTPS?
- What are the best practices when dealing when mobile? Does this case differ in native or hybrid development? What about using in app browser for payments?