Time To Live (TTL) defines how long a value remains valid before it expires. In payments, cryptograms (TAVV, UCAF, AEVV) have short TTLs, often minutes, because they are single-use authorization proofs. Idempotency keys and session tokens have longer TTLs balanced against replay risk.
TTL mismatches cause subtle production bugs: your checkout cache reuses a cryptogram across retry windows; a subscription job batches authorizations with stale values; a mobile SDK holds JWE payloads too long before provisioning. Instrument cryptogram fetch timestamps and decline codes tied to expiry.
DNS TTL is unrelated but often confused in infrastructure runbooks; payment TTL here means cryptographic or session validity windows.
Veliro documents cryptogram TTL expectations per scheme and returns fresh values on each POST …/cryptogram call. Design your authorization pipeline to fetch cryptograms as late as possible before forward-to-PSP, not at token creation time hours earlier.
Queue workers that batch billings should fetch cryptograms inside the job immediately before forward, not reuse values fetched during an earlier scheduling step, TTL bugs show up as intermittent “works on retry” declines.