Help HN: Stripe shutting us down with 48 hours notice on a holiday skeleton crew
Thinking aloud here, it does seem like (as we've always known), anyone doing eCommerce online is effectively beholden to their payment provider.<p>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?<p>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).<p>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.<p>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.<p>ACME is like this for SSL - there's now multiple CAs implementing the one API. Could we get there for payments too?