Stripe is PayPal circa 2010
learnjsthehardway.com
learnjsthehardway.com
The website doesn't work, the email doesn't work, I charge it back every single month, yet Stripe doesn't care one bit.
Attempting to contact Stripe results in emails asking if I need help resetting my password (yes I legit sent an email asking for them to investigate the "company" and they sent back a reply with details on how to reset my password), to telling me to contact my credit card provider.
Honestly both companies are giant bags of turds, if you can you should look elsewhere, you can save money on almost every fee, there are alternatives to every single product they provide, and pretty much all of the alternatives are varying degrees of better or cheaper.
The AMEX people just keep saying Stripe has a "iron clad contract" so even with that, they cannot do much.
I am not saying it is a 100% Stripe. But why would a company like Stripe allow me to do (successfully) 7 chargebacks in a row. At what point would an account be shut down or a subscription terminated? If this was PayPal, the account would have been frozen ages ago.
Even with a brand new credit card, reported as stolen, what ever. If a monthly subscription contract exists (which you sign once you click that button to pay $5 monthly I guess), they can continue charging the account.
This was what AMEX rep told me.
I guess this is both for customer convenience and to give the bank more flexibility, but I think this would be a lot simpler if closed credit card numbers just stopped working.
https://stripe.com/docs/saving-cards#automatic-card-updates
> Stripe works with card networks and automatically attempts to update saved card details whenever a customer receives a new card (for example, replacing an expired card or one that was reported lost or stolen).
> It is widely supported in the United States, allowing Stripe to automatically update most American Express, Visa, Mastercard, and Discover cards issued there.
My god.
It doesn’t quite work like that in Europe, as far as I know. The fact that you file chargebacks over and over and they don’t do shit is even more insane.
Which is annoying in its own way because when your card expire, you need to manually re-enter its new details into all the services you're using. And you (or at least I) will inevitably forget one of these until you need it urgently.
I would get super annoyed at the US behaviour.
Although in the US people still subscribe to "newspapers" where you can subscribe online but have to wait for hours on hold on a hotline to end the subscription...
Not to pile on poor Sam here. This is a common thing in the finance industry, and tech, and basically everywhere.
The fact the founders quickly offered assistance directly, when they’re business is worth tens of billions is at least worth giving the benefit of the doubt. Even if it’s just for PR, they’re at least doing it.
Why the hell would you praise a company for an empty gesture? You're defending bullshit like it's a good thing.
I’m assuming they’ll fix the problem, even if it’s just for PR purposes.
Anyway I misread your previous comment, sorry about that.
While it’s a fair point that with PayPal, you are almost entirely SOL, whereas with Stripe you at least have a chance, it’s not a tenable solution.
The problem is they decided to leave up their Stripe account and just stop replying.
What am I missing?
I'm sure most devs have an experience where something is broken for weeks before you happen to overhear someone talking about the multi-step workaround for a 5 minute code fix.
I think the same kind of issue applies.. Support teams are encouraged to not escalate, if they do, it often goes to a higher level support (but not any developers/business people). They find a clever solution and that becomes the common practice. It's not until a big stink is made that the right people are aware of a possible problem, and perhaps only then investigate the scope of that problem, and realize it needs prioritization.
Of course, this doesn't answer why the support team didn't even read the email to see you're not asking for a password reset... But might be a contributing factor.
https://github.com/mastodon/mastodon/issues/5634
So people came back to empty timelines. Terrible UX, but until someone both experienced it and mentioned it, no one with code access realized how bad this was for returning users. Now there's a friendly message letting returning users know what's going on.
What helped fight this was to create a rule in Radar to reject all cards without 3D Secure capability, but it had cut off a sizable chunk of legit revenue.
Something cheap turns into a $15 dispute fee.
(Disclaimer: I used to work at Stripe on the dispute resolution team. I no longer work at Stripe.)
If your fraud has a large enough monetary value, large enough scale, or you work with another person on it, you can get hit with a serious felony charge and end up in prison for a few years. Disclaimer: I am not a lawyer or expert on credit card fraud.
Sort of like the highway system relies on an agreement not to play bumper-cars. There's nothing actually stopping anyone.
Self-preservation.
A chargeback with stripe costs like $15 for the seller. Even if the charge was only $1.5. Imagine the monetary problems you could create and the seller has no other way than to pay and hope to not get banned.
Anyway, the merchant eats fraud for card not present transactions. So why would the bank choose to reduce its payment volume in order to reduce fraud it doesn't even have to pay for?
If the merchant says 3D Secure only, it reduces fraud, but also reduces payment volume, because most customers will choose to use a merchant with less friction, especially if their issuing bank doesn't do 3D Secure, or it's broken when they go to purchase.
Reducing fraud is good for merchants, but it the drop in sales may not be worth it. There's a lot of other things merchants can do to reduce fraud that aren't likely to cut into sales as much.
Block every single fraudulent or suspicious transaction, and you're leaving obscene amounts of money on the table.
The amount of credit card fraud that goes unclaimed or is eaten by liability shift is huge, so if Stripe makes a product like Radar ACTUALLY WORK, they would be missing out big time.
I am confident Stripe's radar's shortcomings are deliberate and not simple bugs or design problems.
It appears they have no incentive for the product to be 100% effective and that would explain why Stripe Radar is billed per screened transaction, regardless of outcome.
We benchmark Stripe Radar against other pure play fraud fingerprinting solutions, and the difference is abysmal. The fact that Stripe claims to have seen 80% of any card before it gets to your store make this fact even worse.
So, like parent says, you are going to see radar scores of 90 and 95 for certain charges (clearly fraudulent carding attempts), followed by scores of 15 or 20 for the same card, IP, fingerprint with absolutely no warning.
I've grown tired of escalating this to Support. They just give me the ML model answer. Basically: "It's a black box!"
You can definitely add a rule to start blocking charges from X places, or with Y velocity, or always enforce 3DS, but then you're taking the model into your own hands, and that has some important consequences.
Your acceptance rate goes down. You're heavily interfering with the model and relying (and trusting) it less, and you realise you really don't need Radar to do that for you.
If you're serious about fraud, you must use a pure player solution that is 100% aligned with your interests.
From what we've seen with Stripe Radar in the past, that doesn't seem to be the case.
I'm a big fan of Stripe in may ways, but I really have a love/hate relationship with this side of their business...
Stripe Radar costing money is a bit annoying too - my solution was to block non-Australian cards - but the only way to do that is with Radar, which costs money. Radar doesn't let you whitelist currencies either.
What's a payment method actually worth where you have so little control if the payment succeeds?
Would much prefer a solution simpler/easier/less devstating than dropping Mjölnir on it.
As far as I know, it's not granular, per-merchant, so you can't skip the fraudulent merchant while updating the legitimate ones.
Furthermore, some banks may not even give control to the user about whether this happens or not.
Customer can see these tokens anytime, along with merchant details, and customer can revoke these tokens anytime.
At that point it becomes a legal problem for them and I suspect they'll be forced to take more serious action.
This doesn't sound like a particularly difficult bar to clear.
- The damages in question would exceed hundreds of thousands of dollars
- You want to make an example out of the defendant and have lots of money to burn
- You are engaging in litigation as part of a settlement extortion scheme ala Prenda Law
America does not award legal fees to the victor - in fact, it's considered so un-American that American lawyers literally call it the British Rule[0]. As a result, small actors - which you almost certainly are - will bankrupt themselves just getting to the discovery phase, regardless of if they are plaintiffs or defendants.
In a few situations, this has become such a problem that US law either provides time-saving motions for common forms of nuisance lawsuits[1] or uses it as a way to encourage certain behaviors[2] out of litigants. However, this kind of fraud case will almost certainly not fall under such measures, and you are almost certainly too small to defend.
Representing yourself in court is technically possible but practically a death sentence to your case. And an actual lawyer would tell you exactly what I've told you, except with actual attorney-client privilege[3] involved, and they'd charge you for telling you that. Except they'd probably also add in a bunch of stuff about class-action waivers and binding arbitration[4] that would make it nearly impossible for them to represent you.
[0] I've also heard French Rule.
[1] Such as Anti-SLAPP motions, though these are not in federal law yet.
[2] The copyright registration system comes with a few key perks; notably statutory damages and the ability to recover attorney's fees. If you do not have either you cannot economically sue a copyright infringer, which sounds like a really good way to comply with Berne without complying with Berne.
[3] I am not a lawyer.
[4] For what it's worth, there are some crafty lawyers that have figured out a way to help people mass-arbitrate, but companies are trying to fight back against that too.
Sue them in small claims court. You won't get significant money, but they'll have to burn a little money on lawyers. You have the chance at the moral victory of the judge saying you're right*. You probably have a decent chance of getting on the HN front page when you first file and when you win/lose. You have a noticably higher chance at being covered in the mainstream media than if you just complain on the internet.
*The judge generally doesn't literally say you're right
There are several other Merchant of Record alternatives, but I have not found something that can do quite the programmatic approach you can with Stripe.
I am a customer of their banking service and I played with their APIs. It feels like Stripe at the beginning, hopefully they'll be good for this decade
Unfortunately, I’m going through a divorce right now so I can’t cancel that credit card. But, as soon as I’m free that’s on the top of my list of things to do to start living the rest of my life.
https://usa.visa.com/dam/VCOM/download/merchants/visa-accoun...
https://developer.mastercard.com/product/automatic-billing-u...
https://www.americanexpress.com/us/merchant/cardrefresher.ht...
It’s Citi’s fault for not flagging the change being for fraud reasons, which skips the updaters.
Also how should I describe a rather basic problem? I told them every aspect of it multiple times to multiple tiers of customer service. Email chains (or lack thereof), website details (include login), they already have transaction details.
I am not saying it's a 100% Stripes problem, I am wondering why I am able to chargeback it 7 times in a row, and that does not trigger any red flags. If a single customer chargebacks a "subscription" multiple times in a row, should that not be an immediate cancel?
Why can I not go to Stripe, fill out my credit card, and click cancel and cancel a subscription? They already have a portal to get transaction information, why not allow me to cancel. Since it's all webhooks anyways, what difference is it if it is through X merchant site or Stripe?
customer -> card issuer (amex) -> card network (amex) <- card processor (stripe) <- merchant -> customer
So as you can see, you have no relationship with Stripe. Your have a relationship with Amex and the merchant. Those are your points of contact.
When you make a chargeback, Amex accepts this chargeback, and sends it to the merchant's processor, who then presents it to the merchant for response. This is a process defined in the contracts between each of the parties.
To your other question regarding fraud controls in this system, that's handled in the contracts:
- If you skip out on your debt, Amex must still pay for any charges they authorized. (The payment flow is customer -> Amex -> stripe -> merchant. This flow is reversed for a chargeback/refund.)
- If a merchant skips out, stripe is still responsible for any chargebacks.
Think about what this means: If stripe accepts too many high-risk merchants, they'll lose money. If Amex accepts too many high risk customers, they'll lose money. So they each have an interest in controlling fraud.
So what happens when a merchant gets too many chargebacks (typically less than 1%): Stripe will refuse to do business with that merchant. Why would they do this? Because if Stripe has too many chargebacks, the card network will refuse to do business with Stripe. They may be able to recertify as a high risk processor, but that comes with additional requirements... and if its above those high-risk levels, the card network won't allow stripe to process any payments at all.
This is all defined contractually.
What is the contract you have? You have a contract with Amex: your credit card terms. And you have either an implied or explicit contract with the merchant that they must meet.
Stripe and Amex are not fully aware of your contract with the merchant (refer to first relationship graph above). Part of the chargeback process is the merchant's response. A valid chargeback defense is that the charge meets the contractual terms the customer agreed to (assuming nothing illegal is going on). When the merchant presents the contract in their response, Stripe and Amex can review that contract. Amex (as the card issuer) gets to decide if they accept or reject the merchant's response and issue a decision on the chargeback. (Stripe (on behalf of the merchant) can disagree with this, and it then goes to the card network for a decision.)
So that's the whole process.
If you go to stripe directly (as a customer), you're attempting to do an end run around this contractually enforced process... and stripe isnt going to do that (unless they want to be sued for tortious interference by the merchant).
So hopefully you can see why Amex telling you to call Stripe is so bizarre. What makes it even more odd is that the type of dispute you have is something Amex handles like a 1000 times a day... they have a process for it.
And FYI: Amex can block a merchant from charging you in the future. (Easy on their part: just stop authorizing the charge from the merchant.)
While I believe everything you said, I have not experienced it.
Sometimes when I’m on with CS, if I let it slip that I know a little something about what’s wrong they take the easy out and send me on my way by regurgitating what I just said as the solution.
The average person doesn’t know anything about Stripe or payment processing. I find it hard to think Amex would steer you that way out of the blue.
Is Amex really saying “here’s a phone number to some third party, resolve it yourself”? Totally unprompted?
I would call in and pretend to be as dumb as possible. All you know is you keep getting charged and you don’t want the charges anymore. The business phone number you have is disconnected. Let them take it from there.
Your best bet is to get in contact with someone who is in sales who can escalate this to an engineer or other more technical person. One way to do this may be to declare that you will tell your customers AMEX is no longer acceptable unless they help you resolve the issue. This may seem harsh but I bet it would work at AMEX and not a VISA or Mastercard
No idea why this is, and no idea why anyone would give out his data to unknown companies under this conditions.
This means it's an 800 pound gorilla in a dev/bay friendly costume (docs? API?).
They cannot fix the financial system unless they can become Wells. That will not happen. Thus, their actions, pricing, and product development choices all point to Wells.
PayPal has this exact theme of a problem. Or lack of solving.
[0]
Essentially, they screen transactions; if any approved transactions are chargebacked, they refund you.
A good start point is https://signifyd.com
We dropped in this solution on our e-commerce about 5 years ago; fraud has been a non existent problem.
As expected, just a couple of bucks accumulated. Then a user sent an unsolicited $15 donation, along with an accompanying comment, asking for macOS user support, for help solving a user issue entirely unrelated to my project. I declined, explained the situation and offered to refund the donation. I never received a reply, but immediately after, I received a chargeback notification. Stripe took the $15 from my account as well as a $15 chargeback fee. The user claimed fraud. An appeal went unanswered, despite me providing all required proof.
In the end, this little experiment cost me money. It also opens up a disturbing avenue of hurting someone financially, given enough credit cards and chargebacks.
PaymentIntents workflow (including the necessity to listen for webhooks) deserves a special place in hell. Its like they decided to copy Paypal IPN.
I have used, recommended and intgrated Stripe to multiple businesses over the years (generating hundreds of US$ millions). For the past 2 years or so, I have migrated most of them away from Stripe, and any new integrations are done through other payment processors.
I'm working though Stripe integration for the first time. It's one of the worst APIs I've ever dealt with.
I couldn't find a single place advising which webhooks to listen to - or what their payloads should be - for simple subscription behavior. It's actually inconsistent in places.
They built and accrued all of this complex billing behavior for all of these incredible upmarket needs, and in the meantime they forgot about the simple cases.
I almost used PayPal or Square. Perhaps I should have.
Stripe seems to have moved on to upmarket.
Genuinely 3 months of development, with more roadblocks than I could have ever imagined.
Braintree user here, have I got news for you. I regularly have to waste weeks of developer time on payment processing. The documentation is terrible and fragmented, some things are not explained anywhere, support response times hover around two weeks (I'm not kidding), and the canned support responses rarely fit my use case, so there's always a back-and-forth.
This would all be fine if I could just get it done once, but the thing rears its head regularly, what with the newer PSD2 regulations or something else.
As an example, after having done all the 3DS2 integration work (well, it was closer to re-work, as extensive changes were required), Braintree now tells me that 3DS1 is being deprecated (fine) and some of my transactions are 3DS1. Well, which ones, and WHY? I have no idea. I asked support on Sep 27, that was 12 days ago, no answer.
I looked at Stripe and had a really hard time understanding how I can fit my subscription SaaS into it. I think if you fit the simplest common use case and you're willing to outsource everything, Stripe could be simple to use. If you want to be independent in any way, or want to maintain the relation to the customer yourself, things quickly get difficult. But the real reason why I can't even consider Stripe is multiple currencies: I want to settle in three currencies (including USD), and Stripe will only settle in USD to a bank account based in the US. Good luck getting a US bank account if you are an EU small business. Also, pricing looks reasonable at a first glance, until you notice the currency conversion fees and the extra "billing" fee. In my specific case I would end up at about 5.4%.
Stripe's forex fees are horrendous. Wise charges <0.5%, Stripe >3%. The spread here is similar to the credit card charge in the first place!
I am currently involved in a project to add Stripe support to a product, and it's a lot more complicated to set up a simple payment than other APIs on the market.
From everything I'd heard about Stripe, I thought the API would be really simple, but it's not.
Stripe abstracts away all the complexity having to deal with dozens of payments methods behind this single PaymentIntent API, which let you query the status of a payment at anytime (and webhooks are just a way to listen for updates in realtime).
There are ways to deal with that - a very simple one is a "mop up" process, as suggested by the GOV.UK Pay Service:
https://docs.payments.service.gov.uk/integrate_with_govuk_pa...
I don't get the complaints here. Yea, it is hard to write payments workflows. Learn to properly organize your backend to account for all edge cases. Use stripe test clocks. Use mock objects and stripe CLI. Everything has been handed to you on a silver platter by Stripe IMO.
PaymentIntents and SetupIntents make setting up a basic subscription Billing interface incredibly painful. The documentation is awful and spread across multiple sections of the Help pages so you have to read multiple articles to piece together how it's supposed to work in your specific scenario.
Even understanding when a PaymentIntent is recommended vs when a SetupIntent is needed takes some doing.
And don't get me started on trying to understand whether I need to use the confirmCardPayment or the confirmPayment or confirmCardSetup etc etc functions.
And again, this is the kind of thing that happens to PayPal all the time. The fact that some random lawsuit that never even required a substantial reply from PayPal got picked up by Zed as evidence of their bad behavior "finally catching up to them" really erodes my confidence in the way he represents any of the other details in this article. What else is he misrepresenting or exaggerating?
It's not merely the cost of doing business, it's the cost of avoiding judgements against bad practices.
Do note that Paypal did lose some suits, notably in Quebec for example, where customers protection laws are stronger and arbitration clauses in user agreements cannot force you to forfeit rights you have under the law, in particular to sue.
https://lastattorney.com/paypal-class-action-lawsuit-settlem...
A few examples of these clauses being exercised were on HN (both cases pending) - https://news.ycombinator.com/item?id=29935515
- https://news.ycombinator.com/item?id=32739950
If it wasn't obvious, cherry-picking bits and pieces from various jurisdictions isn't legal; PayPal deftly deflects any legal challenges to their various dispersed entities making them essentially untouchable if you don't have unlimited resources.
If anyone is interested, in the EU, this is their playbook:
- Ignore all communications unless it's a C&D from lawyers
- Deflect responsibility to PayPal Luxembourg.
- They have, or have had literally 90% of LU lawyers retained, meaning your case will not / cannot be accepted by the majority of LU law-firms due to conflict of interest
- Deflect onto the CSSF (Luxembourg Monetary Watchdog)
- Respond to the CSSF that the complaining company is not based in Luxembourg, which results in the CSSF concluding that they are not the competent structure to rule.
- Case closed, your funds have been stolen, and PayPal has artfully dodged the relevant regulatory bodies.
Also, one of the things that are wrong in this post is about Stripe rasar(fraud prevention). It's included in standard pricing, it's not 4 %...
My experience over 10+ years using PayPal and 5+ years using Stripe is that Stripe has much better docs. Just had something stop working because PayPal changes their webhooks, and even their docs are wrong.
Just a few hours ago a customer opened a PayPal claim, and now PayPal took the money hostage. The customer closed the claim, but the one case number the customer has resulted in 10 case numbers for me, and they are still open.
When it comes to "friendly fraud" (customer buys something, and claims it was not them after receiving it), it would be hard to do a worse job than PayPal.
If a customer opens e.g. 15 claims for unauthorized use, basically stating that someone else used their card, PayPal usually always agree with the customer on like 12 of them, while 3 of them PayPal think was legit. Sure PayPal, someone stole their PayPal account, purchased digital goods on my service on an account belonging to the PayPal owner that the PayPal owner clearly is using according to me and PayPal themself.
Chargebacks usually costs money, but PayPal claims is basically just a click to take money from the seller, with no risk. So just that possibility makes PayPal much worse than Stripe.
Stripe isn't perfect, but support is better and at least it's much more resistant to friendly fraud.
What the article says is that PayPal allows payers to request a refund, which is not a chargeback and is free to the vendor. Stripe does not have a dispute or refund process other than chargebacks and they charge vendors $15 for each according to the article.
Radar is not free. https://stripe.com/radar/pricing
There are other features of Radar that are built for fraud teams (not likely to exist at small companies), which cost extra.
I have a credit card issued by a bank in country X, but my home address both in reality and in bank X's records is in country Y. This seems to consistently trigger that fabled PayPal fraud protection the article mentions, making it impossible to enter my information correctly. After lots of poking about in the dark, I eventually figured out that the only way to make PayPal payments through this card is to set my country as "X" and enter a completely fictitious address in X with a separate delivery address in Y, after which the transaction sails through happily.
PayPal required for a few years that I use a VPN for being allowed to log in. All the support could do for me was offer to close my Dutch account so that I could open a German account to use here. I hear that others have no problems using PayPal while on holiday abroad, so not sure what's up with that. Sometimes it also throws javascript errors and gets stuck on some loading icon. Plus all the horror stories about paypal.
The things that always worked effortlessly for me were iDeal (collaboration of Dutch banks for online payments), regular bank transfers (always free in the SEPA zone, but takes 0-4 days depending on bank holidays and servers that take a weekend off), and direct debit (provide your name, address, and IBAN, such as at Liberapay, and everything will be arranged automatically). Basically, the European stuff simply works, not sure why.
At least with PayPal if I sign up for a $10 a month plan I can go into PayPal via the very very difficult to find recurring transaction area and cancel said transaction. I cannot do that on Stripe.
I strongly feel that I should be able to cancel ANY monthly transaction without having to go through the hoops and juggling act that is attempting to get the merchant to cancel said transaction. If I want to cancel a subscription why do I have to convince someone else to do it.
Just let me cancel my stupid monthly subscription since everyone wants to do them.
If you use Apple’s App Store, similar to how they let you view/manage all subscriptions on one place?
(I build things at Stripe, in a space that’s relevant to this use case.)
https://support.stripe.com/charge-lookup
For general context, Stripe started as completely opaque from consumers. We’re growing in that direction, but the start was business uses.
The hackerspace I'm involved in currently has to use Open Collective [1][2] (alongside PayPal) to do so, but there's a ton of onboarding friction:
Some have pointed out that they had been running in circle between Stripe and AMEX. Maybe AMEX is special I don't know. If there's a problem with my payment and the company responsible for the charge isn't reacting, then it's my banks problem, not mine.
For legitimt companies, if there's any issue with my payment, I don't care how, you can't blame Stripe, as I have no business with them, you go deal with Stripe if they are the issue.
Overall I think many have falsely viewed Stripe as some final solution to payments. Mostly I think because they where easy to create an account with. Even before Stripe it wasn't actually difficult sign up with a payment provider and most of them where better and easier to interact with, even if their APIs where worse.
I also learned to loathe stripe (and square) due to those PoS system that have ridiculously high tipping options even for transactions that really ought not to be tipping situation. No, I do not want to give 20% tips when buying bread over the counter at the bakery, thank you very much. (This may not be stripe fault, but the store owner. I resent both just to cover all bases.)
https://www.epi.org/publication/epidemic-wage-theft-costing-...
Tangential, but the iPad ordering sucked. Couldn’t find the Flat White option, turned out you have to click into Cappuccino option first, as if that makes any sense. Oh and you order pastries from it as well. What happened to be able to see the pastries behind the window counter?
As long as we allow the US food industry to not pay employees directly, you should tip, or make your own coffee.
Hurting the employees to fix the system is wrong. Turn your wrath to the employer and the legal frameworks enabling such underpayment.
Flipper Zero project might disagree:
https://nitter.lacontrevoie.fr/flipper_zero/status/156719464...
Could PayPal be acting under government orders, on this one?
Way lower charges. Way more finicky to integrate and yes the documentation is API reference not 'tutorial'. 100% agree about the weird error cases (to the extent I think I've still not handled them all) and the asynchronous stuff (which I kind of understand but also hate).
Fortunately it's a business model where chargebacks are extremely unlikely so that's not affected us.
This liberates me from running a web server, having my own URL, or doing any kind of coding. I love coding, and do it all the time by day, but it would add a layer of complexity to my business that I don't need.
PP has worked fine for me, but they always say that you should have a backup.
Other than that, I always appreciate when one can simply fall back to a bank transfer, then I can choose to just give them 100% of the money without risk to either party (no magic fraud detection, no cut going to paypal) at the cost of waiting a few days for the payment to be confirmed. So basically, just post your IBAN on your website please and offer to tick that as a payment option. No third party needed besides the bank account that you already need for running a business.
As a consumer, I can just download the transaction list as CSV. There doesn't really need to be a standard API if it takes 5 minutes to map your bank's fields in your favorite scripting language. For business accounts, I'm presuming this will be similar, if not better because they would more frequently actually use it.
Even including thorough testing, it should be a few hours of work, and for that you can save whatever cut third parties would otherwise take before it lands in your bank account, plus the consumer doesn't need to deal with fraud shenanigans that might trip incorrectly.
> even worse, most of the bank transfers are far from instant
Yes, I mentioned that as a downside and it really is one, but for anything but food delivery I'm quite likely to choose this option. The anti-fraud on other methods, as someone frequently working across borders and with uBlock and such installed, just makes it impossible or annoyingly hard to pay too often otherwise. Plus, I don't want to give paypal more money if that choice is available to me.
This is not possible with US-style bank transfers at this time.
Like SWIFT but faster and not $25.
Most of the conventional merchant services platforms do this, but they lack all of the modern-web polish that stripe and paypal and square have. They will happily take your volume on a cost-plus basis if you can handle the absolutely disgusting 1998 web presence and lack of docs, and often the antiquated API's that use SOAP and XML.
They're great. They don't change. All payments API's are shit, but one that is predictably shit and doesn't change once you've dealt with the shit is a quasi-meta-good thing as bad as that sounds. You have a person you can speak to, they know you on a first name basis, and they do a single thing- facilitate your ability to process payments.
I think you vastly underestimate the importance of ease of use.
Management might also have a problem later in case of non-payment/chargebacks etc
But, in general, people need to look past the first impression
I really don't see how it's a hard problem either? How often does a payment gateway API really need to change? Just spend the resources necessary to get it right. If you really need to, hire (another) FTE on docs.
At first glance some docs look good but when you go to use it, it's confusing/incomplete/outdated
">People really, really, hate Peter Thiel and Elon Musk. So much so that they will refuse to give my small business money if it goes through Paypal on the off chance that those two guys might get some of it."
This looks like pure spin. I don't know of anyone who refuses to use PayPal because of this reason. (Thiel and Musk are not running the company anymore.) I know a lot of people who refuse to use PayPal because it has some kind of directive to ban people for wrongthink. There are countless instances documented on ReclaimTheNet.org [1], and those are just the ones involving people of notoriety.
[1] - https://reclaimthenet.org/page/2/?s=paypal
There is literally a campaign of people closing PayPal accounts in protest of company's behavior right now. (That $2,500 fine proposal was the last straw.) Guess what? Many people see "errors" when they try to close an account. Dark patterns everywhere.
In short, if you choose to use PayPal as a sole payment method for your business, know that you are alienating a lot of potential customers.
eBay bought Paypal in the 'Paypal Mafia' two decades ago in 2002 which is when most of them cashed out their stock. I highly, highly doubt their founder stock is still in any way connected to the various corporate iterations of Paypal that were sold and resold.
Even 10 years ago this would be a silly thing to be concerned about. Paypal has enough real problems anyway.
I have been looking at it for my future projects for quite some time.
Fees seems to be a bit higher, but it also has both CC and PayPal integrations and can take care of the taxes.
Of course, one of the big drawbacks here is conceding control of a critical part of your infrastructure to another organisation. Better hope they don’t hell ban you, or you’ll be totally screwed. But that seems to be an issue with whoever you choose.
Personally I found geoblocking the Philippines massively reduces card fraud. I’m content to lose any legitimate traffic from the country in return.
Seller accounts seem to get shafted on the regular but they still keep using it.
If Apple/Google control the UX and fraud verification, people should go with the cheapest option.
I'd love to buy a cheaper Stripe alternative, and if it has a poor UX I'd only use it for Google/Apple wallet payment, which could be more than 75% in Europe by the end of the decade.
I run a nice successful business where premium subscriptions are my primary revenue model, and I as well relied on Paypal for years as my payment card processor. Some notes about my experiences over the past 20 years
1) The Paypal hell-ban thing is real. I had a handful of customers open support tickets monthly with me and indicate no matter what they did they could not successfully send us a credit card payment using Paypal as our payment processor. Paypal just says "Nope" and that's it. For all of the customer's payment methods.
2) It's true, there is a subset of people in this world that absolute loath Paypal and will open support tickets telling you so, which means there's a lot more of those people out there that just bail.
3) A few years ago I transitioned to Braintree payments as my primary credit card processor since I wanted to resolve #2 and just provide a simple hosted credit card form. Surprisingly, the transition was pretty easy, the APIs and webhooks were documented nicely, there were libraries available, and it didn't take me long at all to get up and running quickly. The onboarding process was pretty onerous (you'd think I was taking out a 10 million dollar mortage on a vacation home) but once we got going everything has been super smooth. Highly recommend Braintree.
4) I left our existing Paypal integration in place, and shockingly almost 25% of my transactions still come from people who deliberately click on and decide to use Paypal in place of just a simple "enter your credit card information" form.
I've never run into freezes, or some of the other nightmares seen out there, but definitely payments even in this day and time can be maddeningly frustrating. And there's always chargebacks and some of my favorite customer "excuses" for demands for refunds etc. Like:
1) "My 5 year old son signed up for an account on your service and purchased a premium subscription, please provide a refund immediately" - transaction happened at 2am local to the customer and you've got to provide your credit card CVV.
2) Customer purchases a 2 year premium subscription and then opens a support ticket and demands a refund because "I'm not quite sure what this is" - meanwhile they could have purchased a 6 month subscription to try it out just fine. A surprising number of people will just bulldoze through and buy the most expensive option and then have buyers remorse.
3) "The browser autofilled everything and submitted the payment without my involvement whatsoever" - and then demand a refund. Never mind customer has to literally click the "Pay Now" button.
4) And of course the fraudulent chargebacks. They'll open support tickets and correspond with you and demand refunds and then charge it back as an unauthorized fraudulent charge. Maddening.
5) Various other crazy excuses for demanding refunds or charging back something instead of just outright saying "this isn't what I expected for xxx reason" - they'll throw spouses, kids, criminals, everything under the bus instead of themselves. It's wild.
European here, but perhaps my experience is relevant: for nearly all the online credit-card processors, this step will require push-TAN and will fail for me. A fair proportion of websites are buggy and will not gracefully recover the session after the processor reports failure. Paypal, in contrast, has always been unproblematic.
I'm patient and generally try the card before Paypal, but impatient customers in the same boat may behave differently.
IIRC Braintree is owned by PayPal, so I'm curious when to choose PayPal vs Braintree?
One more thing which I'm not sure you ran into: Braintree will eventually, at an arbitrary moment that you cannot predict or plan for, block all of your incoming funds and begin an audit. That audit can take anywhere from around a week to multiple weeks, during which time things will appear normal to your customers, but no funds will be disbursed to you. They will request various documents from you, some of which will feel somewhat invasive. From what I understand, this is routine procedure, usually tied to your monthly billing amounts, but could be triggered by other factors as well (unknown).
So, it's better to make sure the business can handle a several week long suspension in disbursements.
But, they do like to write think pieces on it.
... I appreciate that the author is willing to write something counter to the narrative!
This coming from Zed Shaw at least carries more weight than me ranting about this observation on HN.
One of the thing listed in the article that had me really worry was chargeback. And it seems to be quite common in Stripe world. In low margin world $15 is quite a lot unless you have volume.
Enough people boycott PayPal to make a web developer choose another payment product. He writes about it on HN which amplifies the boycott’s message to tens of thousands of readers. Some of them will join the boycott. PayPal’s PR department is presumably unhappy about this reason now coming up in searches like “PayPal vs Stripe.” And it didn’t take any centralized organizing.
If you win the dispute, we credit you $15 because we feel it's the right thing to do.
You might have different agreements, because you negotiated lower prices because supposedly you have better fraud detection etc.. But that's not the same as "because we feel it's the right thing to do".
On the side of the merchant you do the same.. with "Stripe Chargeback Protection", but you charge for that.
You took a part of the bank's/card's business (risk management), and that's fine, but please don't tell us stripe is doing things because you feel anything.
With Connect, you can do onboarding flows yourself with the Custom plan. Note that information gathering and regulatory requirements for onboarding across dozens of countries is a huge amount of effort. We have whole teams working on this problem alone; not for the feint of heart.
In the abstract we don’t care if you do onboarding or we do. Stripe doesn’t make money there. We offer a solution because it’s a difficult problem that we’re in a position to handle for users.
With payouts you could do something similar. I believe there are platforms that pay everything out to one bank account and then pay out to customers themselves. I’m not an expert on these flows, but I believe it’s to cut down on foreign exchange fees—preventing multiple “hops”. We’re working on making this better.
My goal is to have an approved Stripe Connect account that's controlled by my company (the marketpalce) and pull some sellers, who don't want to go through Stripe onboarding/payout, under it. Then i will build a manual payout flow on top of it.
Which platforms are you referring to? I would love to dive deeper in those.
The money quote. (No pun intended!) I doubt this article will stay on the front page for very long, because HN seems to have a difficult time with content that is critical of one of Y Combinator's biggest portfolio positions.
Finding nothing. Just have to add: Lightning Network payments are ~free, ~instant, and as bearer instruments the merchants aren't responsible for fraud.
- PayPal is trying to be a wallet for online payments - Stripe is payment infrastructure for the world