Help HN: Stripe shutting us down with 48 hours notice on a holiday skeleton crew | Hacker News Reader

Help HN: Stripe shutting us down with 48 hours notice on a holiday skeleton crew

382 pointsthiscatis175 comments

Looking for someone who can escalate a query through Stripe (I know a lof of of Stripe are reading here including pc).

We process about 5-10M a month through Stripe since 2018 without issues. On the 27th of December they have given us 48 hours notice, whilst the entire company is being ran on a skeleton support crew to completely get off stripe and switch to another processor.

We've been in touch with them recently and this was never brought up. We've already started the process to switch do an actual acquiring bank rather than a PSP like Stripe but there's no way this can be completed now in 48 hours, IN BETWEEN CHRISTMAS AND NY.

This seems to be in line with the race to the bottom support from Stripe but pulling something like this is a new low.

So hoping that someone here can escalate.

View on HN

Just thought I'd point out that, unless the OP has moved companies, the OP runs a payment provider: https://news.ycombinator.com/item?id=27674236

That does not tie in with the OPs comments in this thread. I am happy for the OP to correct me, but thought I'd mention this.

The plot thickens..

There's always two sides to every story. I especially love the unfounded claims of "skeleton crew" as if this Stripe customer has any insight into how many people are actually working during the holidays.

He’s talking about his own company.

And if not he can just switch from Stripe to Pomelo Pay.

This is exactly what we’re doing but we unfortunately can’t do this in 48 hours.

I'll add that the OP has probably triggered this by posting a huge loss in their annual accounts to Companies House on December 23rd. I suspect credit bureau feeds have played a part in this. Oh dear.

Company status in the UK seems to be 'dissolved': https://find-and-update.company-information.service.gov.uk/c...

Seems to be active in Singapore though?

It’s Appfleet that have just filed accounts. (edit: and to reply to the person saying about numbers - turnover numbers stated are the payment processing fees, not the amounts actually transacted - see note 5 in the accounts)

Good call: that's (effectively) last year's though, so it's possible things were better this year (although doesn't look good - and doesn't seem to match numbers OP was stating).

Edit: actually, maybe not: the doc mentions March 2021 and Oct 2021 funding...

Those numbers look ok (ish)

Staff costs are roughly £900,000 of the £1.2M loss and they received investment of £5.5M

These are for year two of their business so they’re not huge losses for a venture backed business and suspect they could have sustained the same level of loss year to Dec 31 2021

I tend prefer bootstrapped businesses but these accounts don’t look too bad

Pomelo uses an Icelandic acquiring bank (actually the same as Stripe used to use) as it has its own payment license and E-money license (regulated by the FCA). This is not for Pomelo.

