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.
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)
You don't have to be able to outrun a bear. You only need to outrun the slowest hiker in your group.
PayPal has done as well as it has because their competition has been pretty awful for a long time.
(BTW, the Stripe categorization lists differ from one country to another).
A processor just doing cross currency and settling in a few countries is much easier to do.
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).
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.
What would you say Adyen's biggest advantages are over Stripe and PayPal?
card_present, card_present_single_message, ach_credit_transfer, ach_debit, acss_debit, alipay, bacs_debit, bancontact, chf_credit_transfer, eps, giropay, klarna, multibanco, p24, paper_check, paypal, sepa_credit_transfer, sofort, wechat, or card
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.
Meaning, are they integrated directly with Mastercard/Visa/banks or do they use a First Data/TSYS/FiServ?
> merchant gateway
> merchant acquirer/payment processor
> acquiring bank
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
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).
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.
The problem is, that my PayPal does not let me withdraw money to my US account, as I am not the US citizen.
Not affiliated, don't even have a pro account, but one of the neat things of HN is that you never know who you are chatting with.
Isn't this because the flat fee is something like 50 cents, and you pay an additional ~3.x% on top of that?
Which is why I don't understand how Patreon operate at only 5%.
I don't have a Patreon account myself, but it seems like their 5% cut is separate from any payment processing fee that their creators incur: https://support.patreon.com/hc/en-us/articles/204606125-How-...
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.
i guess they have more profitable things to do than banking
Apple has Apple Pay.
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.
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.
Plus Stripe offers the same benefit of remembering the customer's card details for subsequent purchases (https://stripe.com/docs/saving-cards).
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.
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.
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.
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
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'm not affiliated with either, but I've used both.)
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.
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.
 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...
And none of the pages had any mention of the pricing they charge. Please contact sales even on Pay as You Go Plan.
This is simply not true.
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.
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.
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?
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.
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.
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?
There's also Adyen , used by Uber for example. Supports dozens of payment methods.
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!
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
People trust PayPal a lot more compared to Stripe. The dispute handling process is something which is really good PayPal innovation.
With Stripe people only have option to chargeback incase of any issues.
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.
Here (Finland) PayPal starts at 3.4% + €0.35 domestic, 4.4% + €0.35 US customers.
Stripe is 1.4% + €0.25 EU, 2.9% + €0.25 non-EU cards.
Also unpopular opinion - Transferwise for business is the most superior solution for payments rn despite its shortcomings.
Hope that helps.
Same issue trying to add it as backend to Stripe, Shopify etc.
The account name will be required in future UK banking regulations, at last, so this issue may get resolved by Stripe, PayPal, etc., just not soon.
Looks like TransferWise are interested in fixing the debitable account issue.
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).
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.
https://medium.com/paypal-engineering/launch-v2-paypal-check... is one of the first things we have launched and more interesting stuff to follow.
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.
I made a dark theme for it:
I can that doing this somehow flags you for further attention and increases risk of blacklist. Sigh...
I keep hearing this horror stories about blocking the account, AND losing all the balance. Which just seems bizarre.
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.
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.
The only customers I've had request it were a few international ones without credit cards.
(Not saying stripe rejects more. It's just the default people use first)
These also handle hairy stuff like VAT MOSS for EU customers that -AFAIK- Paypal doesn't handle for you and you have to it yourself.
Converting and withdrawing is very expensive. Better to use the funds to pay for other services.