Decision editor

The decision editor is where you add branching logic to a checkpoint – routing a transaction down different paths based on conditions you define, without touching code.

When to use it

  • Route by currency or region to different gateway credentials
  • Branch on order amount (e.g. only run a fraud check above a threshold)
  • Route based on a fraud provider's decision (allow, deny, or step up to 3DS)
  • Scope a rule to one market only (e.g. a routing test limited to one country)

Adding a path

Open a Decision step on the canvas, then Add Path. Give the path a name that describes what it's for (e.g. USD, HighRisk). Set its condition using the field search, an operator, and a value – for example, transaction.currency is one of USD. Any transaction that doesn't match an explicit path falls through to Default.

Data available to condition on comes from your Trigger's Expected Data – transaction and customer fields, and any outputs from a fraud or identity step earlier in the flow.

📘

Paths are evaluated in order, top to bottom, and the first one that passes wins – the transaction takes that path and stops evaluating the rest. Path order matters; put more specific conditions above Default and above broader catch-alls.

Routing each path

Drop the steps for that path underneath it – for example, a Purchase step pointed at a different Gateway Token per branch. Save, then Publish; the canvas updates to show each branch immediately, no redeploy.

Examples

Multi-gateway credential mapping

A common pattern: one path per currency or region, each pointed at its own gateway connection.

  1. Open the Decision step after your payment-method step.
  2. Add Path, name it, and set the condition (e.g. transaction.currency is one of USD).
  3. Drop a Purchase step into the new path and set its Gateway Token to the credential for that region.
  4. Leave the Default path on your original gateway.

Everything that doesn't match an explicit path keeps using Default, so this is safe to add incrementally.

Fraud check before 3DS

Another common pattern: score the transaction first, and only add friction where it's warranted.

  1. Add a Decision step after your fraud-provider step (e.g. Forter, Sift).
  2. One path for "fraud detected" → Deny.
  3. One path for "3DS recommended" → a Perform 3DS Authentication step → then Purchase.
  4. Default path (clean) → straight to Purchase.

Remember: paths reaching the end without an explicit Deny are allowed by default, so you only need to place Deny where you want to block.

A/B testing a rule

If you want to compare two gateways head-to-head rather than route deterministically, an A/B Test step splits traffic by percentage instead of a condition (e.g. 80/20 across two Purchase steps), and you can still scope it with a condition (like a specific country). That's a separate step type from Decision, but it sits in the same part of the canvas.



Did this page help you?