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

[thiscatis]

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.

[trollied]

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.

[thiscatis]

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.

[trollied]

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.

[elidourado]

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

[namdnay]

The plot thickens..

[g_p]

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?

[Joe8Bit]

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.

[btown]

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!

[mrweasel]

> 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.

[znpy]

> 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.

[tzs]

> 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.

[iso1631]

> 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.

[midasuni]

> 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.

[zx76]

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

[namdnay]

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.

[Sebb767]

> 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.

[jeroenhd]

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.

[namdnay]

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?

[thiscatis]

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

[dinkblam]

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.

[newsbinator]

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.

[greatjack613]

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.

[chinathrow]

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

[edwinwee]

I work at Stripe—I’m sorry for the trouble. Could you email me at [email protected] and we can dig into this?

[jimjams]

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

[thiscatis]

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.

[atdrummond]

Email me at [email protected]

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

[ayoubElk]

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

[starklevnertz]

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 [email protected]

[m_st]

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.

[jacquesm]

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.

[starklevnertz]

Last time Patrick was on HN customer support duty:

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

[zerr]

Did anyone notice if Paypal CEO is also hanging here?

[DenisM]

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

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

[emerongi]

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.

[globalise83]

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.

[mahesh_rm]

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

[djohnston]

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.

[giomasce]

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).

[cm2187]

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?

[g_p]

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)

[jordansmith]

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

[eurasiantiger]

You said ”almost all”.

[alibarber]

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.

[jacquesm]

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

[DantesKite]

Need more context.

[popinman322]

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

[locallost]

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