Durable transaction lifecycle

Admission locks the account, then vendor, and resolves idempotency before checking new allowance. It atomically writes the quote consumption, purchase identity and reservation. The persisted queued row is the dispatch record. A scheduler scan recovers work even if publishing to the queue fails.

queued → creating → created → confirming → pending → completed → reversed
                       ↘ cancelling → cancelled
uncertain result → needs_review → authenticated reconciliation
verified rejection / decline → failed

A create claim commits before the provider HTTP request. The worker sends auto_confirm: false. It records the returned identity and actual provider cost, adjusts the reservation, validates the benefit and rechecks controls before committing a separate confirmation claim. It then confirms that same provider ID. Provider calls occur outside database transactions.

A timeout or worker crash after either claim never permits repeating that action. Reconciliation retrieves the transaction by its original provider ID, or its original external ID if creation was ambiguous. A missing lookup result is not rejection evidence. Reservations remain outstanding until verified terminal evidence arrives.

If the actual cost exceeds a limit, or the selling charge/benefit no longer matches the quote, the gateway claims cancellation of the unconfirmed provider transaction. A failed cancellation retains its hold and remains under review. A provider hold can temporarily exceed the expected reserved amount before the changed cost is known; confirmed spending remains gated.

Callbacks are untrusted hints. They schedule an authenticated provider GET and cannot set a status, fulfilment or reservation directly. Completed transactions continue to be reconciled for late reversals.

Completion and delivery

The provider completion date is used when returned as a valid timestamp. Otherwise the first verified completion timestamp is recorded, along with completion_time_source. Completion converts a reservation into gross spent allowance once. Duplicate and stale callbacks do not regress terminal state. Reversals retain original gross cost and do not replenish allowance.

PIN, eSIM metadata, activation data and recipient inputs are encrypted with Laravel's application key. Restrict fulfilment:read; retrieval is audited and sent with Cache-Control: no-store. Never log these payloads in consuming applications. Back up and protect the application key; changing it without a key-rotation plan makes stored fulfilment unreadable.

Unknown provider evidence remains unknown. Staff can request status verification, but the dashboard provides no force-success, manual-release or resend-purchase action.