How is generating payment Tokens secure in Mobile development?

Question

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.

1. 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?
2. 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?
3. 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?

Answer 1

You seem to have a misunderstanding about token creation, when you say you can create a token without having it be over HTTPS. Token creation goes as follows:

1. Cardholder submits card over HTTPS to Stripe
2. Stripe stores the card number and associates it with a token which they generate
3. Stripe hands the token to the merchant (you).
4. From then on, you can charge the underlying credit card by telling Stripe to charge that token.

Step 1, where the card number is transmitted across the network, must be protected by HTTPS. The token, while not as sensitive as the card number, is usually transmitted over HTTPS also.

When Stripe says

we suggest that you also serve the page containing the payment form with HTTPS

They mean that your page which contains the form (or iframe, or link, or javascript) that leads to Stripe. They're not talking about subsequent token transmissions when they say this (although, again, standard practice is to protect the token as well).

To answer your questions:

1. Is it secure for token be created over HTTP and not HTTPS?

No. Token creation requires card data be transmitted, which requires HTTPS as per PCI. Remember, you don't create the token, Stripe does, and they're at the other end of the Internet from both you and your customer.

2. If so, couldn't the user's card info be jeopardized (e.g collected or scraped) in this process?

Since #1 is "no" the "if so" clause doesn't apply. (Yes, if you didn't use HTTPS, the user's card info could be jeopardized, which is why it must be HTTPS.)

3. What are the best practices when dealing when mobile?

Best practice is to encrypt everything, on or off mobile.

Answer 2

Credit card PANs must NEVER be sent in plaintext or stored unencrypted.

This means that you must retrieve the payment card information from the user over a secure channel like HTTPS and must obtain a payment token for it from Stripe over HTTPS.

An interesting variant on this which omits your web app from PCI is to send a public key down to the client, have JavaScript encrypt the PAN and then your server sends that encrypted PAN to a tokenization service on your backend that has the private key and talks to Stripe.