Address Expiration

Overview

Address Expiration limits the usable lifetime of a session-specific payment destination. In OxaPay white-label payments, the generated address is valid only for the configured lifetime, and the documentation warns that funds sent after expiry can be unrecoverable.

The address lifetime is connected to payment-session context such as Expected Amount, pay currency, network, and quote. After expiration, the same visible destination should not be assumed to retain the original rate or automatic matching behavior.

Address expiration differs from Quote Expiration. A price quote controls rate validity, while address expiration controls whether the destination remains recognized for that session. Products can align these timestamps, but systems should store them separately.

It also differs from Static Address Revocation. A static address is designed for reuse and is disabled through a separate lifecycle action. A temporary address normally expires automatically according to the payment configuration.

Interfaces must remove or clearly mark expired instructions and prevent copyable stale QR codes. Late transfers should enter an exception workflow with chain evidence, session timestamps, and recovery rules rather than being silently credited or discarded.

Expiration policy should be enforced consistently across API, web interface, QR code, and support tools. Cached pages and browser history can continue exposing old instructions after the backend has expired them. Payment systems should attach the expiration timestamp to the destination record itself and reject attempts to regenerate a session by merely extending the visible countdown.

Operators should be able to search payments by expired address and determine whether it was ever used, replaced, or exposed. This makes late-payment investigation faster and reduces the chance that support recommends an unsafe manual credit.