Business Processes
Payments rarely stand alone. Onboarding a merchant, reviewing a suspicious transaction, approving a payout above a threshold, collecting documents before a limit is raised — each is a sequence of steps, some automated, some requiring a person, most with a deadline attached.
The process engine lets you model these as diagrams instead of code: a definition describes the flow, and every run of it is an instance that moves through the diagram on its own.
The process engine is the Workflow & BPM module. Enable it in the marketplace section of the Admin Console; the section only appears for organizations where the module is active.
What a process is made of
A definition is a graph of nodes connected by arrows. Nodes come in a few kinds:
| Node | What it does |
|---|---|
| Automated step | Calls a platform capability — screen a customer, create a payout, send a notification, evaluate a decision table |
| Human task | Waits for a person. Appears in the task queue with a form, a team and a deadline |
| Exclusive gateway | Picks exactly one outgoing arrow based on a condition |
| Parallel gateway | Splits into several branches and waits for all of them to come back |
| Inclusive gateway | Takes every branch whose condition holds |
| Timer | Holds the process until a moment or for a duration |
| Loop / multi-instance | Repeats a step, or runs it once per element of a collection |
| Sub-process | Embeds another flow as a single step |
| Error boundary | An escape route drawn on a step: when the step fails, the process leaves along this arrow instead of stopping |
Each instance carries variables — a set of values that steps read and write. A screening step writes its verdict, a gateway further down reads it and chooses a branch.
Diagrams are edited visually in the Admin Console and can be imported from and exported to BPMN 2.0 XML, so a flow drawn in an external modeller can be brought in as is.
Human tasks
A task waits in the queue until someone takes it. Taking it makes that person responsible; until then nobody is. A task carries the team it belongs to, the form to fill in, and its deadline.
Operators work the queue from Process tasks in the Admin Console: take a task, fill in the form, complete it with a decision. The decision goes back into the process and determines the next branch. Tasks can also be delegated, returned to the pool, rejected with a reason, or escalated — automatically when the deadline passes, or by hand.
Step reliability
An automated step usually calls something outside the platform, and outside things fail. Three settings decide what happens then. All of them are set on the step and inherited from the definition when the step says nothing.
Retry policy
| Setting | Default | Meaning |
|---|---|---|
| Attempts | 5 | Total tries, the first one included |
| Initial delay | 5 s | Wait before the first retry |
| Multiplier | 5 | How fast the wait grows |
| Maximum delay | 1 h | Ceiling for the wait |
| Retry on | transient | Which failures are worth retrying |
With the defaults a step is tried five times over about 13 minutes: the four retries wait 5 seconds, 25 seconds, 2 minutes and 10 minutes. The one-hour ceiling only comes into play if you raise the attempt count — the fifth wait would be 52 minutes and the sixth would exceed an hour.
What is retried by default. Only failures backed by state on the other side: connection loss, timeout, name resolution failure, HTTP 429, and the gateway errors 502, 503 and 504. A definite answer — no such account, invalid data, already processed, any other 4xx — is not retried, because it will not change.
HTTP 500 is not in that list, and the distinction matters. A 502, 503 or 504 comes from the infrastructure in front of the application: the request did not reach it, or no answer came back, so the work most likely never started. A 500 means the opposite — the application accepted the request and failed partway through, which for a payment means it may have taken the money and failed to report it. Retrying that charges twice.
If you know your provider treats a repeated request as the same operation, add 500 to the step's retry list explicitly. That is a decision about a specific provider, not a default.
The default is deliberately narrow. A process step is often a call to a payment provider, and retrying it without idempotency on the provider's side can charge the customer twice.
Widening the list is your decision, made per step: either all, or a list of failure names and response codes (provider_declined, 409) that is added to the transient ones. Before widening it for a step that moves money, confirm that the provider treats a repeated request as the same operation.
Time limit and heartbeat
Every step has a time limit, 30 seconds unless the step sets its own. It is not a total execution budget — it is how long the step may go without a sign of life.
A long operation (a registry export, waiting for blockchain confirmations, a paginated provider poll) may run far longer than the limit as long as it reports back. Each report restarts the count, so the limit cancels what actually hangs rather than what is merely slow. A step that goes silent past its limit is cancelled, and the failure follows the ordinary path — which means the retry policy applies to it too.
In the task queue this is the difference between a step that is alive at 14:32 and one that is hanging. The overdue only filter shows steps whose deadline has passed with no outcome.
Failure review
When a step runs out of attempts, the process cannot go further on its own, and the task moves to Failure review in the Admin Console. Each entry keeps the node, the failure type and text, the number of attempts made, and the context: which task it was, which definition, and the process variables at the moment of failure.
Two decisions are available:
- Retry — re-executes the step for real. If it succeeds this time, the process continues from where it stood. If the retry cannot even start, the entry returns to the queue rather than disappearing from it.
- Close — records who decided and why. The process stays where it is: closing an entry is a decision not to pursue it, not a confirmation that everything is fine.
A step with an error boundary drawn on it never reaches this page. Such a failure is part of the flow — the process handles it along the drawn route.
The same node appearing here again and again is not an operator's problem but a signal to change the process or the step's retry policy. A burst of entries in a short window usually means a provider outage, not a fault in each individual process.
Versions
Publishing a new version never disturbs running instances: each one finishes on the version it started with, and only new instances use the latest published one.
That raises the practical question — wait for the old ones to finish, or move them? The definition list answers it: for any definition you can see how many live instances are running and suspended on each of its versions, including the ones that have already emptied out.
Editing follows a simple cycle: a published definition is returned to draft, changed, then published again. Every publication is recorded with its version number and a fingerprint of the diagram, so the history of what was published and when is auditable.
Decision tables
Business rules that change often are better kept out of the diagram. A decision table (DMN) holds them as rows of conditions and outcomes: risk thresholds, fee tiers, routing preferences, approval limits.
A process step evaluates the table and continues by its outcome. Tables are versioned, their evaluations are recorded for audit, and two variants of a table can be compared on live traffic through an A/B experiment before one of them is adopted.
Ad-hoc cases
Not every piece of work has a fixed order. Case management covers investigations — a dispute, a compliance review — where tasks are added as the picture develops, milestones are recorded, and the case is resolved and closed rather than following a diagram from start to end.
Where to find it in the Admin Console
| Page | What it is for |
|---|---|
| Process definitions | The catalogue of processes, publication, versions and live instances per version |
| Process editor | The visual diagram, step settings including reliability, BPMN import and export |
| Process tasks | The operator queue: attempts, response deadlines, the overdue only filter |
| Failure review | Steps that exhausted their attempts: retry or close |
| Cases | Ad-hoc investigations |
| Decision tables | Business rules, versions, audit trail, A/B experiments |
| Process analytics | Where instances spend time and where they get stuck |
Related
- Admin Console — the rest of the operator workspace
- Terminals & Routing — how a payment picks its provider
- Getting Started — first setup of the platform