Introducing Composer: Fraud and Payment Orchestration on One Canvas

Every payments team has felt this tension: the fraud tools, the routing logic, and the payment execution all live in different systems, built by different teams, on different timelines. Changing any one of them means opening an engineering ticket and waiting.

Today, we're introducing Composer: Spreedly's no-code visual canvas for orchestrating the entire transaction lifecycle, from fraud and identity checks through authentication, routing, and execution. It's the product of combining our newly-acquired Dodgeball logic engine with Spreedly's payment orchestration platform, and it's the biggest step yet toward a single, neutral command center for how money and risk decisions move through your business.

The problem: your fraud and payment systems can't see each other

Ask a payments or risk team how a transaction gets approved, and the answer spans three or four tools: a fraud vendor, a 3DS provider, routing logic buried in a gateway integration, retry rules hard-coded into a backend service. Each piece works. None of them talk to each other.

This fragmentation costs you in three ways:

1. Hard-coded logic is technical debt. Every new gateway, fraud provider, or routing rule takes an engineering sprint to ship, and teams spend six to twelve months building payment logic that turns brittle and expensive to maintain. Every future change means going back into that code.
2. Fraud and payments are fragmented across systems. Risk scoring, 3DS triggers, routing, and retry logic each live in their own tool. Nobody on the business side can change a rule without opening a ticket and waiting on engineering's roadmap, even when the fix is urgent and the logic is simple.
3. PSP-native orchestration means lock-in. When your orchestration logic sits inside a single processor's ecosystem, it only works with that processor. You can't apply the same fraud rule or routing decision across the rest of your gateway stack, so you end up rebuilding multi-provider strategies piece by piece, in every corner of your infrastructure.

Engineering hours are only part of the bill. The gaps between your tools are the blind spots bad actors look for. A bad actor moving from a fraudulent sign-up to a stolen-card checkout doesn't care that your identity vendor and your payment gateway have never talked to each other. In most stacks today, they haven't.

Composer: unifying fraud and payments in a single place

What it is

Composer is a no-code, visual workflow canvas that sits over Spreedly's platform, putting your risk tools and your payment gateways in the same flow. Instead of writing and maintaining backend code to sequence a fraud check, a 3DS challenge, and an authorization, you build that sequence visually as a chain of connected nodes, and you change it the same way.

We built it by combining Dodgeball's fraud and identity logic engine with Spreedly's network of 150+ gateway and PSP integrations, plus native connections into Spreedly Vault, Protect, Connect, and Optimize. The fraud signal and the payment event now sit in the same view, evaluated by the same rule.

How it works

Every step in the transaction journey is a node on the canvas. You chain nodes in whatever order your business needs:

• Risk: fraud and abuse decisioning: third-party fraud vendor calls, rule sets and score thresholds, allow/block/step-up actions, chargeback signal routing
• Identity: KYC and KYB verification, digital identity checks, onboarding and login checkpoints
• 3DS: dynamic, risk-based authentication triggering, SCA exemption management, multi-gateway 3DS
• Payments: native transaction execution: authorize, capture, auth-then-capture, refunds, reversals, gateway credential mapping, multi-processor chaining
• Control: conditional branches, response handling by decline code, A/B and dark-mode testing, real-time publishing with no deploy

Most PSP-native tools and point orchestrators can't chain risk and payment events in a single flow like this. You end up stitching separate systems together yourself, and maintaining that stitching.

How it runs: a trigger (a checkout, a sign-up, a login) starts the flow. Each node runs, evaluates or acts, and hands off to the next one, and conditional branches decide which path a transaction takes based on the real-time result. Change a threshold, reorder a step, or add a branch, and it takes effect on the next transaction, with no deploy and no release window.

Why it matters

The team that owns the outcome can now own the logic behind it.

Use the vendors you have. Try the ones you don't.

That agility only counts if adding a provider is equally easy. There are two ways to bring one in. Bring your own credentials and connect them to Spreedly, and Composer calls the vendors you've already negotiated with: your contracts, your pricing, your data agreements, nothing to re-procure or re-paper. Or pull from our growing marketplace of pre-negotiated payment and fraud/risk providers: test a new one without a procurement cycle, run one commercial relationship instead of many, and move to your own contract when it makes sense.

What you can build with it

The possibilities are countless, but three examples come up most with customers:

1. Change your payment stack without calling engineering. Swap gateways, add or remove fraud providers, enable new payment methods, or update routing and retry logic directly on the canvas, in minutes. When a fraud tool starts outperforming or a gateway underperforms in a region, your team acts the same day, not next sprint.
2. Fraud check, then 3DS, then authorize. Instead of challenging every transaction, run a risk score first, trigger 3DS only if it crosses a threshold, then authorize. Known-good customers skip the challenge, SCA compliance is covered in mandated markets (EEA, UK, LATAM), and 3DS becomes a lever for lifting issuer approval rates, not a box you check for compliance. That's one orchestrated sequence instead of three integrations you'd otherwise keep in sync yourself.
3. Gateway failover and soft decline recovery. When a primary gateway goes down or returns a soft decline, Composer retries on a backup gateway, with no code change and no incident response. Your customer sees "payment successful," not the outage or the decline behind it.

See it in action. Watch the series →

What's next

Composer's launch lays the foundation: a single canvas, node-based logic, native execution across fraud, identity, authentication, and payments. It's also the blueprint for what comes next. Every future capability ships as a new node type on the same canvas, not a new tool to integrate.

That means what you can build here keeps expanding: smarter, automated routing decisions; retry logic that reaches beyond checkout into subscription billing; even describing the outcome you want and letting Composer build the workflow for you. We'll have more to share as these take shape.

To learn how Composer can make your team move faster, or what it would take to move your stack onto it, talk to our team today