Terminal Payment State

Overview

How it works

What matters in practice

A terminal state is an endpoint defined by a particular workflow, such as an invoice accepted and fulfilled, permanently canceled, or failed after its recovery policy ends. 'Terminal' must be scoped: an invoice can be complete while a refund or dispute workflow opens later. Avoid treating terminal as an excuse to discard events, because late transfers and reconciliation adjustments still need to be recorded. Define allowed corrections through separate adjustment states or compensating events with audit history rather than silently rewriting old decisions.

State-machine designers should decide what can happen after terminal completion without deleting history. An unexpected late deposit may open a separate excess-payment case; an accepted order might later generate a refund obligation. Implement those as linked events or new processes, not as a casual rollback of a previously audited payment. Clearly document whether terminal refers to payment acceptance, fulfillment or merchant settlement.

Design automated actions around the transition into a terminal state, not repeated readings of the terminal label. For example, a fulfillment event should fire once when an invoice first becomes accepted, with a durable idempotency key. Rebuilding the state machine after an outage must not send another access code merely because the record still says 'paid'.

Related glossary concepts

Payment State Recovery; Payout Processing Pipeline; Payout State