Skip to content

Execution delivery

The payer API 0.12 adds POST /v1/payer/transfer-approval-requests/{id}/execution with an empty body, one UUID Idempotency-Key and fresh DPoP from the original active session. Identity checks its retained accepted APPROVED issuer evidence, current source/session eligibility and original deadlines before committing one execution authorization. The command is retained before any switch call. Subsequent delivery always uses that exact command, including its original proof, admission and expiry. Later source holds do not erase a prior authorization commit; they also cannot authorize a new command.

The payer API runs only in the local sandbox: the hosted sandbox does not serve it yet.

GET /v1/payer/transfer-approval-requests/{id}/execution-status is passive. It creates no authorization, dispatch attempt or idle-session renewal. A foreign session gets 404; a signed-out session gets 401. The response always has authority: EXECUTION_STATUS_ONLY and never proves a debit, recipient credit or completed transfer. No issuer token, compact proof or recipient selector is public.

State Meaning
NOT_ADMITTED No local execution command exists.
ADMITTED Local authorization exists without a retained receiving outcome.
UNKNOWN The latest transport attempt has no trustworthy outcome.
STORED A switch receiving receipt was retained. No money movement is implied.
UNAVAILABLE The peer rejected delivery; no monetary outcome is inferred.
INVESTIGATION_REQUIRED A permanent local or observed remote conflict prevents a usable execution status.

The separate status describes the original time window or permanent investigation. CURRENT is not current remote eligibility or dispatch permission. EXPIRED does not erase the record, extend authority or imply a refund. Before admission, execution_id and admitted_at_epoch_seconds are explicitly null. received_at_epoch_seconds remains null until trustworthy receiving evidence exists; an earlier receiving timestamp may remain visible alongside a later UNKNOWN attempt.

Preserve the original request and mutation key after uncertainty, and retry with a fresh DPoP proof. Known results are cached for the same key. Use a new key only for a deliberate new delivery attempt; this still sends the original command and never creates a replacement authorization. Concurrent same-key calls share a pending attempt. Durable limits are sixty key aliases and sixty dispatch attempts per execution, and 120 attempts per original session per minute. Exhaustion returns 429 while passive status remains available. A first authorization after original expiry returns 409.

A switch receiving receipt confirms only that the authorization was retained: it confirms no debit, credit or refund. A revoked session can no longer read or deliver this request. Resolve a lost response with the same retained command, without changing its amount, references or deadline.

The generated SDK exposes deliverPayerTransferExecution, readPayerTransferExecutionStatus and TransferExecutionStatus. Clients supply device-backed DPoP. Independent Android and iOS journeys will consume these contracts after monetary execution is available.

The feature defaults off. In addition to quote, approval and issuer-refresh configuration, identity requires IDENTITY_EXECUTION_ENABLED=true, a literal loopback IDENTITY_EXECUTION_SWITCH_ORIGIN, a separate IDENTITY_EXECUTION_SERVICE_KEY and IDENTITY_EXECUTION_PERIMETER_KEY. The switch execution intake must be explicitly enabled with matching credentials and transfer issuer pins. Provider debit/credit/reversal, ledger posting and production acceptance remain separate work.

For dated debit, credit and reversal evidence, use the separate monetary status contract.