Gr4vy

Service Overview

Gr4vy is a payment orchestration platform that describes itself as the first cloud-native payment orchestration platform built in the cloud from day one, and adopts a fairly unusual self-positioning: IaaS, Infrastructure as a Service. The implication is that it wants to be procured as infrastructure rather than as a payment provider.

The product consists of five modules. Acceptance handles acquirer connectivity, Checkout provides checkout components, Vault custodies payment credentials, Optimize handles routing and success-rate optimization, and Analytics provides data and reporting. Together they cover the whole path from connectivity to analytics rather than only the routing segment.

Its most quoted capability is the agnostic PSP model. Agnostic means the orchestration layer does not favour any acquirer: the merchant decides which PSP handles which transaction, and can add or remove a PSP at any point without touching the checkout or building a new API.

The official figures are reasonably specific: 1 integration reaches 400+ payment methods, a multi-PSP strategy lifts authorization by 3% or more, up to 14% of failed payment revenue can be recovered, and the platform runs at 99.99% availability. The first two are revenue-side and the last is availability-side, which happen to map onto the two core demands of payment orchestration.

The customer list shows the target segment: Wpay is the payment platform inside Australia's largest retail group, Grammarly and Rakuten Viki are global digital subscriptions, Trek and Baby Bunting are retail, JustGiving and PlayHQ are charity and sports events, Zip is buy-now-pay-later, and Much Better Adventures is travel. The spread is wide and most of them are multi-market, multi-method businesses.

Key Strengths

• PSP statelessness is the sharpest claim: acquirers have an inherent incentive to steer transactions onto their own infrastructure because it affects their cost and margin structure. An orchestration layer exists to put that choice back in the merchant's hands, so routing follows the merchant's interest rather than the PSP's.
• Adding a PSP without touching the front end: the official site states new PSPs and fraud providers can be enabled with no checkout change and no new API. That turns "change provider" from a project into a configuration step, which is exactly what decides whether a multi-PSP strategy ever ships.
• 400+ payment methods through 1 integration: for businesses that need local payment methods per country, that scale means most target markets do not require a from-scratch integration, cutting marginal cost sharply.
• Failed payment recovery is quantifiable revenue: the official figures cite up to 14% of failed payment revenue recoverable and 3%+ authorization lift under multi-PSP. These are the easiest parts of an orchestration layer to validate and the easiest to put into a business case.
• A 99.99% availability commitment: when the payment path goes down the loss is immediate and direct. Committing to 99.99% signals that the product sits at the same level as the payment path rather than being an optional add-on.
• Analytics and Optimize close the data loop: routing decisions need evidence. Analytics provides per-rail and per-method performance while Optimize applies it to live routing, so optimization continues rather than being a one-time setup.

Product Ecosystem

Acceptance

Acceptance brings each acquirer's capability in behind a unified interface. A merchant integrates once, and adding a PSP afterwards is enabled on the Gr4vy side without rebuilding checkout or changing API versions.

Checkout

Checkout provides hostable checkout components and also supports backend-only usage. For businesses with their own front-end design system, componentized embedding preserves the existing look while adding orchestration capability.

Vault

Vault custodies card and payment credentials decoupled from any specific PSP. Credentials live at the orchestration layer, so switching PSP or splitting traffic across several PSPs never forces a customer to re-enter a card. That is the technical precondition for the stateless-PSP model.

Optimize

Optimize routes according to live performance of each rail. It treats authorization rate as an objective function to improve rather than treating rail order as fixed configuration.

Analytics

Analytics provides data and reporting across transactions, rails and payment methods so teams can see which rail underperforms in which market. It feeds Optimize and also grounds any explanation of success-rate movement.

Limitations

• The IaaS framing cuts both ways: it hands you control and hands you operating responsibility. Without a payments engineering team this stack is hard to stand up, particularly when mapping decline codes and tuning routing strategy.
• No acquiring licence: the merchant remains the contracting party with each PSP, negotiating merchant accounts, deposits, underwriting and settlement cycles. An orchestration layer does not resolve whether you can obtain an account at all.
• Opaque pricing: no standard rate card is published and everything is negotiated, so small and mid-size teams struggle to model total cost and to compare orchestrators on a like-for-like basis.
• SaaS-first delivery: institutions with hard requirements around data residency, private deployment or regulatory isolation must confirm support first rather than assume it.
• Not applicable to mainland China: domestic CNY acquiring and local clearing are out of scope, so mainland entities should be excluded.
• Payment method coverage is uneven by region: the 400+ figure is an aggregate, so which methods exist in a given country and which are locally direct must be checked against the current official list.

Use Cases

• Multi-PSP and traffic splitting by market (★★★★★): businesses already contracted with 2+ PSPs that need to split by country or method and reconcile centrally; the agnostic model and 400+ methods map onto that requirement directly.
• Global subscriptions and SaaS (★★★★☆): multi-market subscription businesses like Grammarly and Rakuten Viki keep credentials at the orchestration layer, so rail changes do not break renewals and success-rate gains land on MRR.
• Categories with high payment failure (★★★★☆): for teams sensitive to a 14% failed-payment recovery figure, the return on an orchestration layer is easy to measure and usually visible within 1 to 2 quarters.
• Cross-border stores and retail (★★★☆☆): useful for adding local payment methods per market, though local acquiring licences and local entities remain your own problem.
• Mainland China domestic acquiring (★☆☆☆☆): domestic CNY acquiring and clearing are outside the capability set; a hard limit.
• One PSP and no payments engineers (☆☆☆☆☆): the worst fit. You get none of the multi-PSP benefit and lack the people to run IaaS, so the usual outcome is a half-finished integration.

Pricing

There are 5 main cost drivers:

• Transaction volume and ticket count
• How many PSPs and target markets are connected
• How many modules are enabled, especially Optimize call volume
• Whether existing credentials must be migrated
• Complexity of settlement currencies and cross-border paths

The table contains no rate figures because Gr4vy does not publish a standard price list. Actual pricing follows the current official quote and your contract; request platform, transaction and module fees separately.

FAQ

• Is Gr4vy an acquirer?
  No. It is a payment orchestration platform positioning itself as IaaS, holding no acquiring licence and no clearing role. Acquiring stays with the PSPs you contract; Gr4vy custodies credentials and routes requests to the right PSP.

• Why insist that PSPs should be stateless?
  Because acquirers have an incentive to keep transactions on their own infrastructure, tied directly to their cost structure. The orchestration layer exists to return routing control to the merchant so each transaction takes the rail that serves the merchant, not the PSP.

• Do I need to change checkout to add a PSP?
  Per the official site, no. Enabling a new PSP or fraud provider happens on the Gr4vy side without a checkout change and without a new API. That is precisely what determines whether a multi-PSP strategy can ship within a couple of quarters.

• What does the IaaS positioning mean for my team?
  More control and more operating responsibility. You are not building infrastructure, but you need someone to work through decline-code mapping, routing strategy and reconciliation definitions. Without payments engineering this integration usually does not get finished.

• Can a mainland China company use it?
  Domestic CNY acquiring and local clearing are out of scope, so mainland entities cannot. An offshore entity serving customers in Australia, Europe or Southeast Asia can evaluate it, but per-market method coverage must be checked against the official list.

Source: original 16IDC content. Product capabilities, supported countries and fee definitions follow the official documentation and your contract.