Hold and retries

A payment attempt enters hold state when:

• The merchant's endpoint responds with decision = hold.
• The endpoint times out and the configured default_on_timeout policy resolves to hold.

In both cases, Tekmerion schedules a re-invocation of the KYT endpoint.

Re-invocation

Each re-invocation is a complete new KYT request for the same payment attempt. The request payload is structurally identical to the initial invocation per the Request contract. The invocation_no field increments by 1 with each re-invocation.

The pair (payment_attempt_id, invocation_no) uniquely identifies each invocation within an attempt.

retry_after

When a merchant responds with decision = hold, the retry_after field MUST be present and MUST be a positive integer (seconds). Tekmerion schedules the re-invocation no sooner than retry_after seconds from when the hold decision was received.

When hold originates from a timeout resolution (default_on_timeout = hold), no retry_after is supplied. Tekmerion applies its own retry schedule for that re-invocation.

No maximum re-invocation count

This contract does not define a maximum number of re-invocations per attempt. An attempt remains in hold state until:

• A re-invocation returns approve or reject.
• Ops intervention resolves the attempt through an alternative path.

Merchants implementing hold logic MUST be prepared for eventual resolution through ops channels if automatic re-invocation does not produce a final decision.

Idempotent response handling

Because invocation_no is included in every request, the merchant's endpoint can detect duplicate deliveries of the same invocation. A response to an already-decided invocation_no SHOULD return the original decision again. Tekmerion treats re-delivered responses to the same invocation_no as idempotent.