1
votes

I am working to connect Stripe up with my iOS Swift app to handle payments. Below is a flow chart I found which contains the conventional flow chart for integrating Stripe with an iOS app. Here it is: Suggested Stripe flow chart I am wondering if I could alter this flow chart to be the following steps:

  1. [From phone to web server] Send request token containing booking information.
  2. [From web server to Stripe] Send credit card data which is stored on web server.
  3. [From Stripe to web server] Return token.
  4. [From web server to Stripe] Send token back, confirming transaction.
  5. [From Stripe to web server] Transaction response.
  6. [From web server to phone] Transaction response.

Obviously, the main difference is starting by sending a token with the booking request info to the web server, instead of sending the credit card data to stripe. This avoids having to constantly ask the user for their credit card info, as that info is stored on the web server. Does this look safe?

1

1 Answers

7
votes

What you are proposing is a bad idea, and it misses the point of Stripe.

If you store credit card data on your server, you have to be PCI-compliant. (This might actually also violate Stripe's Terms and Conditions; I'm not sure, but you should check and ask an attorney.) It also opens you up to lots of potential problems. Imagine if your server gets hacked, someday. If you're in a litigious locale or one with lots of privacy laws and regulations (like Europe or the U.S.), your life will be much worse if card information is stolen than if only tokens are stolen.

Instead of storing card data, use the Stripe API to generate a customer and associate the card with that customer. You store the IDs generated by those API calls, not the raw card data. Then, using the Stripe-generated customer ID, you can run charges against that card, but without having to store the card data yourself.