Payment Command

Overview

Payment Command is an explicit request for a payment system to perform an action that may change state or create financial effects. Examples include authorize payment, initiate payout, approve refund, close settlement batch, or retry an execution. Payment Command is closely connected to Payment Domain Event , Payment Execution , and Payment Execution Context .

Operational implementation normally requires command ID, actor and authorization context, target aggregate or payment, idempotency key, and validation and deadline. Execution evidence should preserve command, context, policy and configuration versions, selected route, provider references, attempts, state transitions, and resulting events or journal records. The operating record should preserve the original obligation, participants, amount, currency or asset, authoritative identifiers, timestamps, state history, exceptions, and final financial effect. Important failure modes include duplicate or delayed events, wrong destinations or currencies, stale instructions, unavailable providers, unsupported retries, and customer-facing status that differs from authoritative records.

Payment Command should remain distinct from Payment Domain Event, Payment Execution, and Payment Execution Context, because each can represent a different stage, record, control, or financial outcome.

The principal risks include duplicate command execution, ambiguous intent, missing authorization, commands accepted after expiry, and side effects before validation. Testing should include duplicate commands, timeouts with unknown provider outcome, partial progress, retry after restart, policy change during execution, and recovery from a failed step. Useful measures include command acceptance rate, validation failure rate, execution latency, duplicate suppression, and expired-command count.

Execution rules, retry boundaries, irreversible steps, approval requirements, and exception ownership should be reviewed and versioned before release. Controls should validate inputs server-side, authenticate external events, make irreversible actions idempotent, and reconcile provider, network, settlement, and ledger evidence. For Payment Command, this point supports the definition’s focus on explicit request for a payment system to perform an action that may change state or create financial effects.