Tell us if you’ve heard this before.
A merchant goes to review their processing statements.
They, of course, can’t read any of it, so they hire someone who can.
A learned payments professional takes a glance and realizes, holy shit, Shift4 is pumping this merchant for 840 bps of margin.
Honestly it’s a miracle that the merchant is still solvent.
Time to switch processors.
Ignoring the outrageous Shaft4 termination fee, which is, somehow, basically just legalized racketeering at this point, the merchant needs to move over their cards on file.
What are cards on file?
Well, the information on the face of a credit and debit card has been deemed a “security risk”, so it “must” be protected with a bunch of expensive, nonsense compliance… that earn the makers of said arbitrary rules even more money, because we guess there wasn’t enough money just ripping basis points on every transaction as a duopoly.
Imagine that there was only one source of food, and you had to buy utensils every time you ate from… the only manufacturer of said food.
Think those forks are going to be reasonably priced?
If you want history on how this “security” body came to be (it’s called PCI, btw), feel free to read this piece.
So anyway, these cards are tokenized, meaning that the super-sensitive-better-never-let-it-leak-but-let’s-ignore-the-easier-and-more-effective-means-of-ssecurity card numbers are hashed into a string of characters that the gateway generates.
As an example, assume your card number is 4242 4242 4242 4242.
Can’t have that number just floating around.
So the gateway – in this case Shaft4 – turns that card number into a unique token that represents that card, but if someone were to ever access that token they couldn’t easily decrypt it back into the original card number.
Make sense?
Well the only party that can reasonably read that token is Shaft4.
Meaning that if you wanted to move that card on file into your new gateway partner, you can’t.
Not without Shaft4 giving you the original card number, at which point your new gateway partner would convert that card number into its own token.
On a technical level, the hand-off needs (according to arbitrary PCI rules, mind you) to happen directly between Shaft4 and your new gateway in a PCI-secure environment.
Anyone who’s not operating a PCI-secure environment cannot touch the data.
But this is technical.
On a business level, things are different.
When Shaft4 – or really any processor – hears that their merchant is leaving, they throw up blockers.
“Mother f*cker, I worked hard to induce that piece of sh*t merchant, and I want to bleed them out; there’s still blood left Godd*amnit!”
Literally the first – and only – thought that traverses the big brains of the legacy payment bros.
This then goes one of two ways.
First, Shaft4 just entirely refuses to cooperate.
Doesn’t respond to communications.
Tells the merchant it’s impossible to leave.
You know what this looks like. The more desperate the processor, the worse this behavior.
Second, the processor allows the merchant to leave but they make it so economically punitive it’s impossible in reality. Like…
Termination fees that are 20 years of a merchant’s margin (not kidding, here’s Shaft4’s termination fee schedule as proof:
Absurd costs to move the tokens.
How about 6 figures for 1,000 tokens? Sounds fair, right?
It turns out that there are rules for what you can and can’t do in these situations, at least if you participate in card acceptance through the duopolies. Because Visa and Mastercard are absolutely nothing if not fantastic as setting (and capriciously enforcing) arbitrary rules.
To get to the bottom of this, we tapped the inimitable Jason Kafer, who is incredibly well versed on most everything payments.
First, the rules on tokens:
So no, processors/acquirers CANNOT obstruct the migration of tokens.
Hard stop.
If you stick your hand in the payments cookie jar you have to let other people snack, too.
“Sometimes the processors forget the rules they signed up to follow, and you need counsel to send them a letter reminding them,” shares Jason.
But sometimes there are legitimate reasons to pause before token release.
Most of the time the person going to the processor is the merchant, who is not PCI level 1 certified. The merchant shouldn’t be doing this: they should connect the new service provider with their existing processor. The new service provider should draft a PDF of answers to objections that the existing processor might raise, and send this to the merchant to forward on to their existing processor. If you don’t do this, the best case is you have 3-4 weeks of back and forth before anything happens.
Jason wants to be clear that there can be legitimate fees associated with transferring tokens.
There’s no black and white rule against charging for token release. Of course there are reasonable and legitimate costs, but then there’s just greed. You need someone with experience to provide you guidelines sometimes.
Even if you cross this rubicon and get the tokens released for a fair exchange, there are still pitfalls.
“People need to be very clear and specific on what they want, and what they get. Detail out the data you need or you’re likely to receive tokens that are worthless.”
What does that mean?
“Processors will export the minimum amount required to the new party. I’ve often seen tokens come over that are entirely lacking AVS or CVV data, which means you’ll never be able to leverage network tokens or even modern payment tools.”
If you really want to understand the pitfalls in more detail, you need to read Jason’s post on the matter. There are a lot of gotchas with network tokenization, and the large processors in particular can take months to port tokens.
Jason has taken all these learnings and built a solution that resolves these nagging issues.
Here’s the summary.
- Legacy acquirers, who are dying a slow death and desperate to retain merchants, won’t make porting tokens easy.
- But they have to. It’s in the network rules. Worst case you can have counsel author a form letter pointing to the network language (which we’ve posted herein).
- Expect fees for porting tokens. Make sure they’re reasonable fees and not pure avarice. A good SWAG is a few hours of work @ $150/hour, so in the realm of < $1K.
- Be very specific on what data you request. Check it. Then check it again.
- Write a clear list of instructions for your merchant to present to their existing acquirer to avoid slowdowns.
Add comment