Thinking aloud here, it does seem like (as we've always known), anyone doing eCommerce online is effectively beholden to their payment provider.

Given Stripe is pretty popular, it feels like for many it is becoming the "S3" of payments in terms of an API. Would it be viable for others to implement the same API on the basis of compatibility, portability and interoperability?

In the past, I recall dealing with systems where you'd have multiple backend processors for major external functions, and you'd load balance which provider was used. Some might have more favourable pricing, and be a preferred partner, while others might be potential future preferred partners being tried out (see how many failures you get from them, compared with the current preferred partner).

It seems that, if this was possible to implement (card tokenization obviously being an issue here), you could have multiple independent backend providers implementing the Stripe API as a provider, and you load balance across them.

Just like how you could use another S3 API provider for storage if one is giving you hassle, or not offering satisfactory performance or support. Sure, you have migration work to do, but having the same API and underlying properties should speed things up and let you get new transactions onto the new storage ASAP.

ACME is like this for SSL - there's now multiple CAs implementing the one API. Could we get there for payments too?

A good point, and may help in this case, but often when onboarding with a payment processor (especially at the 5-10m a month level of the OP) the majority of the time/complexity isn’t the technical integration.

The complexity is usually compliance (eg KYB, sanctions checks, AML) and while payment processors have done a lot to reduce the time and complexity it can still be a long and painful process.

In my experience (I’m CTO at a payment network) technical integration is <10% the time for a merchant doing this kind of volume moving processors.

Finally, what you described has happened. A lot of payment processors have been heavily influenced by Stripe’s DX and align relatively closely, or at least closely enough to make transition easier. The challenge is that few even medium sized merchants just use the core ‘move money’ APIs that are ‘easily’ replaceable, they use things like reporting/reconciliation, anti-fraud and a host of other products that make up an ‘ecosystem’ of products that in combination is very hard to replace quickly.

> It seems that, if this was possible to implement (card tokenization obviously being an issue here)

It can be implemented, it has been implemented. Let's say that you'd like to move from one PSP to a new one, but you also have old PSP manage storing credit card information for you. All you have is a weird token, which represents your costumers credit card, but locked to you store. When you switch, you send the list of tokens to the PSP, which will then exchange information with the new PSP. Lastly the new PSP will send you a set of replacement tokens.

Granted it's not super automated, and not something PSPs will do, unless you're moving between them, but they can do it.

You're not explicitly mentioning it but this means the PSPs are sending each other the raw credit card data right?

This seems to be the case - another comment in this thread links to https://stripe.com/docs/security/data-migrations/exports, which appears to suggest that the data is exchanged to another PCI-DSS provider via PGP-encrypted JSON-dump.

That JSON-dump includes the card number, expiry, and billing address.

I believe so, either that or there's an additional level of tokenization between them and the company doing the actual integration with the credit card companies.

Most people don't realize is that paying with credit cards mean dealing with as many as four companies. The store, obviously, then the payment service provider, an acquirer and then the actual credit card company (and then maybe your bank).

The acquirer is normally pretty invisible. Some companies acts as both PSP and acquirer, but some PSP also use the same acquirer, or support multiple. In the later case, you can actually switch PSP, but keep the acquirer. In these cases I would guess that you could avoid doing having to transfer raw credit card data between PSPs.

> Thinking aloud here, it does seem like (as we've always known), anyone doing eCommerce online is effectively beholden to their payment provider.

The very sad thing is that bitcoin was designed as a proposal to circumvent this specific problem. Be your own bank and stuff like that.

Then bitcoin and other cryptocurrencies became what they became... Basically speculative bubbles.

This is a constant source of disappointment for me. I recently came across a twitter thread where an artist living in South East Asia was banned by PayPal (they were doing NSFW commissions IIRC) and felt had no real alternative ways to get paid for their work. Someone replied and mentioned that cryptocurrencies were meant to be a solution to being beholden to payment providers and their whims. And that person was then vilified for "pushing their pyramid scheme".

It's true that modern cryptocurrency is largely a pyramid scheme, but it could have been so much more.

Well, I do pay for things with Bitcoin regularly, and these payments have become much faster and cheaper recently. This month's payments: a VPN, a sim card refill in a country where I was visiting, an anti-corruption org banned in my country.

Be that as it may, there is a reason finance is regulated the way it is. Like it or not, if you implement a technology intended to create an ecosystem where that type of regulating activity is impossible, you will find every character excluded by design from the regulated system amongst your userbase. You will very quickly, come to re-invent many control schemes in an attempt to get your unregulated space "mostly safe" for normal people, but in the process of so doing, be back to square one.

This is why we (note the royal we) can't have nice things. It is also why becoming a financial services provider is a late-stage growth milestone of a business. Once you get past compliance, monitoring, and risk management boss, offering a line of credit or other finance products is an exercise in bookkeeping, and scales relatively trivially given sane accounting practices and managing your liabilities/issuing demographic.

If as a business, you achieve that and are still even remotely true to your original roots, congratulations, you're The Man(TM) now.

> anyone doing eCommerce online is effectively beholden to their payment provider.

ProviderS. Plural.

Yes it will cost more to integrate with a different API, but not an enormous amount.

https://www.spreedly.com/ has implemented such an abstraction, and stores tokenized cards centrally in a PCI compliant vault - so when the customer types in their card info, it goes over spreedly.js to Spreedly servers, and you can have Spreedly send that to Stripe for the original payment, but then have Spreedly route that information to Braintree or Authorize.net for future payments, without ever needing the card data to touch your servers. Switching to a new processor is as simple as changing the "gateway_token" constant you include when calling their API.

They've even implemented the load balancing idea: https://www.spreedly.com/smart-routing-for-payments

Pricing is in the hundreds-per-month plus cents-per-transaction, so they're not a fit for all businesses. But if you collect high-value transactions and keep cards on file (for subscriptions, SaaS, etc.), I highly recommend building on top of them rather than on top of an individual processor, as well as maintaining multiple merchant accounts with different providers. Business continuity is the name of the game!

Hi btown, thanks for the Spreedly plug!! I’m Director of Engineering at Spreedly and helped to launch routing capabilities as a engineer and leader. If the OP already has an existing relationship with a gateway(s), we definitely make it easy to integrate with a single API to multiple payment gateways. I’d highly recommend they look at a solution like ours or another provider to work reduce risk in the future.

> It seems that, if this was possible to implement (card tokenization obviously being an issue here), you could have multiple independent backend providers implementing the Stripe API as a provider, and you load balance across them

Doing your own PCI compliant credit card storage system instead of relying on your payment processor's tokenization system is not too difficult, but is a bit of a pain in the ass.

The biggest problem I see to switching between payment processors is the Visa and MC stored credential requirements. A few years ago they changed to a system where when you store a credit card you have to set a flag on the first transaction that tells Visa or MC that you are storing the card.

When you do subsequent transaction using the stored card, you have to tell them you are using a stored card and send them a reference to that original flagged transaction.

Most payment processors I've used give you a transaction ID that is something they generate, not the transaction ID that the Visa or MC network generates. If you are doing your own card storage that can lock you into using that same processor for future on-file and recurring charges on that card, because only that processor knows how to map the transaction ID you know (the one that processor generated) for the original transaction to the Visa or MC transaction ID.

Note that even if your current processor provides a way to get the underlying Visa or MC transaction ID there may be no way to use that with another processor. The other processor's APIs that take a transaction ID are going to expect one of their transaction IDs.

I'm not sure how widespread this is. Visa and MC announced their "Stored Credential Framework" several years ago. As the deadline approached for when it would become required, too many major payment processors were not ready and so it was delayed a year. By the end of that year there were still major ones not ready (Authorize.Net for example still hadn't even said what their plans were) and so it was delayed even more.

The processor we use was ready by the end of the first delay and we got our system converted to work with that, and I stopped following what was going on with the others so have no idea if it now actually is required everywhere or if there are major processors that still have an extension.

> So hoping that someone here can escalate.

Ahh the modern P/I/SAAS method of working.

What’s your resilience plan? Surely you have a plan if a supplier stops working with you? With 10M revenue it seems irresponsible to have all your eggs in one basket.

More than happy to do a post-mortem and to satisfy your valuable insights later.

While I also would love to hear what you have planned and what failed (I would have worded it differently though), even if you did plan for this, 48h notice and that on a holiday season sounds absurd and may not even be enough for "just changing a config and testing the system through". It's mean and you shouldn't feel too bad.

It’s a valuable lesson for others who don’t have and test their backup plans

I have no idea why people are downvoting you, because you're absolutely right.

Tens years ago I implemented a payment service for the ecommerce site I worked for. Our main fear wasn't that a payment provider would cancel our contract with 48 hours notice, but it was certainly something that concerned us. Our main goal was to work around instabilities as the PSPs at the time. They where nowhere near as stable as we would have liked. We also wanted to be able to add or move between PSPs in the future, to get better deals.

At any given time we had active contracts with at least two PSPs providing credit card clearing, as well as a few with "buy now, pay later" options and a few payment options for various local markets.

The service/gateway I build would take a order and return a list of payment options that would be valid. Valid meaning available in that country, valid in terms of total amount, insurance and so on. The customer could then pick whatever payment option they preferred.

We where able to turn on or off payment options with a checkbox. So if/when a PSP went down, we could just switch to our backup PSP. Sure the cost would be a bit higher, but that's preferable to losing the order.

Pushing $10M+ though just Stripe, and betting that they will never be down, never fail, and never decide that you violated some rule is nuts. I'm not even faulting Stripe, because other providers WILL do the same.

This feels like more like a Reddit post than an HN one to me - light on the details with plenty Russell Conjugation [1]. I know Stripe has had it's support lapses but I highly doubt they'd just suddenly suspend an account doing $10 million per month without any prior engagement.

In fact, lower down the thread we can in fact see the OP mentions that rather than processing since 2018 "without issues" as they claim in their post they had their reserve requirements increased a few months ago by Stripe to 50% of revenue held for 90 days!

This is a very substantial reserve requirement and presumably there was a conversation between Stripe and the OP's company at the time about the fraud or risk profile that lead Stripe to impose these increased reserve requirements. Presumably whatever prompted the increase in reserve has got worse and caused Stripe to decide the business relationship is no longer worth it.

On the other hand - just 48 hours to leave doesn't seem like fair play. So either 1. the OP is misrepresenting the communications they've had with Stripe over the past few months (including how abrupt the shut down notice from Stripe actually is), or 2. Stripe really will make snap algorithmic decisions over the future of businesses without remorse...

Maybe there's a way for Stripe to show which it is without breaking any of their privacy considerations.

[1] https://www.edge.org/response-detail/27181

or 3) OP is misrepresenting their business (they're a payment provider themselves, not a merchant), and is staying deliberately vague because they're never told their customers they were actually relying on Stripe.

From OP's website (pomelo pay):

> By partnering with international banks in 2018 we engineered a simple and effective method for their merchants to receive payments using secure QR code technology.

> In 2020 the world has changed and social distancing has become the norm. From city-based side-hustlers to local sole traders there is a need for flexible, safe and adaptable finance tools that are reassuring, not rigid.

> We truly believe that our toolkits, that include low-cost payment features, simple e-commerce platforms and innovative QR code solutions, will help businesses get back on their feet without costing the earth.

Could they be using Stripe Connect for this?

https://stripe.com/connect

would definitely make sense... shame OP disappeared, I'd be interested in knowing what exactly they were doing. and TBH i'm not sure why they needed to hide what they were doing, it seems a legitimate use of Stripe Connect? Although a bit cheeky not to mention it in any way on their own website

> On the other hand - just 48 hours to leave doesn't seem like fair play.

We can't say that as a general statement. You can't suddenly start using your account to process, say, ransomware payments and expect a month grace period since it's Christmas and you need to update all your infected clients.

I'm not saying that this is what OP did and it seems likely to me that 48 hours is an uncalled-for short notice period, but there definitely are circumstances where this would be fair.

Good point. I just presumed there was a general pattern at play - I guess because the OP's statement didn't mention any specifics that imply a sudden change in what they process. But yes, for certain types of a fraud it's entirely reasonable that Stripe have an immediate blocking function of sorts.

I worked at a payment processor and I overlapped with the risk department many times there. If one of our merchants were going against the card-brand guidelines or engaging in illegal activity we would have cut them off the same day. The processors are the ones carrying the risk, and could lost their whole portfolio if they are found to not be diligent with the activity of their accounts.

That sucks. What reason did they give you? Something vague like "you broke the terms of service" or something more specific? What could customer support tell you?

I read you're in the hospitality business, did a whole bunch of people cancel/chargeback because of the omicron covid wave, maybe? Just trying to see if there's any reason Stripe may have picked this moment to kill your contract with them rather than any other.

From a business perspective I can see why the timing sucks but this week is just another week, especially with Christmas and NY falling in the weekend. Companies generally try not to pull these stunts around (American) holidays, but there's nothing more special about this week than there is about next week or the week before. You can't expect Stripe to turn off their fraud department for two weeks because it makes the flagged companies sad.

There are other options such as stopping payouts completely and holding 100% in reserve, not shutting down completely within 48 hours.

Based on your existing troubles with them, they've probably already got your account flagged as "problematic" in some way.

If I were to design an anti fraud system, I'd make sure that the more problems I have with an account, the swifter I can react to changes. The payment processor may be more liable to cover damages if they already had a hunch that the company they were dealing with was bad when fraud took place.

Sounds to me like they just wanted you out and found a reason to get rid of you.

The real reason is probably because OP’s company “pomelopay” are advertising themselves as a payment provider, apparently leveraging Stripe (as some form of bootstrap hack?). I imagine Strioe don’t like that?

don't switch to Paddle. they shut you down immediately, without 48 hours notice, and without reason at all. and if their GitHub issue system is full of angry customers, they just delete all GitHub issues and comments, instead of improving their service/product.

thats why we switched to Stripe, believing they wouldn't shut you down without reason.

It's as if payments are ripe for disruption... /s.

Its all solved by cryptocurrency but just need another decade for adoption as a functional day to day currency!

Is this sarcasm?

No. Despite their current use as speculation objects or pyramid schemes, they were originally designed to be exactly that, a digital hard-cash replacement. Unfortunately, their use as the former makes the use as the latter currently very unattractive.

It's not a cash alternative with the kind of paper trail blockchain creates.

Just saying. The perks of cash don't stop at what everyone considers virtuous or convenient to those looking to control economic activity from the top down.

My commet was about the "it's all solved" part of the comment. Would you really consider payments are solved with crypto?

Last week I tried to buy RunJS (http://runjs.app), which uses Paddle. It wouldn't take my business credit card, so I emailed the creator. He said it's a Paddle problem and gave me Paddle's email.

I sent Paddle an email explaining what I was trying to buy, with a screenshot of the payment modal and error message, and their reply was an email bot that said:

> I wasn't able to tell exactly which transaction you're referring to, but it looks like your email **** is linked to a purchase of Unlimited icons pack from Icon54 on *** ** 2017 for USD 0 (order number ######).

> If you need further assistance with this purchase, you can follow this link to chat with me, Kino. I'm a virtual assistant, available 24/7 to help you with this matter.

I emailed this reply to the creator of RunJS and asked him to follow up with Paddle to help me buy his software.

His response was:

> I'd recommend following the instructions that Paddle provided.

> I'm, unfortunately, not able to assist with payment issues.

So my takeaway is yes: payments are broken, especially with Paddle. Payments would be less broken if anybody along the chain cared enough about support to solve payment problems.

Ding ding ding. Welcome to the tyranny of economies of scale. The profit taking happens only a little at a time, spread over millions of transactions. Given you're getting it right more often than wrong (something your analytics will tell you) and your merchants can't be arsed to leave, ignoring problems is absolutely an effective tactic.

Also welcome to why I've been trying to get away from finance and failing miserably. The human cost quantification is far too high for my tastes in my reckoning of hours of suffering induced.

There's some profound revelation on the nature of the great farce that "you can do anything, as long as the money holds out", but this is likely so tautologically obvious it makes very unstimulating discussion.

Agreed, I had to use paddle once for a subscription and the experience was absolutely horrific.

Events are delayed, no customer support, sucky sdk.

Don't touch them with a 10 foot pole.

…or a paddle? /s

I work at Stripe—I’m sorry for the trouble. Could you email me at edwin@stripe.com and we can dig into this?

So what reason did they give for not wanting to do business with you any more?

We're in delayed fulfilment hence some additional risk (quite some time between selling the service and delivering the service) so I get it

1. They already hold 50% (!!!) of all our revenue in reserve for 90 days for the last months (currently a couple of MILLION USD)

2. We are already in the process of moving away from Stripe but they have until now never pulled something so low. The reserves are already massively hurting us, hence moving to an actual acquiring bank but now giving us 2 days in between Christmas and NY is just insane.

So was the answer “stripe think we’re committing fraud by charging for and not delivering goods because of this delay” or something else?

Nope, we're in travel and hospitality (so people book early and stay later) and they don't want to bear the refund risk with Covid-19.

Again, I'm not forcing Stripe to do business with us (even though we never had issues in 4 years and processed millions through them). I just want them to give us a bit more time than 48 hours to switch to another processor in between Christmas and NY.

I don't get it. Are you charging people before their stay? In most of my experiences with Booking.com or hotels themselves, I settle the bill (with my card) at the end of the stay.

Many hotel booking sites do charge at the time of booking, particularly when the booking is heavily discounted / non-refundable.

Depends. Many sites offer non-refundable reservations for a cheaper rate. You pay when you book.

booking.com always charges me before I fly. Same with agoda and another site I’ve used which name eludes me.

Never had the option to pay at the hotel upon arrival.

If you are using a Debit Card, the amount will be held. It looks like it’s charged (and maybe your bank doesn’t show that) but there is a difference from the seller side.

I don't believe that's true. Using a Credit Card funds can still be held and either released or taken at a later date. This usually happens with you rent a car and they need a security deposit.

What I don't understand tho is /why/ a merchant will often accept a credit card but not a debit credit card. While there's differences in fruad protection and refunding, the main difference is debit credit card draws on funds you have while credit card supplies a line of credit to re-pay at a later date.

the absolute best fares i got were always paying in full before the actual trip. i still do this today with covid.

A lot of trips and stays are prepaid in exchange for a lower price.

Lots of hospitality businesses charge before the stay, like travel agencies. A company may need to reserve flights, book rooms and possibly set up tours and events, and all that stuff costs money upfront. If you don't have a lot of buffer (say, because Stripe is reserving half your funds) then you'll need to cover the costs in some other way.

If you only book a hotel then you'll probably get the option to pay upfront or settle afterwards, but if you buy an entire package deal from a third party comaonty then you usually get asked for some or all money upfront. These packages are often more expensive than going through the effort of finding a good deal yourself, or they're cheaper and rely on a lot of deals not falling through.

I wouldn't trust my customers to show up without at least a reservation on their account, especially now with new covid waves and potential anti covid measures threatening holiday fun.

Booking.com, expedia etc. have options to pay in advance. They'll refund you later if you cancel. Some listings seem to have this as the only option? I didn't look recently.

I don’t get it. You’re a payment provider that is in fact just a wrapper around another payment provider?

You didn’t actually answer op’s question. What reason did they give you? What part of the TOS did they say you are violating?

> They already hold 50% (!!!) of all our revenue in reserve for 90 days for the last months (currently a couple of MILLION USD)

So, over the last 90 days you've had $4M of revenue, or $1.3M per month. That's rather a lot less than 5-10M.

Email me at alex@staqq.co

I work in this space and I’m sure we can at least get you up on something temporary while we sort this out.

Damn! Stripe seems to be really dropping the ball recently.

You’ve come to the right place!

This is where the Stripe CEO will reply to you when all their support processes have failed, and you have no other course to save your business. That’s the way all $122billion companies operate.

If he hasn’t been here yet, stay on hold he’ll be here soon.

Patrick? Catastrophic customer support fail call for you….

(Call waiting music….) Oh dear he’s on Christmas holidays. I’m pretty sure their automated processes suspended your account for good reason. If you feel this is not correct, email your case for why you should be allowed by us to have a working business to noreply@stripe.com

I love that comment. This is how support is handled these days.

If you want to know whether a famous Windows audio app works on Surface X (ARM), just ask them on Twitter because the web site sucks and mails aren't replied. If you have an issue with your groceries, just call them out on Twitter because in the store they don't care. For big tech, use HN. Fine.

I personally don't see this as entirely a negative. If I have an issue usually I can just dm a company on twitter and I don't have to call anyone, deal with phone trees, or be there actively waiting for a response. I know this doesn't work well for folks that don't use twitter and it's definitely not a replacement for proper customer service. I do think it's a good addition to proper customer support, though.

> I personally don't see this as entirely a negative. If I have an issue usually I can just dm a company on twitter and I don't have to call anyone, deal with phone trees, or be there actively waiting for a response. I know this doesn't work well for folks that don't use twitter and it's definitely not a replacement for proper customer service. I do think it's a good addition to proper customer support, though.

Pivoting the angle on your perspective a bit:

"If a customer having a problem with our service isn't technical enough to backchannel us, they're not technical enough to be a viral thorn in our side."

To be clear, this is a process defect, and no company should aspire to build this into their processes as a feature. It's a net negative for absolutely everyone except perhaps you, me, and in the short term, the company. I'd argue it's a long term negative for you and me too as we hawk a service to others based on our current experiences, keeping the product from improving for everyone, including ourselves.

It could definitely (and is already) be a negative for some people. My hope is that support can become better and more async. By becoming async it becomes less "I get whoever I get when they answer the phone" and more "I get the support I actually need instead of being bounced around". I don't enjoy having to harass a company on twitter, I just hate it less than getting on the phone.

A good example of this is apple card support. You just text the support line. It's great because I don't need to wait on the phone. If someone doesn't have the info I need they can pass it on without me needing to know about it. I can continue my day without making a chore out of something. This is the part I was trying to highlight (not the reduced access to support).

i agree with you that async support is great, but chatbots and email have been there for a while. What is infuriating with Twitter is that it's basically one rule for the "powerful" (those who are on twitter and have followers/subscribers/whatever) and one for the others

I think the downvotes are because the comment you replied to stated

> This is how support is handled these days.

... with an implied all other things are dropped/neglected and you replied with

> I personally don't see this as entirely a negative.

I fully agree with your point that companies being available on social media, but your first comment can be read as supporting that other avenues are dropped and that's clearly a negative. The grandparent clearly replied to that reading of your comment.

Yeah, I just meant to say that as a user of twitter it's nice to be able to find most companies and message them in one central place instead of dealing with phones, chatbots, etc. I'm definitely not advocating for removing phone or email support.

While I am not a fan of Amazon for other reasons, their chat support has been always outstanding for me.

refunds are sublime

Really? The last several times I've tried to contact support I have only been able to "chat" with some limited functionality chatbot that was clearly narrowly programmed for a few use cases.

No option to reach a human by phone, chat, email. It felt pretty awful.

Edit: I should clarify that I mean Amazon retail. I don't use AWS, but I imagine it has much better support.

I've never had an issue getting in touch with a human on Amazon. On the contact us page there's even an option for them to call you. Enter your phone number and they usually call in under a minute. This option is available in the UK at least.

Maybe that's a UK regulation? I just tried navigating the maze of a customer service site from the US again and can't find any apparent way to contact a human.

Edit: I should clarify that I mean Amazon retail. I don't use AWS, but I imagine it has much better support.

I am from Canada and always had good experience with retail support.

Just ask in chat for a human after reaching a dead end.

I have to agree. At a place I do work at I've contacted AWS support twice using their email support ticket system. Both times were quite pleasant.

Where pleasant in this case is the person replying took the time to read the words you wrote and confirmed that by prefacing most sentences with "so I see you're trying to do xyz", followed by a thorough and well thought out response with references and suggestions.

So many times I've emailed other places (multi-million dollar companies) where it's painfully clear the person replying didn't read anything and some tool scanned my email for keywords which they auto-replied with even though the response makes no sense based on what I wrote. Then it takes additional days and back and forths to get to the point where they understand the original email that was written, in which case it gets "escalated" to another support team / tier within the organization where the process starts again.

> This is how support is handled these days.

These days? When was this not a standard practice for the financial industry?

Most of the time when a bank (or similar) decides to close your account they literally can’t even discuss the reasons with you without putting themselves in jeopardy.

It's anti money laundering regulation, and yes under no circumstances are you allowed to tip off the client that he's being investigated. You are literally obligated to lie if they ask and say there's an undetermined hold-up or something like that. If you don't you become criminally liable, even if the customer is found to not have broken any laws.

Work for a hedge fund under both US and UK regulatory authority.

In practice this also makes it rather challenging to discuss non-AML issues with clients, because if you’re always willing to discuss non-AML issues it quickly becomes clear which issues are AML issues.

Did anyone notice if Paypal CEO is also hanging here?

That would be nice to know, our non profit organization is struggling to get a Braintree account enabled and their customer support just doesn't answer us.

We used Braintree and during the time they were bought out by PayPal and all th terrible PayPal support was integrated. We could never reach a live person at Braintree again and ended up switching processors.

It's scary to think a processor can't answer a phone call but hold your entire business' money in their hands.

For what it's worth, we recently tried to get a new Braintree account set up (this summer) and ended up in the same situation. After a few months of trying to get in touch with them, a coworker of mine was told that Braintree is being integrated into PayPal and is no longer accepting new customers. We ultimately had no other choice than to switch payment processors.

Thanks for the information. Looks like we will need to look at another payment processor and adapts our code to it...

Last time Patrick was on HN customer support duty:

https://news.ycombinator.com/item?id=28522784

Yeah and it worked last time. As a Stripe customer myself with way less revenue than OP, I worry about this a lot. How can any sane company terminate any client with revenue (any size) without having been in contact to sort issues before hand or if not possible, to terminate them with a grace period?

This is insanity.

You don't know what the OP has left out of their post. I am pretty sure Stripe didn't terminate a major customer like that overnight because some admin or bot got bored.

Correct, but they stated they're in delayed fulfillment within the travel vertical.

Google often does that to Google play developers so I don’t see why stripe can’t?

The Stripe CEO was on HN before stripe was even a thing. This comment is disgusting on so many levels. In other companies the CEO wouldn't even give you the time of day whereas with Stripe if something goes wrong in their processes, which given the size of that company is by now inevitable there is at least one way in which you can try to correct this.

Obviously, it would be great if nothing ever went wrong. It would be better still if Stripe had a couple of thousand people manning the phones over Christmas. But automation can and does fail and I figure that by now anybody that decides to farm out a critical portion of their business to a large company is able to figure out for themselves that such a dependency has risks as well as benefits.

It still sucks for the OP, but your characterization, using a novelty account at that, is below the belt, especially on a one-sided story that appears to have plenty left out.

Why is the comment so unfair though? It's true that for many companies, customer support is a joke in poor taste compared to the profits brought in by said customers. And "appeal through HN" often seems like the only solution that will get you unstuck.

I think this event, and many others (and Stripe is very far from being the worse of the lot - looking at you Apple & Google) shows that these companies simply do not value their customers' peace of mind and are perfectly happy to send automated notices and perform automated takedowns without a (relevantly informed & powerful enough to act) human in the loop, and without the possibility of a meaningful appeal (that gives actual reasons and not "you have violated policies").

Automation can fail, but this begs the question of why this is automated in the first place, given the consequences. This is also not a business bringing in 100$ per month (though I will argue they also deserve respect, but I understand if they're not giving quite the same care as business bringing in hundreds of thousands or millions).

> I figure that by now anybody that decides to farm out a critical portion of their business to a large company is able to figure out for themselves that such a dependency has risks as well as benefits.

This is a disingenuous argument in general. If cars were much more unsafe than they are, would you also blame car crash victim for driving a car knowing what the risks are?

We can certainly blame a person for using an unsafe mode of transport. Is that up for debate?

My point is mostly that it shouldn't be used to argue against increased security for that mode of transportation.

The pattern is as follows:

- A: I had a really bad accident, we should make these vehicles more secure. - B: No, you had to be aware that it was risky.

- A: Stripe jeopardized our business, they really should have better customer support for these cases. - B: No, you had to be aware it was risky to use them.

It's a non-sequitur: the plight for increased security/customer support is in no way hampered by the fact that the buyer had to be aware of the risk (which I guess he had, but ... so what?).

> This comment is disgusting on so many levels.

“Disgusting” is a hilariously strong word to use against someone trying to hold a 100B+ company to a little heat and get attention to their cause.

“Assume positive intent” is a facade for “don’t assume negative intent” - but that doesn’t mean we should dip into the good-will bucket for every company spokesperson here.

No, but for the Collison brothers I'll be happy to make an exception, I have yet to see any interaction between them and others where they did not go out of their way to make things right and they come across as super nice, both before and after their success.

If you want to go after the CEOs of other 100B+ companies be my guest, they usually are jerks. But in this very specific case that is not so.

Then make it for HN comments and posters.

https://news.ycombinator.com/newsguidelines.html

HN isn’t a place for this sort of rhetoric. From the guidelines: Don't be snarky.

https://news.ycombinator.com/newsguidelines.html

Do you not get to negotiate different terms after X revenue and Y years of customership? The fact that they can end the contract on their side with only a 48h notification period is honestly baffling. I'd expect better terms.

Not very helpful right now, but when your short term issue is resolved you should look into integrating with a payment orchestration layer so that you could easily switch payment processors without having to reintegrate.

Can you provide a few examples of the most common such offerings?

For ruby there is a nice library from Shopify offering a huge number of payment gateway integrations: https://github.com/activemerchant/active_merchant

Not affiliated with them, but Spreedly is an example of a company in this space.

I feel for you. I had issues with Stripe, and it's one of the reasons I started building dapps on ETH. People read these stories and still think there's no usecase for a decentralized financial system.

As somebody doing web development for a small business (run by my wife) selling courses online and using Stripe for payment processing, I am a bit concerned by this and other similar posts. So far Stripe has always run smoothly for us (FWIW, we never had a single dispute), but I'd like to have an exit strategy. What other other payment processors similar to Stripe you would suggest? So far I basically only care about credit cards (not other payment methods).

A question on credit card fraud. Almost all the payments I make online require some form of 2FA from the bank. Doesn’t that cut fraud to zero?

You said ”almost all”.

Not necessarily - payment processors are still concerned about delayed fraud claims. Not all "fraud" is "it wasn't the cardpayer who authorized this transaction". The risk team is also thinking about the likelihood of chargebacks - certain industries or sectors see far higher chargeback rates than others, and therefore many processors will refuse to deal with them.

Other areas of heightened risk of fraud could be non-delivery of goods (physical item never arrives, resulting in claim via card issuer), defective goods or not-as-described (merchant is just box shifting crap they've never actually seen, and complaints will arrive), or insolvency of the provider.

There have been cases in travel and hospitality where processors put 6 month cashflow halts on funds, to manage the perceived risk of non-delivery. This can in itself be enough to bankrupt the company relying on the processor! (See https://en.wikipedia.org/wiki/Flyglobespan#Financial_difficu... for an example in the UK affecting an airline, where the card processor placed a halt, but had actually spent or otherwise exappropriated the funds)

I don’t think that is the norm for most people is it?

I only get a 2fa confirmation if it’s some absurd amount of money

Honest question - I am not familiar with the business realities of taking payments, but here goes:

At most companies I’ve worked at, we’ve at least done an exercise in keeping our core business process running or available on a competing cloud / connectivity provider or OS, or on prem and offsite. Is it impractical to try and do this with your payment processor? I.e route every 3rd customer to PayPal instead of stripe? Legislative / contractual reasons prohibit this perhaps?

Absolutely not blaming the OP here for their situation, a business has made promises of an easy life for payment processing, they’ve (presumably) been paid by the client but are now causing trouble - this is clearly crappy. But it is not exactly uncommon sadly.

Edit: Further reading of the comments here do seem to make out that this case in particular might not be as clear cut as first seen. But my general question still stands.

Having a backup payment processor is fairly standard for legitimate businesses.

Need more context.

Have you contacted the support team yet? Escalation likely requires an open ticket.

Hope you get help, but I know which provider I won't be using in the future.

General question: when switching payment processors, is there some way of taking all those pre-authorized card details with you? Or is the only way to re-prompt all customers for their card details again?

No, this is called merchant tokenisation (the token only works with that specific processor and that merchant) so you generally can't transfer over pre-auths unless you actually hold the auth code and card details yourself.

Sure you can. Stripe explicitly support this:

https://stripe.com/docs/security/data-migrations/exports

However, the card details don't go to you. They'll transfer the card details to another PCI compliant payment processor.

Thanks for linking this, will come in handy.

I feel for you. But why run skeleton crew for one of the highest revenue periods in hospitality? Makes you vulnerable at the worst time and sorta kinda a little arrogant.

Plenty of companies right now are trying to give their workers a break to prevent burnout, keep talent, etc. Not to mention a lot of folks request this time off for the holidays anyway. Losing your payment processor in 48 hours would just be as substantial of an issue even if they had an entire crew anyways.

This is simply the nature of the hospitality industry. If you get burned out working holidays then hospitality is not for you. It’s a blunt fact of the business case.

Did they give you a reason that they are pulling the plug? Was it because your fraud numbers are too high or something? This same thing happened to a startup I confounded on a Friday afternoon with Chase Payment Services (Paymentech). It was because our fraud numbers had breached 1% which was their line in the sand fraud limit. We switched to Braintree in a few hours, we already had that code built as a backup.

TBH 1% fraud seems like a lot.

I don't know the reasons for this, Stripe is also not so used in Italy, btw I think you should never, ever, rely on a single PSP, they have too much power. More than two years ago we had to add electronic payment to the proprietary B2B ecommerce I was working on, first thing was to design an architecture as indipendent as possibile from a specific PSP.

I’ll get to straight to the point: You’re screwed. Also this kind of post style where you air out dirty laundry (if the story is even true) is unlikely to inspire anyone at Stripe to help you. I know some people that work there through my LinkedIn.

Everything about this sounds Phishy to me. Unless You are We-Travel there is something wrong with your supposed numbers and I doubt a company that is listed as a premier flagship customer of stripe would be getting the boot before they took down their promotional material regarding We=Travel.

Are You sure your not just dreaming/sleep walking right now?

Just to put things in a bit more perspective You claim that You gross between 60 and 100 million per year in sales. Anyone can do a google search of the top global travel companies based on sales and unless You are in the top 100 those numbers don't jive. Any top 100 in the world company would have their lawyers all over this, even over the Christmas to New years dearth.

Is this common at all with other PSPs?

What line of work is your business in by the way?

The only time I've seen a PSP give a time frame this short is because we accidentally provoked VISA. We had some VERY cheap products, like $2, and an insanely easy checkout. Some one in the UK created a bot to buy these products to verify stolen credit cards.

VISA found out before we did, and basically told us to shut it down or lose the ability to accept VISA cards. All this was communicated via the PSP.

So, unicorns in 2022 seem to do support by Hacker News pledge.

Good luck resolving this.

Will this type of thing still happen when/if we all are using crypto payments?

I know that bringing up crypto creates a strong positive/negative "with us or against us" reaction. But it would be great if we could discuss this question on a technical level this time! It is a real question: Will using Bitcoin and the lightning network (or similar technologies) free us from the constant fear that a human or algorithmic error kills our business?

Will there be a service in between you and that network? If so, yes.

Someone correct me if I am wrong, but I think it is pretty easy to run a lightning node. And then no service is between you and the network.

Doubt it, because if you wanted to buy a $2 candy bar with Bitcoin in April, it would have cost you over $50 to do so. Stripe charges a rate of 2.9% + $0.30 by default. Everyone but money launderers would choose to use any other payment method than Bitcoin.

Layer two solutions like the lightning network make payments almost free. Much cheaper than using Stripe.

They also remove almost all the supposed decentralization and trustless model benefits of bitcoin

How so? I have not much knowledge about it, but my expectation is that when you run your own lightning node, there is no reduction in decentralization and trustlessness.

And I would expect that running your own node is as easy as setting up a cheap $10/month VM, download the software, start it, wait some hours until it is synced and then you are good to go?

If there is a service (API) between you and that network, yes.

I mean. You can still use cash. Crypto is similarly an "apples to California" comparison. My extremely limited understanding of payment processor issues and values to companies, is that it's technical aspects a little bit, and legal and process and regulation requirements and fraud detection most of all -- in other words, things which are explicitly "out of scope" or actively rejected by most crypto stacks today.

Could it be an area crypto addresses in future? Sure why not. Without becoming basically the same thing? Doubtful.

(In service of interesting conversation, I'm excluding all other current deal breakers such as transaction cost, time, volatility, complexity etc and assuming a "but coin but works / practical" magical Crypto of future :)

What do you mean with "legal and process and regulation"?

Regarding "fraud detection" - isn't that a self made problem of payment processors? When the settlement is instant, the merchant does not need to be afraid of fraud. Bitcoin paid via the lightning network is paid and can not be taken back.

>When the settlement is instant, the merchant does not need to be afraid of fraud.

There is no instant settlement between entities at different institutions. If you are in the same bank, you can pull it off because the money never leaves your books. If it does leave your books, you're riding the overnight ACH, and incurring propagation delays as the receiving bank filters the funds through process.

Remember, all networks are glorified, process driven, protocol mediated implementations of humans playing a repetitive game of telephone. The chain ain't done til everybody is done metaphorically talking.

>Regarding "fraud detection"

Let me reframe your question in a more familiar context. Fraud becomes software exploitation over an internetwork of trusted hosts. In theory, if no one was a dick... there should be no problems.

>Bitcoin paid via the lightning network is paid and can not be taken back.

This is an anti-feature in the the financial service space. In fact, a really conservative institution won't even consider a transaction truly settled til the dispute window lapses. Mistakes are made, accounts compromised. Lack of reversals or process to accommodate the work stream does not paint you in a flattering light.

all big tech companies get away with shit customer service because we take it in the ass

Why not leave them indefinitely? They get to slack on this and send everyone on to a switchboard because we keep using them

Mondido CEO is hanging around here! ;)

That’s low

Whoa. Does Authorize.net ever do anything like this? This gives me heebie-jeebies…

No, they are not well organized enoug!

> I know a lof of of Stripe are reading here including pc

Why don't you directly reach out to them, instead of posting to HN?

We have, and their support needs more time to answer our email or chat queries than they've given us notice. So I guess they do observe holiday support times, just not for their customers.

I thought posting to Hacker News was the best way to contact Stripe? ;)

There's a joke about the CEO in another comment, but HN should actually be an appropriate place to reach Stripe employees who might care about making the company look good; after failure with official customer support, it's the best communication channel I could think of.

It shouldn't. We're on hackernews. This is not news. Nor is it about tinkering. It's literally just a "help me, I'm getting taken in the behind by $bigco" post.

I don't want to see this place turn into a tech support forum, and no I don't care how much money is involved.

The standard operating procedure for turning this kind of problem into news is writing about it indignantly on one's blog, on Twitter, etc. and then linking to the newsworthy episode of shameful corporate insensitivity inspiring public outrage.

But this time it isn't mere indignation, the OP is desperate. How much money is involved matters.

Reply on news.ycombinator.com