Pre-Auth Flow

fires on the app validate order hook, before payment authorization ( forterauthtiming pre auth or pre and post auth ) checkout can be blocked here before the payment processor is ever called sequencediagram participant browser participant sfcc participant psp participant forter api browser >>sfcc submit checkout sfcc >>forter api post /v3/ /orders/{preauthorderno} note over sfcc,forter api app validate order — before payment alt decline forter api >>sfcc declined sfcc >>browser block checkout (no auth fee charged) else approve / not reviewed forter api >>sfcc decision sfcc >>sfcc decision stored on basket sfcc >>psp payment authorization psp >>sfcc auth result sfcc >>sfcc app post auth — copy decision to order sfcc >>sfcc forterorderupdatesfra job syncs status end how it works sfra's base validateorder hook runs first if it errors, checkout stops before any forter logic runs a pre generated order number is reserved for the basket and becomes the order's real number once checkout completes numbers reserved for abandoned or declined checkouts are never reused, so gaps in order numbering are expected this works because checkouthelpers js overrides sfra's base createorder to call ordermgr createorder(basket, orderno) , forcing sfcc to reuse the reserved number rather than minting a new one forter is called with the basket data, using the same order data mapping # as post auth since no order exists yet, fields like order status and payment transaction details are naturally incomplete at this point the decision is written to the basket, then mirrored into the session so it survives until the order is created see getting the decision onto the order # on a decline with fortercancelorderondecline enabled, checkout is blocked immediately, with no order to void