PSP Integration Guide

forter maps payment data to its own schema server side (see how order data is built and mapped # ) this guide covers the integration side adjustments some psps need for forter to get complete data timing app post auth needs to fire after the psp authorizes payment, so forter can read the finished payment data psps that authorize inside handlepayments() and let the base placeorder route run already satisfy this no changes are needed psps that reimplement placeorder or confirm the payment client side don't fire app post auth in the standard flow, and need a re fire added see example stripe payment element # for this pattern applied in detail passthrough in your psp's controller, find where it calls the app post auth hook and add pspresponse to the options object var options = { req req, res res, pspresponse paymentintent // or adyenresult, braintreetransaction, etc }; the cartridge stores it as order custom forterpspauthresult forter's backend extracts card data, fingerprint, avs/cvv results, charge id, and more from the raw response this also applies to pre auth integrations see order status sync # for how the status sync job forwards this data even when post auth is skipped hook contention sfcc's hookmgr callhook() invokes only the first registered implementation of a hook in the cartridge path if another vendor's cartridge also registers app post auth , only one implementation runs if this happens, register a second hook pointing at forter's existing handler, then call it from the other cartridge's controller in int forter sfra/cartridge/scripts/hooks json { "name" "app forter post auth", "script" " /hooks/postauthorizationhandling" } in the other vendor's cartridge, wherever it calls its own app post auth hookshelper('app forter post auth', 'postauthorization', handlepaymentresult, order, options); the other vendor keeps app post auth both hooks fire independently