Automatic fulfillment providers

Only a paid order line with an applicable digital/provider delivery type can create an intent. One tenant, order line, and provider operation has one durable operationId, used as the provider idempotency key. Plugins cannot set payment, order, refund, or fulfillment facts directly.

The state machine is pending → dispatching → succeeded | failed_retryable | failed_terminal | unknown | manual_review. Timeout, disconnect, or an unreadable response becomes unknown, never success or an immediate blind retry.

After unknown, query/reconcile by operation ID before any retry. A late success, duplicate callback, concurrent workers, lease expiry, and provider-reference conflict all converge through conditional database updates. Only a confirmed success invokes the public fulfillment service to persist delivery facts and Outbox events once.

Provider credentials are encrypted references and do not enter browsers, events, logs, or this site. Endpoints require HTTPS, an allowlist, redirect limits, private-address and DNS-rebinding controls, response-size/time limits, circuit breakers, and installation quotas. Real provider and network-failure evidence remains separate from deterministic adapter tests.