payment-async-flow

Handle async payment callbacks for Pix and Boleto by returning an undefined status on creation, storing the exact callbackUrl, and processing provider webhooks to update the local payment state.

Prevent double-charges in asynchronous payment flows by implementing idempotent Create Payment handling, which ensures duplicate requests or webhook retries do not result in multiple transaction authorizations.

Calculate delayToCancel for redirect-based payment methods by aligning the local timeout value with the specific provider's expiry SLA, ensuring the system waits appropriately before canceling pending transactions.

Webhook signature validation for payment provider callbacks works by preserving and verifying the X-VTEX-signature header, ensuring that incoming notifications genuinely originate from the expected payment provider.

Yes, you can use async payment orchestration for non-VTEX IO platforms, as the flow supports both VTEX IO and non-VTEX IO callback patterns with robust retry semantics for webhook processing.

Async payments return an undefined status on creation because final transaction results are only known after a provider callback, requiring non-blocking flows that defer status updates until webhook notification.