Migrate to Pre-Auth

overview using a pre authorization flow is a prerequisite for accessing 3ds services if you are updating your existing forter integration from post auth to pre auth, the are three main changes move the order api request to an earlier stage in pre authorization, call forter's order api before calling the psp for authorization and before executing 3ds https //docs forter com/3ds execution , ideally at a point where the routing is already known, so the relevant mid can be provided in the order api request, add the authorizationstep field and include all of the same data as in the post auth request except the authorization results, since you won't have them yet creditcard verificationresults tokenizedcard verificationresults paypal paymentstatus applepay verificationresults androidpay verificationresults digitalwallet paymentsuccessstatus installmentservice serviceresponsecode venmo verificationresults banktransfer paymentsuccessstatus paymentgatewaydata or paymentprocessordata upgrade to order v3 https //docs forter com/reference/order v3 (required for 3ds execution) if you are leveraging forter's 3ds execution services, you must also upgrade to v3 of the order api if your current custom api version does not include order v3, request an updated version from your forter implementation engineer or utilize the standard version published on this site the api request structure is unchanged from v2 to v3, but the api response differs be sure to update your handling for each fraud decision in order response fraud decision (approve \ decline \ not reviewed) is included in the forterdecision field instead of an action field fraud decision v2 response { "action" "approve" } fraud decision v3 response { "forterdecision" "approve", } if you are are guided to retain your post auth integration while adding a pre auth integration (i e receive fraud decisions both before and after authorization), you should take into account the post auth decision only in the event of successful authorization if payment was authorized but forter decision was decline, you should void the authorization 3ds recommendation in order response 3ds recommendation (verification required 3ds challenge) is included in the recommendation string field, instead of the recommendations array 3ds recommendation v2 response { "action" "approve", "recommendations" \["verification required 3ds challenge"] } 3ds recommendation v3 response { "forterdecision" "approve", "recommendation" "verification required 3ds challenge" } psd2 exemption in order response psd2 exemption recommendation (request sca exemption ) is included in the recommendation string field, instead of the recommendations array psd2 exemption v2 response { "action" "approve", "recommendations" \["request sca exemption tra"] } psd2 exemption v3 response { "forterdecision" "approve", "recommendation" "request sca exemption tra" } 3ds execution in order response the v3 response will include the managedordertoken field continue with the integration guide for 3ds execution https //docs forter com/3ds execution send payment authorization details you can streamline the process of sending payment authorization updates by creating a webhook notification from your payment processors that they will send directly to forter forter can accept payment webhook notifications from adyen https //docs forter com/adyen payment webhook , primer https //docs forter com/primer payment webhook , and worldpay https //docs forter com/worldpay payment webhook for all other psps, send an update via the order status api https //docs forter com/reference/order status that includes the verificationresults object with all values from your processor including 3ds results also include an updated status for the order with this request when the authorization succeeds, updatedstatus “processing” when the authorization fails, updatedstatus “canceled by merchant”