Would you still purchase add-ons if PayPal wasn't supported (and Stripe was?)
- Thread starter Robust
- Start date
Robust
Well-known member
Doesn't matter. Stripe is just a secure way of processing cards. If people voting no are voting because they don't know what stripe is, that's technically a yes - it's just a credit card payment processor.
Robust
Well-known member
We lose a lot of money accepting and processing PayPal. We get about £21.50 out of a £25 purchase for example, but Stripe would allow us to get £24.20 losing less in fees, etc.
Snog
Well-known member
From a customer user standpoint, I actually look for places that take PayPal. If I find something I want at two places, usually the one that takes PayPal will win out.
From a vendor standpoint PayPal may take more for transactions, but I don't need to worry about PCI compliance on my server (although at this moment it is anyway). I don't know what the rules are in the EU, but here in the US, your server must be PCI compliant or you will at some point start paying a huge amounts in fees/fines and could quite possible lose your merchant account.
That's not to mention the $100 per year fee to certify you're PCI compliant.
From a vendor standpoint PayPal may take more for transactions, but I don't need to worry about PCI compliance on my server (although at this moment it is anyway). I don't know what the rules are in the EU, but here in the US, your server must be PCI compliant or you will at some point start paying a huge amounts in fees/fines and could quite possible lose your merchant account.
That's not to mention the $100 per year fee to certify you're PCI compliant.
MattW
Well-known member
That is only the case if you are storing card holder data. If you simply hand the transaction off to PayPal / Stripe etc, then you aren't required to be PCI complaint.
https://www.paypal.com/uk/webapps/mpp/pci
This is what happened to Lush back in 2011 when they had their site hacked, and were storing card holder data on their own servers:
http://www.theguardian.com/money/2011/jan/21/lush-website-hack-customers-fraud
Snog
Well-known member
It is also the case if you transmit cardholder data, which looking at the Stripe API you are doing. If you take cardholder data on your site for any reason and transmit it, you must be PCI compliant.
With PayPal, I never see or transmit cardholder data.
From what I recall when Mike implemented it, all data regarding the CC is handled entirely by stripe.
Alpha1
Well-known member
I don't use credit cards, but I think that Stripe is expanding its payment methods. So it depends on if there is any payment methods that I can use.
If I can pay through it easily then I will prefer it above PayPal. While PayPal has been less evil in recent years, its ugly past weighs against it. While its convenience and the critical mass it has makes it too important to abandon.
If I can pay through it easily then I will prefer it above PayPal. While PayPal has been less evil in recent years, its ugly past weighs against it. While its convenience and the critical mass it has makes it too important to abandon.
Jake B.
Well-known member
When you enter your card details it's actually within an iframe on stripe. clicking the "pay with stripe" button opens a modal that contains an iframe to stripe.com that contains all of the form fields, so no card information touches your server. You are likely still required to have SSL, but really you should anyways
SneakyDave
Well-known member
I would be interested to know WHY PayPal isn't accepted if Stripe was the preferred method of payment.
I've seen a lot of sellers (not devs) lose their PayPal accounts due to shady practices.
I've seen a lot of sellers (not devs) lose their PayPal accounts due to shady practices.
Robust
Well-known member
Why on PayPal? Is it because you're on their website? That's exactly what Stripe does too. Stripe Checkout is a js form thing where the customer completes a form that directly posts to Stripe, and that entire form (the form with the request to Stripe) is within another form that gets the result of that form (which is a customer ID). So this customer ID basically identifies the customer for future charges.
Card details do not touch the foreign server. The foreign server does all its business with your customer ID.
Mr Lucky
Well-known member
I don't think so. I decided to switch from Worldpay and Paypal to just Paypal, mainly because it was cheaper than Worldpay.
If Stripe is cheaper, I'm certainly going to look into that, though i don't really want SSL so that may be a problem.
Robust
Well-known member
This was for Apantic but processing PayPal for us is at a higher cost and we lose almost 20% of the money processing it. Yeah, it's that high. We'll still accept PayPal but likely have a gateway charge, and the only reason I see for using it is if you don't have a card and are using PayPal balance like lots of people. Stripe is more convenient for us and honestly faster and less hassle for the average customer.
Even though card data doesn't touch your server, I believe Stripe recommend (and actually, require) it. I remember reading that in their docs but don't quote me on this, check out their docs.
Mr Lucky
Well-known member
I looked at Stripe extensions for Woocommerce. Some of the plugins require it, one of them doesn't but recommends it:
http://codecanyon.net/item/stripe-c...tf8=✓&term=ssl&from_buyers_and_authors_only=0
As you can see, many people are confused about the SSL issue. From what I can tell it's mostly about cusotomer confidence. With Worldpay the sale redirects to the secure worldpay site for CC details to be entered. If that page were in an iframe, it would still be secure, but the customer would not assume so as the green/grey padlock icon would not be there at the top of the browser.
Snog
Well-known member
OK, I didn't read the entire documentation there, I only looked at their API samples where cURL is used and PHP. They both indicate the info is taken on the server and transmitted to Stripe.When you enter your card details it's actually within an iframe on stripe. clicking the "pay with stripe" button opens a modal that contains an iframe to stripe.com that contains all of the form fields, so no card information touches your server. You are likely still required to have SSL, but really you should anyways
Code:
curl https://api.stripe.com/v1/charges \
-u sk_test_BQokikJOvBiI2HlWgH4olfQ2: \
-d amount=400 \
-d currency=usd \
-d "description=Charge for test@example.com" \
-d "source[object]=card" \
-d "source[number]=4242424242424242" \
-d "source[exp_month]=12" \
-d "source[exp_year]=2017" \
-d "source[cvc]=123"
Code:
\Stripe\Stripe::setApiKey("sk_test_BQokikJOvBiI2HlWgH4olfQ2");
\Stripe\Charge::create(array(
"amount" => 400,
"currency" => "usd",
"source" => array(
"number" => "4242424242424242",
"exp_month" => 4,
"exp_year" => 2017,
"cvc" => "314"
),
"description" => "Charge for test@example.com"
));And looking at their web site, I don't see how they are cheaper when the pay as you go option is identical to PayPal 2.9% plus 30 cents. There must be lower rates for the Enterprise users.
Liam W
in memoriam 1998-2020
Granted, PayPal have the same fees for charge backs.
I've accepted both Stripe and PayPal for my add-ons for a while, and most everyone uses PayPal (I'm actually surprised when someone uses Stripe).
However, I'm probably very lucky, because in total across everything, I've only had 1 chargeback...
I do believe Stripe is slightly cheaper, however you do have to wait a minimum of a week for the funds to be in your bank account (which annoys me slightly).
They're a good alternative to PayPal, but people seem to prefer PayPal...
Liam
I've accepted both Stripe and PayPal for my add-ons for a while, and most everyone uses PayPal (I'm actually surprised when someone uses Stripe).
However, I'm probably very lucky, because in total across everything, I've only had 1 chargeback...
I do believe Stripe is slightly cheaper, however you do have to wait a minimum of a week for the funds to be in your bank account (which annoys me slightly).
They're a good alternative to PayPal, but people seem to prefer PayPal...
Liam
It is possible to use their API to charge cards directly.
However the recommended approach is one of two...
There is a Checkout.js implementation which renders the payment form in an iframe and is 100% managed by them. You can see that in action here:
https://stripe.com/checkout
Then there is a more DIY integration in which you render the form fields in your own template, fits in with your own style, etc.
Both of these, however, support card tokenization. This is where the card details are submitted to Stripe using their provided JS, Stripe converts the card details and returns a token. You receive the token and the only thing you submit from that form is the token (if you're rendering your own form fields, they should be without name attributes so they never touch your server).
You then make API calls with that token and that is what triggers a charge to the credit card.
This defers a lot of the PCI compliance in their direction, so, effectively, you shouldn't need to do much.
However, the first approach, Checkout.js qualifies for the PCI DSS SAQ-A whereas the latter approach - because you are rendering the fields on your own server - qualifies for PCI DSS SAQ-A EP.
https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf
That explains a little bit about what the SAQ stuff is. There is other documentation which is pretty extensive. Wherever possible I would recommend implementing a method that qualifies for the SAQ-A. There are still things you need to do to ensure you are compliant, but they are mostly common sense. You wouldn't think it but SAQ-A EP requires a lot more of you.
FWIW, Stripe says their inline approach is SAQ-A, but we've done a fair amount of reading and don't agree with their interpretation (others have the same opinion). Of course, PCI stuff really just comes down to what the card companies determine, so chances are, you won't even be on their radar if you're only doing a handful of transactions per day.
Last edited: