Payment orchestration or an independent vault? When I’d pay for the platform

If you run payments for a merchant or own the payments roadmap, you may be weighing a vault against a full orchestration platform. Start with the next thing your team needs to ship. Is it a secure way to send a stored card to an endpoint you’ve already chosen? Is it a way for your team to manage routing, retries, local payment methods or gateway onboarding across providers?

I’d buy a vault with a forwarding proxy for the first job. I’d consider orchestration for the second if I wanted a vendor to build and maintain the connections and give my team controls it could use without an engineering release.

Both approaches can use a processor-agnostic vault. A vault stores the card and gives your application a token in its place. An orchestrator can supply or connect the vault, then add gateway integrations, routing and reporting. With a standalone vault, you decide which of those capabilities to build or buy. There’s also a third approach for an enterprise that wants to own the payments roadmap. Buy the components you need and keep responsibility for what gets built and when.

When is a vault and forwarding proxy enough?

Say you run a travel business and need to send a customer’s stored card to a booking API. Your application knows the destination and builds the request with a vault token in the card field. The proxy replaces the token with the required card data inside its PCI DSS environment and sends the request to the approved endpoint. Your application can make the call without handling the raw card number.

The same pattern can serve supported endpoints at Amadeus or Sabre, a subscription billing API such as Zuora, or a direct integration with a payment service provider (PSP). Check that the destination accepts the card data for that flow and that your vault can forward it there. If that’s the whole job, I’d buy the vault and the proxy. The merchant still owns the request and decides where it goes.

How I’d run two card processors

For a U.S. card business adding a second processor, I’d price an independent vault, payment intelligence and a small routing service before buying a full platform. Once both providers can use the stored cards, I’d give the second processor a defined share of first attempts, perhaps 30%, then compare approval rates and cost on similar traffic. Depending on your card mix, it may make sense to compare results by issuer or card type before moving more traffic. I’d decide up front which failures qualify for a second attempt. If the first processor times out and I can’t tell whether it charged the card, I’d check the transaction before sending it elsewhere. The same setup can work for a higher-risk merchant if both providers accept the business and the traffic.

The next decision is how specific those retry rules need to be. Built-in cascading typically sends eligible failures, such as certain soft declines or gateway outages, to a backup gateway under the platform’s rules. If I’m considering an orchestrator, I want to see which declines I can act on and whether I can change the destination and timing.

I’d keep the original decline code alongside the normalized response used to compare processors. With a retry service I control, I can use that detail and any Merchant Advice Code the PSP passes through. For a specific decline, I might schedule a retry on the same gateway five days later, where the advice and network rules allow it. If the advice says to stop, the retry ends there. I’d keep the logic in my own stack if I needed that much control and the platform couldn’t provide it.

When is payment orchestration worth paying for?

A growing global merchant

If I’m expanding across continents and need to offer local and alternative payment methods alongside cards, I’d start with orchestration. A team might be adding Pix in Brazil while it manages separate gateways and processors for Europe and North America. Each new method brings checkout, payment status, refunds and settlement work. In my experience, once you’re managing more than five to seven gateways, keeping those connections current is a job in itself. I’d give that work to an orchestrator that can show the methods and payment flows I need in each market.

A software platform that lets merchants bring their own gateway

A vertical SaaS company or merchant aggregator can help customers accept payments while each customer stays the merchant of record. In this setup, the software platform is a non-merchant of record. Picture a QuickBooks-style invoicing product. A business sends invoices through the software and connects its existing gateway to collect them. When the platform supports the gateway, its sales team can move straight to onboarding.

These platforms can end up supporting 15 to 30 gateway integrations, sometimes more. Competitors tend to cover the same popular gateways, so the deal that sets one platform apart may hinge on a regional processor the others don’t support. If the orchestrator can commit to building that connector in two weeks, the software platform has a chance to win the merchant’s business without asking it to change processors. That delivery date is part of what I’d buy from the orchestrator.

For a niche gateway already in the catalog, ask when it last handled live traffic and have the vendor demonstrate what the prospect needs, such as partial refunds or settlement reporting. Some connections were built for one customer and may have fallen behind since. For a missing connector, get a price, a date for production and a named owner in Product or Professional Services. Agree who will maintain it once the merchant goes live. I cover the commercial questions in five nontechnical things to check before buying orchestration.

When an enterprise wants to own the roadmap

At roughly $500 million in annual payment volume, I’d look early at independent payment intelligence and a vault. A large merchant may be willing to pay for orchestration and still want to decide which integration ships next. If a change to a processor connection or a new retry rule is important to your business, waiting for the vendor to put it on its product roadmap can cost more than the software fee.

I’d use independent intelligence to compare processors, see what a routing change did and give finance a way to trace a payout back to captures, refunds and fees. Pagos and Optimized Payments are examples. Then I’d decide who implements the changes. One option is to work closely with an orchestrator that will commit to the integrations and features on your roadmap. Another is to buy a vault and have your own payments engineers build the processor connections and routing. In either setup, the merchant decides what comes next.

At the far end, payments can be important enough to justify hiring a team and building the platform in-house. Uber has described building its own payments platform, and Amazon’s Prime Video Commerce team has described its work toward a unified orchestration platform. At that scale, I’d consider owning the vault as well if the business is prepared to operate and secure it. The decision depends on the team and what payments need to do for the business.

