Overview
Inversion of control: one KYT invocation per attempt, and where it sits in the pipeline.
The KYT webhook is an outbound HTTP call Tekmerion makes to a merchant-configured endpoint to obtain a compliance decision — approve, reject, or hold — for each payment attempt, after a customer deposit has been observed on-chain and sanctions screening has completed.
Inversion of control
Transaction-level compliance belongs to the merchant. Tekmerion performs session-level geoblock and sanctions screening on the source wallet address before invoking the merchant's endpoint. The final approve/reject decision — whether to sweep funds to the merchant or refund them — is structurally the merchant's responsibility. The KYT webhook is the contract through which that decision is delivered.
Tekmerion has no authority to override the merchant's KYT decision. The merchant's response governs execution.
One invocation per attempt
Each payment attempt that reaches the post-deposit compliance stage triggers exactly one KYT invocation. If the merchant responds hold, Tekmerion re-invokes the webhook after the requested delay. Each re-invocation is a new numbered call on the same attempt; the invocation_no field in the request payload identifies it.
Position in the payment pipeline
The KYT webhook is invoked after:
- An on-chain deposit transfer is observed and attributed to a payment attempt.
- Tekmerion's sanctions screening on the source wallet address completes.
The request payload includes the sanctions screening result alongside the on-chain transfer details.
The KYT webhook is invoked before:
- Funds are swept to the merchant.
- A refund is initiated.
- A Proof-of-Payment is finalized for that attempt.
No execution action occurs until a final KYT decision (approve or reject) is received or the configured timeout policy resolves the attempt.
What the merchant endpoint receives
Tekmerion sends a signed JSON POST request. The payload carries the on-chain context — deposit address, source address, transaction hash, amount, token, chain — together with Tekmerion's sanctions result and a unique invocation identifier.
Full payload rules and field semantics: Request contract
Request authentication: Verifying requests
What the endpoint must return
The endpoint MUST respond within the configured SLA window (default: 60 seconds) with a JSON body containing a decision field set to approve, reject, or hold. Each decision value has conditional required fields:
| Decision | Required field |
|---|---|
approve | sweep_to — destination address for the sweep |
reject | refund_to — address to which funds are returned |
hold | retry_after — seconds before Tekmerion re-invokes |
Full response rules and field-level validation: Response contract
Timeout and hold behavior
If no valid response arrives within the SLA window, the endpoint's configured default_on_timeout policy applies. If a merchant returns hold, Tekmerion schedules a re-invocation. Both paths keep the payment attempt in a pending state until a final decision is received.
SLA and timeouts · Hold and retries
Endpoint health
Tekmerion tracks consecutive failures per endpoint configuration. Sustained failures trigger automatic suspension, blocking further invocations until the endpoint is reactivated.