Spreedly

Service Overview

Spreedly is a payment orchestration provider. The operating entity is Spreedly, Inc., headquartered in the United States. Its current positioning line is "Payment Orchestration for the Agentic Era", which pushes the orchestration layer toward AI-agent-initiated commerce.

It does not acquire. It is neither an acquirer nor a PSP. Settlement still runs through the gateways, processors or acquirers the merchant has contracted with; Spreedly sits in the middle and does three jobs — hold the credentials, route the request, and chain fraud and 3DS together.

The four pillars are the place to start. Vault stores card and payment credentials in the merchant's own vault. Connect lets 1 integration reach any gateway, provider or processor. Protect chains the merchant's chosen fraud, identity and 3DS providers onto the same path. Optimize uses real-time cost and authorization data to decide which rail every single transaction should take.

The agentic commerce claim deserves its own look. The official site states that 1 integration covers the standards proposed in that direction by OpenAI, Google, Visa and Mastercard, so a transaction can start inside ChatGPT or Gemini while the merchant remains the merchant of record — funds, refunds and liability stay with the merchant, and the AI platform is only an entry point, not a payee.

One thing needs saying up front: the value here is not how clever the routing algorithm is, but who owns the vault. That single fact sets the cost structure later and decides whether you can still change processors in 3 years. Plenty of teams buy it as multi-rail failover and only later realize the real benefit is holding their own credentials.

Key Strengths

• Credential sovereignty is the real differentiator: card data lives in the merchant's own vault, so switching processors means moving the store over, not asking every existing customer to re-enter a card. Without that, changing PSP means re-enrolling the whole customer base, and the drop-off alone can kill the project — which is exactly where many multi-rail strategies quietly die.
• One integration, near-zero marginal cost for later switches: Connect absorbs gateway differences behind a single interface. Adding a rail, replacing a rail or splitting a rail by country becomes configuration on the Spreedly side rather than a checkout rewrite.
• Composer takes rule changes off the engineering calendar: the payments team assembles fraud, routing and settlement rules and publishes them the same day. Fraud policy and routing policy are operational decisions and should not consume 2 sprints each time.
• Routing decisions use real-time cost and approval data: Optimize decides rail by rail from actual transaction outcomes instead of a static priority order. The official numbers are 30%+ authorization lift and more than 1 billion USD in recovered revenue.
• Fraud, identity and 3DS providers stay swappable: Protect does not lock you to one fraud vendor, so negotiating leverage and replacement rights remain with the merchant. For high-risk categories, vendor replaceability often matters more than the scoring model itself.
• Public customers span both high-risk and high-ticket ends: SeatGeek, Priceline and Hopper are high-ticket, time-critical travel and ticketing; Lemonade is regulated insurance; HBO Max, Bandcamp and Chargebee are subscriptions and digital content. All of those demand strong authorization rates and failover, which suggests the product has run under real pressure.

Product Ecosystem

Vault

Vault is the foundation of the whole product. Card numbers, tokens and payment credentials are held in the merchant's own vault, decoupled from any specific processor. The credential lifecycle is therefore no longer hostage to a single gateway: switching gateways, adding gateways or routing by region all leave existing customers untouched.

Connect

Connect provides a unified integration surface so merchants reach any gateway, provider or processor through one interface. Integrate once, and every additional rail afterwards is a configuration step. For cross-border businesses that split traffic by country, currency or card scheme, this removes the repeated work of writing each gateway integration from scratch.

Protect

Protect chains fraud, identity verification and 3DS providers onto the transaction path, and the merchant picks those providers. That is a fundamentally different procurement stance from using the orchestrator's bundled fraud stack: the first keeps pricing power and replacement rights, the second locks fraud into the orchestrator as well.

Optimize

Optimize makes a routing decision per transaction from real-time cost and authorization data. The difference from fixed-priority rotation is that it treats each rail's current performance as an input rather than treating historical assumptions as rules. In a multi-rail setup that difference shows up as several points of authorization rate.

Composer

Composer is a visual canvas aimed at payment operations. Fraud rules, routing conditions and settlement logic are assembled on the canvas and published without waiting for engineering to change code. This layer decouples payment strategy iteration speed from the engineering cadence and lets an operations team tune strategy directly for the first time.

