Quick disclosure up front: I work for IXOPAY (payment orchestration) and we compete in this market. The problem itself affects everyone regardless of vendor, which is why I am writing about it.

If you have ever tried to change payment processors, you have likely run into this issue, i.e. who owns your payment tokens.

What is a payment token?

A payment token is a stand-in for a customer's real card number. Instead of storing the actual PAN, you store a token that maps back to it inside a secure vault. Lets you charge returning customers and run subscriptions without holding raw card data yourself.

You have 2 types that matter:

• Gateway tokens are issued and held by your processor. They only work inside that processor's system.
• Network tokens are issued by the card networks (Visa, Mastercard). They aren't tied to a single processor.

It’s not a big difference, but it becomes one when you try to leave.

Why it is hard to switch payment processors

Gateway tokens stay in the processor's vault. When you switch, you cannot take them with you. You are left with three bad choices: move them at high engineering cost, make customers enter their cards again, or give up on those customer accounts entirely.

That single fact causes most of the pain in switching processors:

• Engineering work. Leaving a processor when you do not own your tokens requires exporting token data, encrypting it again, formatting it for the new system, and testing with live transactions. This takes months of software development.
• Getting your own data back. Exporting your customer tokens often requires a formal request process, including legal paperwork, encrypted file transfers, compliance checks, and extra fees. Even though it is your data, it is stored in someone else's system.
• Extra security compliance during the move. If you migrate, you must run two payment systems at the same time. Security standards require full compliance for both systems, which doubles your work during the transition.

Advantages of owning your own token storage

The alternative is storing tokens in an independent vault that you control, separate from any processor. Two things change:

First, switching processors is as simple as changing a setting (no software overhaul required). You connect your new provider to your existing vault and you’re done.

Second, you can use network tokens with every connected payment provider. These tokens lead to higher approval rates because banks trust them more. They also update automatically when cards renew, so you lose fewer sales to expired cards.

What to ask before you switch

Before you compare processing fees with a new provider, ask where your tokens will be stored. 

If they stay in the processor's vault then it will be hard changing providers later. Even with lower processing fees, you end up paying more down the line to switch.

If you are going to move your tokens once, move them to your own vault.

If you want to own your token vault, payment management platforms usually solve this because their vaults sit above individual processors. IXOPAY is one platform that offers an independent PCI Level 1 vault with network tokens, and there are other options available as well.

I work at IXOPAY, I'm offering that information up front, because this topic's come up a few times with us, so creating a post for the benefit of the public.

if it appears self-promotional, please let me know, I'll take it down

The biggest difference is how transaction notifications work. Spreedly is synchronous. IXOPAY sends an asynchronous callback once a transaction reaches a final state. That changes how you handle post-transaction logic on the backend.

On the frontend, both platforms use a JavaScript library to tokenize card data in the browser. The initialization pattern is similar, but IXOPAY's payment.init() uses a Connector Key rather than an environment key, and tokenization returns a transaction token via success/error callbacks rather than Spreedly's event-based paymentMethod listener.

For the transaction API, IXOPAY's PHP client uses a Debit object with explicit success, cancel, error, and callback URLs. Recurring transactions reference the UUID from the first transaction via setReferenceTransactionId() rather than reusing a stored payment method token.

One thing that simplifies the switch: IXOPAY normalizes processor response data into a single notification format, so you're working with consistent output regardless of which gateway is behind the transaction.

I just asked a question, I seemed to have been doing fine previously, but then suddenly kaboom.

I saw something about contributor quality score, but I don't know how it's calculated or how to move it along.

Help, please.

For me it was become the best at martial arts and Bruce Lee kicking the school bully so hard he'd break through the door and hit the wall on the other side, and then one-by-one beating down all the teachers that tried to defend him.