Closed RIAEvangelist closed 9 years ago
Passing credit cards even with HTTPS opens people up to claims under PCI-DSS if any credit card information is stolen or lost, even if information is passed (Like is done here)
A person could handle credit cards without PCI-DSS certification but is liable for all damages. PCI-DSS certification is quite expensive and is just absurd to go through if you can use something like Stripe.
The idea I had was using my own credit card to run PizzaGiver (Without PCI-DSS so I'd only be liable to myself) and running their information through Stripe and reimbursing myself.
It is extremely roundabout. Basically, I was trying to use Stripe to put an additional layer so that I wouldn't be liable for damages if credit card information was stolen (which is highly unlikely since the site is not a big scale).
In other words, this could be stripped out of the 'default' branch but I can keep my version with Stripe. Sorry for the spam.
I see. I am all too familiar with PCI-Compliance, and agree. But I believe this is the same as passing the information direct to domino's. Meaning one way or another the cc info is passed over https to another party for the transaction to happen with them.
The code implementation looks like stripe charges the buyer once paying your stripe account and once paying domino's. Did i miss something? Not too familiar with stripe.
I do think it would be good to have examples of how to do 3rd party integration with stripe etc. I think though this should live in the app using the module, rather than forcing it in PizzaPI.
So like, the give.Pizza app would use the module and use stripe, but then also be able to change to paypal or square or Authorize.net etc.
This would leave it upto the devs if they want to go this route or not financially, and keep the PizzaPi purely a dominos API for anyone to use with any service.
In my implementation, it was going to authorize a charge for the 'base price' (As Dominos has no functionality to charge a tip on the website. Ugh.), then I was going to transmit my credit card to Dominos for payment then authorize the Stripe payment with the full amount (Since the tip included would end up on my credit card).
Super round about. This is also why I plan(ned) on abandoning using credit cards for PizzaGiver and trying to use gift cards instead but haven't tested or implemented the functionality yet. Allowing gift cards to be used (and ensuring it actually works) may be a good future feature to add.
And I definitely agree about removing Stripe and not forcing it all together. There is definitely a better way to implement so it isn't required.
EDIT: Also, I am not entirely sure about whether credit cards to Dominos over HTTPS is an "okay" procedure under PCI-DSS. It is really a question of how the credit card is handled before the information is transfered. It isn't likely to happen but it could be a possibility. In regards to the API, who cares, it isn't our / the API's problem to worry about. I was building my own API so I wasn't entirely planning on distributing it when I was writing it. (The honest truth is I only published it so I didn't have to push the API with PizzaGiver to Heroku. :p)
Hey whatever the the reason its awesome!
Did a bit of research, using stripe via an api will not alleviate PCI-DSS compliance. Basically the only way to do this would be to have a separate app written by stripe take the payment and then send a token to your app.
Think like popup or iframe etc.
allowing user input in your software which is in any way cc related puts you under PCI-DSS. Which is why when you use paypal etc. you go to a different site and then have a hook on your site to accept the payment.
Then again... some people probably wouldn't care if they are PCI compliant until they get to be a size that would be investigated, or have poor customer service so people decide to report them to a government agency.
Just wonder what the thought process is for this one.