Post-Auth Flow

fires on the app post auth hook, after payment authorization this is the default timing ( forterauthtiming post auth ) sequencediagram participant browser participant sfcc participant psp participant forter api browser >>sfcc submit checkout sfcc >>psp payment authorization psp >>sfcc auth result, order placed sfcc >>forter api post /v3/ /orders/{orderno} note over sfcc,forter api app post auth — after payment alt decline forter api >>sfcc declined sfcc >>sfcc ordermgr failorder() sfcc >>browser decline message shown else approve forter api >>sfcc approved sfcc >>browser order confirmed else not reviewed forter api >>sfcc not reviewed sfcc >>browser order confirmed — capture held for review end sfcc >>sfcc forterorderupdatesfra job syncs status how it works if the psp controller passed a raw authorization response, it's captured onto order custom forterpspauthresult see psp integration guide # if a pre auth decision exists from earlier in checkout, it's mirrored onto the order under pre and post auth , this step's fresh decision then replaces it only the latest decision is kept, in order custom forterdecision see getting the decision onto the order # forter is called with the full order data see how order data is built and mapped # on a decline with fortercancelorderondecline enabled, the order is voided via ordermgr failorder() then, the cartridge resolves the customer facing decline message if that resolution step fails, the order is already cancelled if another vendor's cartridge also registers app post auth , only one implementation runs sfcc calls just the first match in the cartridge path see hook contention # for the escape hatch