The operator issues the signed trace.
Upstream of checkout. agent_kya_id, audience, scope, max_amount_cents, and principal_hash. This is not a merchant call.
A shopping agent can carry a real customer request and still exceed the purchase it was meant to make. Your backend verifies the agent, then enforces the operator's signed trace — audience, scope, and spending limit — before the card is touched.
The customer asked for a $149 replacement filter. The agent also added a $39 protection plan. Identity can still come back accept. The signed cap is a different call.
Upstream of checkout. agent_kya_id, audience, scope, max_amount_cents, and principal_hash. This is not a merchant call.
Send kya_id and transaction_context. Get identity, trust_score, and an accept / review / decline recommendation. This call does not enforce the signed cap.
Send the trace_jwt with the cart. If the cart is outside audience, scope, or spend cap, decision is decline and the session is failed. The card is not touched.
/api/v1/verify returns identity and a recommendation. It does not enforce audience, scope, or max_amount_cents. That is /api/v1/checkout/sessions. Keep both records with the order.
Read the API docsPOST /api/v1/verify
Authorization: Bearer $KYA_KEY
{
"kya_id": "kya_agent_01HX7K9M2PQR",
"transaction_context": {
"amount_cents": 18800,
"currency": "USD"
}
}Response shape
{
"kya_id": "kya_agent_01HX7K9M2PQR",
"recommendation": "accept",
"trust_score": 82,
"trust_level": "high",
"verification_id": "kya_ver_01HX7KA9J"
}You decide whether checkout proceeds. KYA does not invent a detector. The APIs run when you send them a kya_id or a trace_jwt.
No. You call KYA on the agent path. Human sessions are unchanged. Neither /api/v1/verify nor /api/v1/checkout/sessions moves the card.
Two merchant calls. Shopify or custom API. Keep the verification and checkout-session records with the order.