Hacker News Reader

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.

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)

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.

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

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