Transaction processing

Composer can run an actual payment inside a checkpoint — authorize, capture, purchase, verify, or credit — alongside whatever fraud, identity, or 3DS logic the same flow needs. A transaction-processing checkpoint typically runs some or all of this sequence:

Stage	What happens
Collect	A card is captured via Checkout SDK, iFrame or API and vaulted as a portable token
Fraud signal (optional)	A fraud provider (Forter, Sift, or a Marketplace provider) scores the transaction as a node
3DS (optional)	Fires based on risk score or rule; SCA exemptions can apply to low-value traffic
Authorize / Purchase	Runs against the mapped Gateway Token
Recover (optional)	A soft decline or gateway outage is retried automatically on a secondary gateway
Capture (if using auth-then-capture)	Completes a previously authorized transaction

There's no required order beyond what a given step depends on – build the sequence your business logic needs.

Building a transaction processing checkpoint — the hands-on build: creating the checkpoint, wiring steps together, setting the environment, publishing, and calling it from your SDK
Transaction types — reference for each payment step available in the Step Palette (Authorization, Purchase, Capture, Verify, General Credit, and more)
Routing on BIN metadata & normalized fields — using card-level data and gateway-agnostic field names to route a transaction

Recover is an optional paid service and must be enabled by Spreedly for production use — contact your account manager or [email protected]. Billing occurs at the organization level; see your account for details.