Integrations and Developer API

An API plus webhooks covers enrollment, tokenization, transactions and callbacks. For custom-built systems the integration surface is mostly credential capture and token usage; for businesses that already have a checkout, the backend routing layer can be replaced with minimal front-end change.

Limitations

• No acquiring, so you are still the contracting party everywhere: merchant accounts, deposits, underwriting and settlement cycles are negotiated with each gateway. An orchestration layer does not solve the upstream question of whether you can even get an account.
• Opaque pricing: no standard rate card is published and everything is negotiated. Small-volume teams get neither a good price nor a clear total-cost model before signing.
• Engineering-heavy learning curve: teams must understand gateway differences, tokenization mechanics, 3DS flows and decline-code semantics. Without 1 or 2 payments engineers this stack is hard to run independently.
• Limited upside for single-rail merchants: with 1 processor and no failover requirement, integration and migration effort usually exceeds the benefit, and the processor's own SDK is the better call.
• Mainland China entities cannot really use it: local CNY acquiring, domestic clearing and filing requirements are all outside the coverage, so domestic operations should not shortlist it.
• A self-held vault enlarges compliance exposure: keeping credentials in-house pushes PCI DSS scope definition, encryption and access auditing back onto the merchant. That effort is frequently underestimated at procurement time.

Use Cases

• Multi-acquirer and multi-rail failover (★★★★★): businesses already contracted with 2+ gateways that need to split traffic by region or card scheme get the most direct return, since both the credential vault and the routing layer match the requirement exactly.
• High-ticket and high-risk categories (★★★★☆): ticketing, travel, insurance and iGaming are extremely sensitive to authorization rate, and per-transaction routing plus swappable fraud translate into measurable revenue.
• Subscription and membership businesses (★★★★☆): credentials sit in an owned vault, so switching rails at renewal never forces a customer to re-enter a card, which matters for churn.
• Cross-border stores and outbound brands (★★★☆☆): useful when you need local payment methods and local acquirers by country, but the local acquiring licences are still yours to obtain.
• Mainland China domestic acquiring (★☆☆☆☆): domestic CNY acquiring, clearing and filing rails are out of scope, so this is a hard limitation rather than a roadmap gap.
• Small merchants on a single PSP (☆☆☆☆☆): the worst fit. A team with 1 processor and modest volume pays far more in integration and operations than it gains.

Pricing

There are 5 main cost drivers:

• Transaction volume and ticket count — larger scale means a lower unit price
• How many gateways and processors are connected — more rails means more configuration work
• Whether existing credentials must be migrated, which is a classic one-off heavy cost
• How many modules are enabled, especially routing and fraud call volume
• Whether multi-currency, multi-region and bespoke 3DS flows are involved

The table contains no rate figures because Spreedly does not publish a standard price list. Actual pricing follows the current official quote and your contract; for large or complex programmes, negotiate directly with sales.

FAQ

• Does Spreedly acquire payments for me?
  No. It is an orchestration layer, holding no acquiring licence and no funds clearing. You still contract gateways, processors or acquirers yourself; Spreedly custodies the credentials, routes requests to the right rail and chains fraud with 3DS.

• Will existing customers have to re-enter cards when I change processors?
  No, and that is the core value of Vault. Credentials live in the merchant's own vault, decoupled from the processor, so the same tokens work after a rail switch. The precondition is that credentials really are stored in Spreedly's Vault rather than still held by the original gateway.

• Is an orchestration layer worth it with only 1 processor?
  Usually not. The return comes from choosing between multiple rails; in a single-rail setup the integration and operations burden clearly exceeds the benefit, and the processor's own SDK is cheaper. Revisit when you add a second processor or need to split traffic by region.

• Can Composer let the business team own fraud rules?
  Yes, with guardrails. Composer lets the payments team build and publish rules without engineering cycles, but fraud rules directly affect money lost, so explicit approval and rollback processes are still required rather than letting anyone edit at will.

• Can a mainland China company use it?
  Domestic CNY acquiring and local clearing are out of scope, so mainland entities generally cannot. An offshore entity serving markets outside mainland China can evaluate it; technical feasibility and business compliance are separate questions and should be assessed separately.

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