Spreedly vs Primer vs Gr4vy: Vault, Workflows and Reporting

The choice between Spreedly, Primer and Gr4vy starts with a practical question: which part of your payment operation needs to become independent of one processor? A vault, a routing workflow and a settlement report solve different problems. Buying a second processor connection does not by itself move stored credentials, make failover safe or reconcile bank credits.

Their public documentation describes all three as broader than a single-feature product. Treat the table below as a map of documented starting points, not a verdict that a capability exists only in one platform.

Credential control: a token is only the first step

Spreedly says it stores the payment method and can use its token at more than one gateway or endpoint. That is a concrete alternative to saving every card only inside a single PSP. It does not mean every destination accepts the same credential format, that a network token is freely exportable, or that a migration has no PCI and contractual work.

Primer documents network tokens linked to vaulted Primer tokens for eligible transactions. Gr4vy describes importing and exporting card data. These are different claims from “every token is portable to every processor.” Ask all three to demonstrate import, repeat payment, export and a controlled exit using the actual processors you plan to use. Record who can initiate an export and what happens to subscriptions during the change.

Workflow control: make failure behaviour observable

Primer's workflow guide gives a useful operational warning: a payment-status trigger needs explicit conditions, or a capture action may run on the wrong status change. Its run history can help diagnose a failed third-party action. Gr4vy also describes no-code routing and A/B tests. A “visual” versus “engineering-led” label does not settle which platform your payments team can safely operate.

Before choosing, put one real route through each candidate: the normal authorisation, a processor timeout, a decline that must not be retried, and a refund after a successful payment. Ask who can publish a rule, how it is tested and rolled back, whether retries use idempotency controls, and which identifier follows the payment across providers. These are PaymentBrief evaluation steps, not a claim that one vendor implements every step by default.

Reporting: compare what the records can actually join

A unified dashboard can help investigate a payment, but a processor's settlement file or bank credit may still be needed to close the cash ledger. Gr4vy describes settlement reports; Primer describes workflow runs and payment events. Neither statement alone proves that a particular merchant can reconcile fees, FX, disputes and net deposits from one export.

Ask for sample output for a successful capture, partial refund, failed attempt and payout. Check the payment ID, processor reference, transaction currency, fee, payout identifier and adjustment type. If a field is missing, establish which provider or bank file owns it. The statement-reading reference explains the separate fee and settlement layers.

Price the full change

No common public rate card was established across the three providers in the documents reviewed for this update. A quote should specify platform and usage fees, vault and token services, custom connectors, migration, support and the PSP/acquirer charges that remain payable outside orchestration. A claimed approval uplift is a hypothesis to test on your traffic, not a number to insert into the business case.

If the problem is a second acquirer rather than a full orchestration layer, start with the multi-acquirer routing guide. If it is credential ownership, read the vendor lock-in reference. Choose the candidate that proves your required route, exit path and reconciliation records under your contract.