Transaction Lifecycle Contexts
2 min
\<font color="#78b5c7">\</font> topic type constraint purpose explain transaction lifecycle contexts and how they affect event submission and processing audience api integrators and client developers applies to explain transaction lifecycle contexts and how they affect event submission and processing does not apply to internal batch processing or non‑request‑based integrations api requests represent transactions at specific points in their lifecycle these lifecycle contexts determine how an event should be interpreted , which data is expected , and which importer id and endpoint configuration applies apis support multiple transaction lifecycle contexts to reflect how transactions evolve over time each context represents a distinct evaluation moment with different expectations and constraints the primary lifecycle contexts are pre‑authorization post‑authorization update each context may be associated with a different importer id , even when the underlying transaction relates to the same customer or order (see importer id and endpoint provisioning docid\ y8ukvwykacafl x06y hf ) pre authorization lifecycle context a pre‑authorization event represents a transaction before final authorization or fulfillment this context is typically used when a transaction is being evaluated prior to approval funds have not yet been captured the outcome of the fraud decision may influence whether the transaction proceeds pre‑authorization events often emphasize intent and risk assessment initial payment and device context customer behavior signals available at checkout pre‑authorization requests are commonly associated with importer ids configured specifically for pre‑decision evaluation post authorization lifecycle context a post‑authorization event represents a transaction after authorization has occurred this context is typically used when authorization has already been granted additional fraud evaluation is required downstream actions (such as review, reversal, or escalation) are being considered post‑authorization events may include finalized payment details authorization outcomes additional context not available earlier in the transaction flow post‑authorization events are often sent to a different importer id than pre‑authorization events, reflecting different processing rules and expectations update lifecycle context an update event represents a change to a previously submitted transaction this context is typically used when transaction details have changed additional information has become available corrections or adjustments are required update events do not represent new transactions they modify or augment an existing event and must reference the original transaction identifier update requests may be associated with a dedicated importer id, or the same importer id as the original event, depending on client configuration