Adyen: Encrypted data used outside of valid time period (172)

Adyen: Encrypted data used outside of valid time period (172)

TL;DR: Your server clock is wrong. Adyen's client-side encrypted card data is only valid within about 24 hours of the real time, so a server stuck in the past (or future) produces 172. Fix the clock with NTP; dont try to work around it in code.

172 - Encrypted data used outside of valid time period

Steps

1. Check the server time. Compare date -u on the server against real UTC. If it is off by hours, days or years, you found it.

• Success check: server UTC matches actual UTC within a minute.

1. Enable time sync. Turn on NTP (chrony/ntpd/systemd-timesyncd) and make sure it actually syncs. Containers and VMs are the usual drifters.

• Success check: the time service reports synchronized, and the offset stays small after a reboot.

1. Regenerate the encrypted payload. The old encrypted blob was minted against the wrong clock. Have the shopper re-enter the card (or re-encrypt) and retry.

• Success check: /payments accepts the fresh encrypted data.

When to use this

• /payments fails with 172, especially on a new server, container, or dev VM.
• The error appears for every card, not just one shopper's.

When NOT to use this

• 174 (unable to decrypt data). That is a key or environment mismatch, not the clock.
• One shopper out of many. Then it is their data, not your server time.

Compatibility

Adyen client-side encryption (Web, iOS, Android), Checkout API and classic API.

Why it happens

The encrypted blob embeds a timestamp so stolen ciphertext cant be replayed forever. Adyen rejects anything encrypted too far from the current time, and a skewed server clock makes fresh encryptions look ancient (or from the future).

Edge cases

• Docker containers inherit the host clock but can drift if the host does. Fix the host.
• If your CI builds test fixtures with encrypted card data, they rot after 24 hours. Generate them fresh in the test run.