Basing these comments purely on the credit-card processing side of things:
Context - small business, using PayPal for almost five years, large transaction values, small transaction volumes, global dispersion of customers, multiple currencies.
1. PayPal works (mostly) without issue for customers from a wide geographic region (my customers are from many countries all over the world).
2. The exchange rates offered via PayPal are TERRIBLE. Several percentage points, on top of the several percentage points initial processing fee. Either the business, or the customer, is paying for these bad exchange rates (dependent upon the source/destination of funds). This can be an additional five percent.
3. Customer service from PayPal is lacking, but in the case of disputes, things have worked out in the way I would logically expect, around 99% of the time. In the other 1%, PayPal refunded the money, I have never lost anything (neither have my customers) due to disputes.
4. STRIPE has categorized my business as high-risk, and therefore won't offer me their services. I won't specify my business type here - I can safely guess there is nobody on this planet that would consider my business type "high-risk".
Some of the categories of what constitutes a high-risk business are obvious - gambling, porn, etc etc, other categories make no sense at all. (I have never had a single disputed charge in four years of operation)
Semi-regularly, I search and compare cc-processing alternatives. Mostly, due to the currency exchange fees, poor customer service, and stories of PayPal accounts being frozen/locked due to spurious reasons.
At a previous job we also used PayPal. We tried switching to a traditional credit card processor, which was a nightmare.
We had a seasonal business that processed sales of $1 million+ revenue in a week, once a year. Around 60% of sales were international. This combination was like kryptonite to card processors. We finally got accepted by one, the fees weren't much better than PayPal. It was amusing seeing TFA describe PayPal's API as "a horrible experience" after having implemented that traditional processor's API.
We ended up going back to PayPal after one season.
Although in the end, our decade-old business was killed by relying on PayPal's fraud detection. We got hit by a flood of China IP-sourced carders and the chargebacks ruined us. This can happen with any traditional card processor as well, it was really on us for being too naive (and being spared from fraud in the past decade)
Did you have significant legitimate China business? These days it's probably not as effective a technique, but back in the mid 00s we ended up just banning entire countries at my company because well over 50% of transactions from those countries ended up being fraudulent.
We did end up banning China, but there such a delay between the transactions and the chargebacks that it was too late. We also tried preemptively refunding suspicious charges, but you get hit with the chargeback fee regardless.
The PayPal fraud was the reason we went to a traditional CC processor. In a single month we were hit with over 1000 french PayPal accounts and we had some legit French business, so we couldn't block them. We ended up getting frozen by PayPal for a while, switched to Authorize.Net, and after a couple months PayPal started releasing funds again, and We had too many charge backs on Authorize.Net to continue using it.
I do not agree with their categorization of gambling as high risk either. Gambling companies are heavily regulated and at least in Europe there are very few fraud cases due to 3D Secure.
2. Stripe's currency conversion rates are also terrible. And you're forced into converting the currency rather than being able to deposit it in the currency my users pay in...
There are lots of legal reasons for this. To be able to settle in a currency, you must have an acquirer that can accomplish that (ie, they have a bank account there). And then next, the Stripe and you will likely need to setup a local entity to have a bank account that can take the money. This then exposes them to more regulation from that country.
A processor just doing cross currency and settling in a few countries is much easier to do.
Stripe can certainly take USD - and my local (Australian) bank certainly accepts USD, as I have a USD bank account with them.
But I'd cut them more slack if they didn't sting me for currency conversion as well.
«The exchange rates offered via PayPal are TERRIBLE»
This is why Bitcoin is not such a bad choice after all. People on HN tend to criticize the Bitcoin option for international payments, saying the combined overhead of the buyer converting his local currency to bitcoins + the overhead of the seller converting the bitcoins to his local currency is too high. But the reality is that this is still less overhead than the next best option (Paypal).
Bitcoin is unequivocally worse for this, as you say, you face two currency conversions, one from buyer currency to BTC and one from BTC to seller currency. Each time you pay 1-2% (or more depending on jurisdiction) and it takes days, which given its huge volatility exposes both sides to massive FOREX risk on top of that. PLUS a BTC transaction fee (currently $0.26). Not to mention the non-trivial chance your exchange will shut down or run away with your money during the process. [Hello, Quadriga]
1-2% + $0.26 + 1-2% + FOREX risk + 1 week + forefeiture risk is strictly worse than even PayPal.
Most Bitcoin exchanges have fees that are a fraction of a percent. Not 1-2%. Paypal has international fees approaching 5%(!)
It doesn't take days to buy some BTC. Buying or selling is instantaneous (once you have an account at an exchange, which is a one-time thing to setup, certainly not a step to go through for every transaction as you seem to imply!)
Volatility has been declining over the last few years. Besides, volatility has an overall net-zero effect on your transactions: half the time you make a bit of extra money, half the time you lose a bit of money, so it averages to zero gains/losses.
Finally, use a trustworthy exchange. These are really not hard to find: Coinbase, Gemini, etc.
I think Stripe might soon offer payments through Paypal in some way. A few weeks ago I tried their new PaymentIntents api. I forgot to give a valid payment method in the request and it returned me an error stating I need one of following payment methods:
I asked them why that list included paypal and how that would work. They replied it was a mistake and it has since been removed from the error. But this tells me that internally they're working on paypal integration.
How does the money actually exchange hands though? Like, your business wants to charge my Mastercard $100. Who moves the money from the mainframe on my bank? I don't think Stripe is integrated with every bank in America?
The card network handles this I believe. I've never worked in payments, but I have spent some time analyzing the space for investments. As far as my knowledge with regards to online payments, the merchant gateway talks with the merchant acquirer/payment processor, the acquiring bank then pays the merchant, and the acquiring bank sends a request to authorize and settle the transaction through the card network, which talks to the consumer's bank/digital wallet. Stripe in this case is the merchant gateway and acquirer. If PayPal is used, ACH replaces the credit card network.
so, since no merchants integrate directly with Mastercard/Visa (it would seem that's just not the business model of the industry. I'd also gamble it isn't possible because if you're a mom and pop shop, Mastercard does not care for you to integrate directly with them), they are going through networks/gateways, which would be TSYS/FiServ/First Data, yes?
I'm just trying to picture a world where payment processor fees are lower because instead of PoS systems for businesses connecting to gateways/middlemen who need to take a cut and hike the rate up, they connect directly to the card network/the underlying bank.
But, it sounds like a service like that would be exactly the middlemen I'm describing, who need to take a cut of the fees :P
It doesn't make much sense for PayPal to be integrated into Stripe (from PayPal's perspective), as it gives PayPal's Braintree a competitive edge over Stripe.
I've used SagePay in the past and they offer PayPal payments via their API. Big mistake. You have less control over the payment experience, and when SagePay have an outage, it takes out both their payment method, and PayPal.
I run an online Photo editor https://www.Photopea.com , where users can pay to get a Premium account. Everything goes through PayPal and users seem to be happy.
But PayPal has quite large fees. From a 9 USD payment, they take like 10%. Also, if you are not from the US (I am not from the US), you can only withdraw money in your local currency, and PayPal has quite bad conversion rates (you lose 2-3% again).
I am still wondering, that after so many years, no big company (Google, Facebook, Apple) came up with their competitor to PayPal (everybody would switch to them, if they had lower fees).
>you can only withdraw money in your local currency, and PayPal has quite bad conversion rates (you lose 2-3% again).
Someone on HN recommended TransferWise for that purpose. I tried it and it works well: PayPal can transfer to TransferWise and then from TransferWise money can be withdrawn in local currency with a very fair exchange rate close to real-time Forex.
Disclaimer: I'm not affiliated with TransferWise in any sense.
Yes, I think it is like 35 Cents + 3.5% or something like that, end up being ~7.5%. And if you include other cost like chargeback etc and averaged out it is likely close to 10%.
Which is why I don't understand how Patreon operate at only 5%.
Not for the lack of trying. Google and Apple are trying to cut into payments from the platforms they own: phones. Amazon has been offering a payments service for a long time iirc.
You can integrate some local bank API for Credit Card Payment. it might not help much but 10-15% payment came from them and save your some money. I always suggest to have both options on website for coverage.
I am working on it at the moment, but it is extremely hard. You have to communicate with them (through email) and describe what you want to do. They have too many requirements (like you should have the icons of MasterCard and Visa on your website) and it is even harder to convince them to allow you accept payments from the whole world (they usually only let you accept payments within your country).
With PayPal, everything is automatic. You can configure everything yourself and accept payments in no time, without having to communicate with an actual person from PayPal.
In Spain, the setup process is the same as when you are asking for a pos machine, you usually have to open an account with them. You get the same conditions than with the pos machine, something like 0.50% and 0.25€ fixed price, with discounts if you have great volume.
Been offering credit cards, paypal, and bitcoin payment options to my customers. Bitcoin is horrible. 1 or 2 transactions per month - not worth the investment it is just a hype for ecommerce.
Paypal vs credit card is completely different story. On my end I get 60% of all payments made via PayPal. In general, if you are not offering PayPal as a checkout option then you are probably missing 10 to 15% of potential sales.
I see similar results on an ecommerce site. PayPal's UX (login, click buy) is a better experience over entering a 16 digit credit card, expiry date, csv & address. It's one or two clicks and payment is done.
It's unfortunate but people will always choose the easiest way irrespective of the costs to the merchant. It would be interesting to see what happens if you charge 2% more for PayPal (or whatever the difference in fees are / amount you need to cover the costs/risk of working with PayPal). I suspect checkout conversions would drop.
PayPal's UX (login, click buy) is a better experience over entering a 16 digit credit card, expiry date, csv & address.
You're comparing the UX for a customer who already has a credit card registered to a Paypal account with the UX of a user who doesn't have a credit card registered with Stripe. If your customer has a Paypal account with a registered card the UX is better. If they don't then Stripe is much nicer because you'd need to include the Paypal sign up process in your UX and that's horrible.
Does the customer know that they are storing their card details with Stripe and not with the merchant?
I think that's important because some people (such as myself) tend to avoid storing card details with arbitrary merchants. I would be far more comfortable knowing that my card details are stored with a specialised payments company like Stripe.
If you already have a credit card with Stripe then definitely yes, you know the merchant doesn't have your card number. IIRC, when you first enter a credit card you remain on a web page controlled by the merchant, so it would be hard for Stripe to guarantee the merchant didn't intercept it in any way. Since this guarantee isn't possible, they're not going to show a message that says the credit card is stored at Stripe and not the merchant. It's up to the merchant to show such a message.
Yes, you can. To ever see the credit card number you'd have to be trying. But I don't see a way to implement stripe in such a way that the credit card entry happens on a separate page on stripe's site where the customer can look at the padlock in their browser's location bar to know that only stripe has access to the entered information.
Of course, and in that case as the user has to enter their credit card details DirectPay's UX is more comparable to Stripe. In my opinion Stripe is preferable in that situation as it's just looks much better, and has friendlier language around it.
Hands down it's that UX for me that causes me to use PayPal whenever it is available, but if it's not available I don't mind having to input my card 9 times out of ten.
I use paypal where available over direct credit card entry not because of the UX, which isn't perfect IMO and in the past has been worse, or because I particularly like paypal otherwise, but because it limits the amount of places I'm handing my credit card details to. I work under the hope that this reduces the attack surface area for those details being attained by the many ne'er-do-wells out there.
Same. That comes from experience. 2 out of 2 of the places I've worked professionally that took CC payments directly initially had CC numbers appearing in plaintext application logs.
It's harder to make that kind of mistake in a Paypal integration so if I'm buying from someone outside of my comfort zone I'll look to use Paypal.
Stripe also makes that kind of thing more difficult to do accidentally. I've occasionally had a look to see if a company used stripe.js before putting in my details.
The harder UX should go away "soon", when the Payment Request API[0] lands. Then you can just directly select a credit card that's already stored in your browser, which should place it on par with Paypal.
The credit card thing is only since 2018, forgot about that. Regarding PayPal, maybe it is in their TOS, but here [0] is a Screenshot from Airberlin (from an article about the new CC rules [1]) from before 2018. 7€ extra for both PayPal and CC, 5€ for SEPA and no extra cost for GiroPay.
>Also theres a german law which forbids additional fees for paying with CC.
Interesting, because lots of brick-and-mortar German businesses (especially restaurants) simply don't take credit cards, because of the processor fees. You'll go very hungry in Germany if you go there with a credit card and no way of getting any cash.
I've done a lot of checkout integrations and The Stripe API is orders of magnitude easier to integrate than the PayPal API. As the author suggests PayPal might be more popular because not everyone has a creditcard. Another factor that helps PayPal is that you don't need to have your card at hand to make the payment, if your account is active, the only thing you have to do is click "next" 2 times and you're done.
Shameless plug related to this post: I'm integrating both Stripe and PayPal in my software licensing SaaS product where I intend to provide the nuts and bolts related to accepting payments and handing out and validating the license keys for a standalone software product. It's still a Work in Progress, the landing page can be found on https://license.io
> As the author suggests PayPal might be more popular because not everyone has a creditcard
Or a credit card that's not otherwise accepted. My main card is a JCB card, which is poorly accepted outside of Japan. PayPal will accept it though. I have VISA cards as well but either with pathetically low credit limits or they're debit so I avoid using them.
I generally prefer using Paypal when I can, because of security. I don't enjoy handing out my credit card details and will try to only enter my details when I think my details are safe.
I agree that Stripe is significantly easier to integrate than PayPal, but Braintree has options for both credit card and PayPal integrations (because they're owned by PayPal) and also has a very nice API.
(I'm not affiliated with either, but I've used both.)
+1 for Braintree. We have used several different payment providers over the years, including PayPal alone. We switched to Braintree back when they were offering $50K in free payment transactions.
The payment integration was straightforward, and getting built-in support for PayPal (which accounts for 16% of our sales) and the ability to safely vault payment methods made it a no-brainer.
My only concern is Braintree is more expensive. Stripe doesn't change any additional percentage for non local currency while Braintree charges additional 1%.
Aren't there many other alternatives, too? Admittedly, I'm a bit out of the loop. When Kagi[1] changed their payment structure to discourage small prices, I started using Fastspring[2] for many years for an old shareware project. It works very well. However, I have almost zero sales now so there is not much to work with.
Funny story: Just a few weeks ago, a a guy from Fastspring called me up in Portugal on my landline phone. His accent was Australian or NZ, so I had troubles understanding him and I also suspected a phone scam first. He turned out to be a very nice person, he was interested in my business, how they could help us grow, and about the Lisbon developer scene in general. I had to tell him that I don't know anything about it, but I did mention Y Combinator and the local government's efforts to attract startup companies. I also had to explain the nature of my 'business' to him - that it's no longer a business, only shareware maintained for existing customers. No idea what the real purpose of the call was, but it was a nice chat and I was positively impressed by Fastspring's customer service.
[1] I remember fondly the cheques I got from "Walnut Creek" and how I had to move to Citibank because my local bank treated me like a suspected criminal because of them. Sadly, I've just learned that they shut down in 2016: https://tidbits.com/2016/08/04/kagi-shuts-down-after-falling...
I remember people from Fastspring and BMTmicro being very active in the indie game development forum i was participating at (i think the BMTmicro guy was actually the owner, not sure about the Fastspring guy). That was around 7-8 years ago, but still left me a positive impression for both companies especially since they weren't just bullshitting to appear "involved" in the community, but actually participating in the discussions with useful comments.
It took us less than one man/day to custom-wrap their REST API via libcurl to add PayPal as an alternative to Stripe. I don't know how else to put it, but it's just really dead simple.
Their own libraries are complete junk though... or at least they used to be few years back.
The problem with their APIs is that they're broken and/or stupid in surprising ways the moment you look beyond the most basic things.
An example: the REST API allows you to create a billing agreement. You can make the customer approve it by redirecting them to the appropriate place, and then execute it to start the cash flow. Obviously, it takes an agreement ID to do anything with it after creating it, so it would make sense if creating the agreement gave you an ID, right? Well, it doesn't. When I wrestled with it a few years ago, there was already a few-years-old bug on their github about it, and the workaround was to extract the part of the approval URL which contained the EC-token. If you sent that part of the URL later to /agreement-execute, it would set things in motion... and return you the actual ID you wanted in the first place. I just checked the docs and it still hasn't been fixed, but at least they're self aware now and the documentation actually tells you to use the EC-token as a temporary agreement ID until you get a proper one. I'm not sure if documenting a hack is something I prefer to fixing a bug; at this point I'm just happy I don't have to work with this pile of crap anymore.
The issues with billing agreements just never stopped. Another one we faced had to do with the agreement start date – the documentation said that the datetime needs to be in the future, which makes sense. "5 minutes from now" worked in testing. But then every now and then there would be a customer for whom the error would come up again. After bringing the issue up with paypal support (let's just say that the level of their english matches the quality of the REST API), we eventually deduced that paypal takes the agreement start time and adjusts it according to the users's timezone – therefore sometimes it would "roll back the time" before the current datetime (which of course wasn't timezone-compensated). Where do they take this timezone data from? Who knows; not from the API call inputs, that's for sure – nice, functional design.
There were more like these and I could go on and on; eventually we shut down all the paypal integrations except for the simpliest, one-time payments, and pushed the paypal payment option very far in the payment interface, hoping that most of our customers won't find it too easily and will just use Stripe instead.
I think it is more that the documentation is poor, and that they have multiple versions of things so Googling can bring back answers that don't apply. PayPal also lacks many features that are easy in Stripe like changing billing plans or prices. Of course the REST API is just a REST API, so calling it isn't any harder than calling Stripe's REST API. We did a SaaS subscription implementation in Stripe and PayPal, and while it ultimately took less code written to implement PayPal, it took at maybe 5 times as long to complete. The time wasn't the issue, it was that it was insanely unpleasant. It made me hate PayPal - I flip off their offices when I drive by.
Agree, I have integrate lots of API and paypal is oldest of all and they know what to do. Yes since they introduce braintree they get lot more options and it get confusing when searching on internet. But if you follow their guide aka follow Composer based installation of API it will become relaitvely easy to find information.
I was looking into payment processors the other day and came across Paddle[0], which seems to tick a lot of boxes that make things easier for small businesses that don't have much of a sales team, such as handling any payment disputes for you and follow up with near-missed conversions.
They also automatically remit local taxes, for small businesses that want to operate globally.
But I have not actually used them. Can anyone else chime in with actual usage experience of Paddle?
I've used Paddle to handle sales of my $25 macOS desktop app, by integrating their macOS SDK + using website integration. Works great, easy to integrate, good admin panel, straightforward to receive payouts. And as an EU business they handle all of the VAT stuff for me (awesome!) -- no VAT MOSS mess. You have a direct B2B relationship with them, where they give you reverse invoices your accountant can book in. Support is also friendly, helpful and very responsive.
In short: would recommend. In my opinion fees are reasonable for the service they supply, and I'm sure they would reduce them if you sell more than say $10k/mo through their platform.
I just knew I wasn't interested in building a complete billing system for 5% + $0.50 per sale, when Apple takes 30% on each sale. They also have affiliate support, which is interesting. But the $0.50 fee might be a bit steep if you're selling a product < $10 -- worth reaching out to them about that.
As a user of Paddle, it is expensive but it has one thing the others don't - the ability to bill Indian customers. Paddle can actually handle Indian customers who don't have an international credit card. Magic.
The trick to using Paddle is use two providers and set the prices in Paddle to be slightly higher than the cheaper provider. In the end those that can use the alternative do, and those that can't, use Paddle.
I'm using Paddle to process recurring payments for a subscription based Chrome extension (https://www.checkbot.io) and I've been happy with it so far.
The general way you integrate Paddle is to add JS-based Paddle checkout buttons to your web interface. On checkout completion, a web hook is sent for the payment success event. I use this to trigger a Google Cloud Function which creates the user account and sends out an email to the customer for how to log in to their account.
Paddle let you sell to most countries in the world (see https://paddle.com/support/countries-supported/ for exceptions) and deal with all local tax, compliance regulations, VAT and invoicing for supported countries for you.
I generally haven't had to give a second thought to where I'm selling to which is great for solo founders as you can focus on your product instead.
For example, when selling from the UK to other EU countries, about 20% in taxes is deducted on each sale, where Paddle will deal with compliance of tracking where the sale came from and giving VAT refunds to VAT registered businesses along with accurate invoices. This really isn't an area I would want to take any risks in getting wrong.
They also give email support for customers concerning payment, invoices and tax issues which can help as well, although it can be confusing for customers who Paddle is and whether they should be contacting you directly or Paddle for help.
Most times I read about Paddle being mentioned in comments, the primary message is "expensive!" but I don't think this is fair. Unless I'm missing something, by going with Stripe I'd have to handle tax and country specific compliance myself which sounds unfeasibly time consuming and risky to me. Until you're making a large amount of money, your time would be better spent elsewhere in my opinion.
For people selling to multiple countries on Stripe, what do you do about keeping up with country specific taxes?
Paddle is quite nice, you get many payment options like PayPal, credit card, wire, etc in one. All unified in one API, which works great. It also offers invoicing + VAT handling for customers, which is great as well. The big disadvantage is the steep pricing, you easily pay double of what Stripe+PayPal would cost.
My experience running Pinboard (which offers Stripe and PayPal as payment options) has been that PayPal is indispensable if you want to collect payments from people outside the United States. There are also common situations where Stripe doesn't work (for example, the customer only has one credit card and it's declined) but PayPal does.
Stripe is far more pleasant to use and implement, but continue to see around 2/3 of my payments coming through PayPal.
We took Michael's feedback from his original article at https://fman.io/blog/paypal-for-saas-99-problems/ very seriously. We're not all of the way there yet; but if anyone has any remaining concerns about the integration, I'd be glad to take them onboard!
PayPal still cannot get its UX right for people resident abroad when adding cards. For example, their telephone number country picker determines the zip code validation, not the country of the billing address. It was quite frustrating and silly to discover.
Another reason to prefer PayPal is that you often have to fill in less fields, transferring your payment, email & shipping address is just a click vs. filling out an entire form.
I recently changed the order form for Candy Japan to ask only the minimum amount of information, and the difference is quite huge for PayPal vs. credit card: https://www.candyjapan.com/subscribe
Is that a special deal you get through Shopify? It sounds less than normal fees?
We use iZettle now for in-person transactions in our shop instead of a traditional PoS card terminal. We're getting 1.75%, but they're cardholder-present, scanned+pin, transactions which are very low risk.
Barclaycard decided we suddenly needed to pay PCI DSS noncompliance fees (our only equipment being their mobile card machine - so no storage of details possible, no network involved, etc.). Cheaper this way, our only loss is no CNP.
Do you sell really cheap products or something? Paypal's fees seem pretty normal from what I've seen: the worst rate, for low-volume sellers, is 2.9% + $0.30 per transaction. So if you're selling things that are only a few dollars each, then those $0.30 fees are going to add up to a significant portion of the product. How is Stripe better?
I'm a fan of Transferwise and recently opened a business account with them. It was a very easy process, even compared to other UK challengers like Starling (who aren't that great, really). They give you a SortCode and AccountNumber. I'm very interested: what is missing for Stripe/PayPal integration?
Both these services require small deposit, automatic withdrawl for verification purpose, transferwise account does not support the automatic withdrawl part.
I assume you are correct about the automatic withdrawal, however I was able to confirm my TransferWise account with PayPal just last week. PayPal deposited the two small txns in the Transferwise borderless US account. It took a lot longer than I expected, but it did work. I was able to withdraw from my PayPal account into the the TransferWise Borderless account (no fees yay).
Must have been a recent development then, when I tried to link Paypal to Transferwise back in January it didn't work, I called customer-care and got them to manually add it then they again sent the verification amount which they couldn't withdraw and once more blocked my account.
Same issue trying to add it as backend to Stripe, Shopify etc.
> Supposedly, Braintree make it possible to integrate PayPal much more easily.
I've recently gone through that process for our startup (https://sendingbee.com/) and I can attest to that. Once both of your Braintree and PayPal accounts are set up, you just link the PayPal account from the Braintree administration with a few clicks and it's immediately available to customers (if you use the Braintree Drop-in integration that is).
Yes. Once a user goes through the Dropin UI (which involves signing up to their PayPal account), you get a "payment method nonce" which is then used as a parameter when creating a subscription.
I am most certainly biased since I work at PayPal and am responsible for APIs that you might end up using but I would without hesitation encourage any small/medium size business to have a PayPal Checkout enabled - it doesn't take much to put the PayPal button and you can see the results for yourself and be the judge. For a broader question of credit card processing I think there are quite a few comments already.
I completely empathize with some of the concerns around using our APIs and more broadly around some of the operational policies, pricing etc. I cannot claim to speak for all of it but since the last 2 years we have been paying serious attention to how we can surface our capabilities in a way that's more understandable, approachable and meaningful to developers.
Can you add a faster way to flag a suspicious transaction for review? Currently we have to call support or send an email. It should be as simple as issuing a refund.
I suppose for small businesses PayPal could work, but for an event I wouldn't touch it with a 10 foot pole. I've read too many stories about accounts getting frozen just as money started to come in, and with organisers not having access to the money they needed, they had no option but to cancel the event.
Apparently sudden increase in payment triggers PayPal's 'this might be suspicious' flag, and once flagged, they apparently like to block until they're sure that the customers are getting what they're signing up for. But because they block the money, they're ensuring that customers are not going to get what they signed up for.
Of course if PayPal as payment option brings in extra customers, you'd be crazy not to accept it, but I wouldn't put all my eggs in that basket.
AFAIK Total Commander was fman's main motivation (IIRC the developer mentioned that on the bootstrapers.io forum). It'll be interesting to see how it evolves, but TBH i find Total Commander perfectly fine and i love how lightweight it is (...compare win10 calc with tc...) while providing a ton of features. And while i understand the (fman) author's point about lifetime licensing, i still prefer TC's lifetime license.
yep. no easy way (via "settings") to change the font and my old eyes need the default font size bumped a few times. I did the tutorial which is excellent and got me up to speed quickly! no way to search for a file, at least I didn't see it in the docs. there is a plugin for "fuzzy" search within a folder but not the entire drive. it's a great little utility but isn't done cooking and the $18 ask is a bit much as it is now IMHO.
it captures data by default... https://fman.io/docs/metrics at least he is open about this. still don't like that is it ON by default or that it's built in to the core code.
Back in the day, before there was the beautifully simple Stripe, I had to implement payments on Authorize.Net, which made PayPal's APIs look great. It was cumbersome, ugly, they had libraries that weren't documented. I was on the phone with their support multiple times in the week it took to implement. And then after implementing it and pushing it to production, customers started using credit card OVER PayPal, and within a month we were fielding over 10 charge backs per day. And within 2 months we abandoned taking credit cards all together which alienated a subset of our customer base who lived in parts of the world that PayPal doesn't allow accounts for.
I never leave any amount in my PayPal account that I'm not willing to lose. I've been flagged before which I why I do it. I was flagged for having a surge in sales, which was legitimate but meant I couldn't access my funds to service the customers who were paying me.
If you only have a few products with fixed prices, integrating PayPal is a matter of defining a button for every product in their UI, copy the HTML form that is generated next to the button and then submit a POST request to PayPal to have the user start the PayPal checkout flow.
Stripe's new checkout system works similar. You define products in their UI and submit a request with the according SKU. The advantage of PayPal is that it requires zero JavaScript. It's just a POST request.
Of course, you need to listen to PayPal's IPNs to process a payment on the server, but this is exactly the same effort as with Stripe.
I service small businesses, and hook them up with payment processors on a regular basis. Not once, over 19 years has any of my clients' customers requested PayPal as a payment option (I've deployed over 100 ecommerce solutions). This must be specific to software or global purchases (my clients are in the US).
My advice always starts with the "easiest" which is PayPal. If they have WooCommerce, I recommend Stripe, before Stripe existed the advice was to go with Authorize.net.
I use both Paypal and Stripe on my website. I've had companies using Paypal to pay $1,000 a couple of times. Both work fine for me. But dispute resolutions are random with Paypal (never had any with Stripe). I just had a few on Paypal: some where I gave no information and it was resolved in my favor, other where I proved taht the customer made repeat payments from the same IP address but Paypal decided one payment was not actually done by the customer.
If you only offered one do you think you'd see a drop off in sales? If you have the volume, would you risk an A/B test to confirm the loss in sales versus the loss in fees? I'm guessing, from other comments, that many customers prefer PayPal when it's available.
Context - small business, using PayPal for almost five years, large transaction values, small transaction volumes, global dispersion of customers, multiple currencies.
1. PayPal works (mostly) without issue for customers from a wide geographic region (my customers are from many countries all over the world).
2. The exchange rates offered via PayPal are TERRIBLE. Several percentage points, on top of the several percentage points initial processing fee. Either the business, or the customer, is paying for these bad exchange rates (dependent upon the source/destination of funds). This can be an additional five percent.
3. Customer service from PayPal is lacking, but in the case of disputes, things have worked out in the way I would logically expect, around 99% of the time. In the other 1%, PayPal refunded the money, I have never lost anything (neither have my customers) due to disputes.
4. STRIPE has categorized my business as high-risk, and therefore won't offer me their services. I won't specify my business type here - I can safely guess there is nobody on this planet that would consider my business type "high-risk".
Some of the categories of what constitutes a high-risk business are obvious - gambling, porn, etc etc, other categories make no sense at all. (I have never had a single disputed charge in four years of operation)
Semi-regularly, I search and compare cc-processing alternatives. Mostly, due to the currency exchange fees, poor customer service, and stories of PayPal accounts being frozen/locked due to spurious reasons.
I consider PayPal the best of the worst choices.