.png?width=365&height=122&name=BTLogo%20(1).png)
Running multiple PSPs is smart. Paying for the same features across each of them isn't.
Apply some wholesale shopping logic to your payments stack.
While 97% of global enterprise retailers operate with multiple payment service providers (PSPs), service duplication (meaning you are paying multiple providers for an identical feature) is often a byproduct. With features such as 3D Secure (3DS), Account Updater, and Network Tokens bundled into a contract, merchants often pay for these services multiple times across their integrations.
Be a wholesale shopper instead.
Here’s what going wholesale shopping looks like for Account Updater, 3DS, Network Tokens, and even Bank Identification Number (BIN) Details.
Account Updater
For merchants running subscriptions, memberships, or any model with cards on file, Account Updater is the difference between a payment that clears quietly in the background, and a failed transaction that triggers an email, support ticket, or at worst, a cancellation. The question isn’t whether your PSP offers the service, it’s how they offer it.
At the processor level, a merchant doesn’t control which cards are being updated. Different logic can’t be applied across customer segments. You may not want an account updater running on every card type in your database—but if your PSP is handling it, that decision is not yours to make.
At the vault level, you provision account updater once under your own Token Requestor ID (TRID) and own the relationship directly with the card network. You decide which cards receive updates, what you want changed, and when.
These updates can then be applied to any of your PSPs.
Network Tokens
The authorization rate lift alone makes network tokens worth the conversation.
Visa reports a 4.6% uplift for card-not-present (CNP) transactions and roughly 28% fraud reduction. Mastercard reports approximately 2.1% authorization rate improvement for CNP. These are not marginal gains for a high-volume merchant—they compound at scale.
But here is a question most merchants do not think to ask: who owns the Token Requestor ID?
When your PSP provisions Network Tokens on your behalf, the TRID is theirs, not yours. The tokens live under their umbrella. If you switch processors, add a new one, or want to route a specific transaction differently, you may not be able to bring those tokens with you. The portability you thought you had doesn't exist.
When Network Tokens are provisioned at the vault level, the TRID is registered in your name. You own the tokens. You see exactly when a Network Token is being used in a transaction versus a raw PAN. You can route the same token across any processor in your stack, and you provision it once.
Not once per processor. Once, total.
For merchants running two or three PSPs, the cost math is straightforward: a feature you're currently buying multiple times becomes a single line item. And with wholesale pricing, that single line item costs less than any one of those individual PSP fees.
3DS Authentication
The challenge for multi-processor merchants with 3DS is consistency. When 3DS is managed at the processor level, each PSP handles authentication independently. You have limited visibility into frictionless throughput rates, limited ability to tune which contextual data fields are being sent, and no unified view across your full transaction volume.
At the vault level, 3DS authentication is centralized. You enroll, you gain direct access to your own authentication data—frictionless rates, step-up rates, regional performance—and you can work to tune the parameters that maximize frictionless approvals. The result is higher frictionless approval rates and fewer unnecessary step-up challenges.
BIN data from the vault can inform which transactions even need 3DS to begin with, using issuer preference data to route authentication decisions intelligently. And when a soft decline comes back from an issuer indicating 3DS is required, the vault is already positioned to handle the retry without bouncing the request across multiple systems.
BIN Data
BIN data is the intelligence layer beneath every card transaction.
That data drives fraud prevention, transaction routing, surcharge logic, dynamic risk thresholds, and customer segmentation. It's fundamental.
The problem is consistency. PSPs return BIN data in different formats, with different field names, and with varying levels of completeness. If you're running multiple processors, you don't have one BIN dataset, you have several, and someone on your team is responsible for maintaining the mapping between them. That's engineering time and operational overhead spent on a problem that shouldn't exist.
Basis Theory maintains a single, enriched BIN dataset at the vault level. Regardless of which processor a transaction flows through, the BIN data your team works with is standardized, consistent, and enriched card type, issuer, region, authentication preferences, and more. There's one source of truth, and it's always current.
For merchants using BIN data to power surcharging, regional compliance, or processor routing logic, consolidating this at the vault level removes the mapping problem entirely. You build the logic once, and it works everywhere.
Taking Ownership
The theme running through every one of these features is the same: when they live at the processor level, you get opacity. When they live at the vault level, you get ownership.
Opacity means you don't know exactly what you're paying. It means your Account Updater runs on cards it shouldn't. It means your network tokens belong to someone else. It means your 3DS data is siloed. It means your BIN logic breaks every time you add a new processor.
Ownership means you provision once, pay once, and use everywhere. It means your TRID is yours.
If you're running more than one PSP and haven't audited what you're paying for Account Updater, Network Tokens, and 3DS across each of them, the answer is almost certainly: more than you should be.
Ready to audit what you’re actually paying for? Schedule time with our team and we can walk through your use case to see where consolidation makes sense.
