Overview

Composer is Spreedly's unified payment and fraud orchestration platform. It functions as a complete transaction engine – customers build visual workflows to execute authorizations, captures, retries, and refunds natively, with no custom server-side gateway code required.

Who is this guide for?

New Spreedly customers with no prior Spreedly integration. These customers implement payment orchestration for the first time via Composer.

Implementation steps

Phase 1 - Account and environment setup

1. Create a Spreedly account and provision an environment. Retrieve your environment_key and API access secret from app.spreedly.com.
2. Add your payment gateway(s) via Spreedly Connect. Spreedly supports 120+ gateways.
3. To access Composer: log in to app.spreedly.com, navigate to the Composer item in the main navigation menu, and click the "Launch Platform" redirect link. Composer is available to all Spreedly accounts.

Phase 2 - SDK setup and payment method collection

4. Install the Composer Server SDK on your backend — required to call Checkpoints and execute transactions.
5. Install the Composer Client SDK on your frontend if you need client-side checkpoint verifications
6. 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.
7. 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 3 - Configure routing rules and transaction processing in the canvas

8. 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.
9. Assign gateway tokens to workflow branches in the canvas.
10. 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.
11. Add a 3DS or Fraud node in the workflow canvas before any transaction processing node (authorization, purchase).

Phase 4 - Testing and go-live

12. 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.
13. Validate that routing rules and gateway credential mapping fire correctly per transaction profile before switching production traffic.
14. Production cutover: enable the Composer workflow for production traffic.