Overview

Composer is Spreedly's unified payment and fraud orchestration platform, built by combining the Dodgeball logic engine with Spreedly's existing Composer product. With the addition of transaction processing in the fall 2026 release, Composer becomes a full transaction engine: customers can execute authorizations, captures, retries, and refunds natively within visual workflows without maintaining custom server-side gateway code.

Who is this guide for?

Merchants currently using Spreedly Vault, Connect, Protect or Optimize — but not Composer (legacy) or Dodgeball. These customers manage payment routing and gateway calls via the core Spreedly gateway API (e.g., POST /v1/gateways/{token}/purchase). They want to adopt Composer to add routing rules and transaction processing to their existing gateway integration without maintaining custom server-side orchestration code.

What changes in Composer 2.0?

• Customers already use the gateway API endpoint that Composer builds on — no endpoint migration is required. What changes is that routing rules and transaction processing logic are now configured in the Composer canvas rather than coded server-side.
• SDK requirements:
  • The new Composer (Dodgeball) SDK (Server & Client).
  • A payment method collection method - Checkout Headless or Express, or the JavaScript API (this is required alongside the server SDK; PM collection is not included in it). Please note that legacy iFrame is also supported but it is a deprecated product. Implementation steps assume this has already been implemented.

Implementation steps

Phase 1 - SDK & tokenization setup

1. Install the Composer Server SDK on your backend — required to call Checkpoints and execute transactions.
2. Install the Composer Client SDK on your frontend if you need client-side checkpoint verifications
3. Payment methods must be tokenized into Spreedly Vault to be processed by Composer 2.0 transaction processing nodes. If currently tokenizing via a gateway-native SDK (Stripe.js, Adyen web component, etc.), this step replaces or supplements that flow. A payment method collection method - Checkout Headless or Express, or the JavaScript API is required alongside the server SDK. Please note that legacy iFrame is also supported but it is a deprecated product.
4. The tokenization call returns a payment_method_token. This token must be available on your server at the point where the Composer Checkpoint is called, so it can be passed into the checkpoint event data for use by the transaction processing node.

Phase 2 - Access Composer

5. Composer is available to all Spreedly accounts. To access it: log in to app.spreedly.com, navigate to the Composer item in the main navigation menu, and click the "Launch Platform" redirect link.

Phase 3 - Configure routing rules and transaction processing in the canvas

6. In the Composer canvas, create a new workflow. Configure routing rules to define which gateway receives transactions based on conditions such as card type, currency, or region.
7. Assign gateway tokens to workflow branches in the canvas.
8. Add transaction processing nodes to define transaction type per branch (Authorize, Capture, or Auth-then-Capture) and configure response handling for approve, soft decline, and hard decline outcomes.
9. Add a 3DS or Fraud node in the workflow canvas before any transaction processing node (authorization, purchase).

Phase 4 - Testing and go-live

10. Test in sandbox using Spreedly test card data. Validate all workflow branches: approve, soft decline, hard decline, and any retry paths. Validate that gateway credential mapping in the canvas routes to the correct gateway.
11. Validate that routing rules and gateway credential mapping fire correctly per transaction profile before switching production traffic.
12. Production cutover: Enable the Composer 2.0 workflow for production traffic. Existing gateway API calls can remain active as a fallback during the transition.