I’d make portability part of that decision. If a processor’s economics change or a buyer wants to use its own provider, test whether you can forward or export credentials and move a small share of traffic. A second vault may be worth buying if it serves a purpose such as a tested backup or better account updater coverage for a share of traffic. The token portability guide covers what to test before moving volume.

How much do vaulting and orchestration cost?

I’d usually expect vaulting to be the lower-cost software purchase. Compare the work included in each quote before you compare the fees. These are indicative annual software budgets as of November 2026.

The rate cards are where the comparison gets harder. My usage illustration assumes 2¢ per billable vault operation and 5¢ per billable orchestration operation. At 2.5 million operations counted the same way, that’s $50,000 and $125,000 in usage before other fees. Vendors can count calls, payment attempts and retries differently. Ask each one to quote the same workload and break out minimums and any charges for network tokens, card account updater, other credential services and 3-D Secure (3DS) authentication. Add the cost of implementation and maintenance on your side.

Spreedly, IXOPAY and Primer also offer vaulting separately from their broader orchestration products. You can buy credential storage and forwarding and bring your own integrations and routing. As more orchestration vendors sell vaulting on its own, I expect basic vaulting to become more interchangeable. I’d ask for the vault quote and the full-platform quote side by side.

Why Professional Services matters

When I’m choosing a vault or an orchestrator, I want to meet the people who will work with my payments team. I’d show the vendor’s Professional Services team the merchant’s roadmap and ask which integrations they can take on, in what order, and who will own the work. That might be a payments adviser who can turn a routing requirement into a design, or an integration specialist who can get a regional gateway live and make sure finance can reconcile the payments.

There’s a reason that work can get less attention inside a software vendor. Private equity and growth investors care about recurring software revenue because it can support a higher valuation multiple. A subscription adds to monthly recurring revenue. A fee for building a gateway comes in once. In my view, that gives management a reason to prioritize the subscription even when the project is what gets the customer live.

AI can help an experienced Professional Services team get to the first test faster. Basis Theory’s James Armstead described generating a software development kit for three processors in under six minutes. The team still needs to work through the PSP’s quirks, test payment flows and settlement, and agree on who maintains the connection after launch. I expect some merchants to build more of their stack as that work gets cheaper. Among vault and orchestration vendors, my bet is on the ones that can put those people on the merchant’s roadmap and deliver the integrations when the business needs them.

If you’re comparing proposals, I can help work through the quotes, test the gateway and payment flows you need, and implement the option you choose.

Common questions about payment vaulting and orchestration

Can I use an independent vault with payment orchestration?

Yes, if the orchestrator supports the vault or the credential forwarding path you need. Verify which tokens and payment methods it can use, who owns the integration and how you would move traffic to another provider.

Does a forwarding proxy make a merchant PCI compliant?

A forwarding proxy can keep raw card data out of your application when the flow is designed that way. The merchant still needs to confirm its PCI DSS scope and responsibilities, including how it oversees the service providers handling card data.

Sources and further reading

• Vaulting and managed orchestration. The vendors make different arguments about which capabilities the merchant should buy together. Basis Theory · Primer
• Secure card forwarding. PCI Proxy documents the token-to-card request flow. Spreedly lists approved receivers, including Amadeus, a Sabre-hosted JetBlue endpoint and Zuora. The PCI Security Standards Council explains the merchant’s responsibilities when card handling is outsourced. Forward proxy documentation · Spreedly receiver documentation · PCI SSC on outsourcing
• Public vault prices checked November 5, 2026. PCI Vault lists $255 per month plus 2¢ per API operation. Enigma lists a $249 per month Growth tier with 250,000 requests and 1¢ per additional request. Spreedly lists Independent Vault from $750 per month. The article’s annual budgets and unit-rate comparison are author illustrations. PCI Vault · Enigma · Spreedly
• Gateway setup, versioning and local methods. Spreedly documents gateway-specific features and version changes. Stripe illustrates the libraries available for a widely used provider. The long-tail maintenance observation comes from the author’s experience. Supported gateways · Version changes · Stripe libraries · Pix · Dutch bank payments
• Platforms that onboard merchants. Spreedly describes how platforms can support merchants’ preferred gateways. IXOPAY documents a merchant structure for white-label platforms, and Gr4vy describes how to enable prebuilt payment connections. Spreedly’s platform guide · IXOPAY’s setup guide · Gr4vy’s platform overview
• Data and independent intelligence. Adyen illustrates the response, retry and settlement fields a PSP can expose. Pagos and Optimized Payments document their product scope. Adyen response fields · Adyen settlement details · Pagos Decision Signals · Optimized Payments Harmonize
• Retry rules. Spreedly’s Recover documentation is an example of built-in failover. Adyen documents the retry guidance it can pass through in Mastercard Merchant Advice Codes. Spreedly Recover · Merchant Advice Codes
• Portability and second vaults. Spreedly documents its export and third-party vaulting processes. EMVCo describes how payment-token use can be restricted. Credential exports · Third-party vaulting · EMVCo
• AI and investor incentives. The development kit timing comes from the person who ran the demonstration. Spectrum Equity has described recurring revenue and subscriptions as areas of investment interest. The effect on Professional Services priorities is the author’s view. Spectrum’s Spreedly investment announcement highlights annual recurring revenue growth. James Armstead’s demonstration · Spectrum Equity · Spectrum’s Spreedly investment
• Standalone vault products and add-ons. Spreedly pricing and modules · IXOPAY tokenization and orchestration offerings · Primer Vault
• Enterprise platforms. Uber’s payments platform · Amazon’s Prime Video Commerce Tech roadmap