Predictive Payments Routing

predictive payment routing (ppr) enables merchants to optimize their payment processing by dynamically selecting the best payment service provider (psp) for each transaction based on real time performance signals target integration workflow predictive routing operates across three stages pre authorization initial routing recommendation post authorization retry routing on decline order status final transaction reporting endpoints /v3/adaptive auth/orders/\[orderid] /v3/orders/\[orderid] recommended integration v3 migrating from v2 to v3 provides merchants with a streamlined process by combining pre auth, post auth, and order status updates in a single integration v3 offers improved routing recommendations, enhancing transaction approval rates and minimizing false declines leveraging advanced payment insights and fraud detection, v3 supports faster, more reliable processing and is prepared for future 3ds execution if a merchant requires v2, it remains fully functional, though additional internal testing will be necessary predictive payment routing flow the routing flow supports 3ds recommendation 3ds with the psp 3ds recommendation + execution by forter feature access and configurations customer and site structure merchant represents the merchant, who may operate multiple sites example customer my streaming platform sites us streaming, eu streaming, mobile app site each site under a merchant may have its own payment configuration, including payment service providers (psps), commitment levels, and routing preferences predictive payment routing feature only customers with predictive payment routing enabled will receive the paymentrecommendations field in the api response for customers without this feature enabled, paymentrecommendations will be absent from the response if predictive payment routing is enabled for a customer all of the customer's sites will include the paymentrecommendations field in the response however, only sites with the correct payment configurations will receive populated data within paymentrecommendations handling the order response the paymentrecommendations field is an object in the response containing payment related recommendations, including potential 3ds requirements merchants should use this object if it is present in the response sample response structure { "forterdecision" "approve", "recommendation" "", "verificationmethod" {}, "processor routing reason" "", "orderid" "tr zooidsh7t2yx7ha1qlioyzwli7ngihjl", "linktoeventindashboard" "https //portal forter com/dashboard/tr zooidsh7t2yx7ha1qlioyzwli7ngihjl", "paymentrecommendations" { "processors" \[ { "processorname" "checkout com", "processormid" "", "priority" 1, "recommendationid" "8b4a2159 9ab3 4e8f 9c83 0b12e7606458", "recommend3ds" false, "regulationrecommendation" "" } ], "processor routing reason" "model recommendation", "action" "process payment" } } key fields in paymentrecommendations processors an array of recommended payment processors, each with field description processorname name or identifier of the recommended processor processormid merchant id as identified by the processor priority priority ranking of the processor recommendation (e g , 1 for highest priority) recommendationid unique identifier for the recommendation recommend3ds boolean indicating if 3ds verification is recommended regulationrecommendation text providing regulatory recommendations or compliance directives processor routing reason why forter provided the recommendation possible values value description model recommendation standard model based recommendation no optional processor no optional processor available according to onboarding documentation ineffective the model decided it will not be beneficial to retry out of scope traffic not part of the routing solution exceeded processing attempts merchant should send 2 iterations only completed payment merchant sent request for routing recommendation for an authorized transaction regulationrecommendation possible values verification required 3ds challenge request sca exemption tra request sca exemption low value request sca exemption corp request sca exemption trusted beneficiary request sca exclusion anonymous request sca exclusion one leg out request sca exclusion mit request sca exclusion moto action recommended action for the transaction possible values process payment do not process no processor preference null currently, the processors array always includes one item only in the future, it might be extended to support multiple items, thus it is an array order requests and status calls order request used for the initial pre auth request ( "authorizationstep" "pre authorization" ) to retrieve the predictive routing decision if a processing attempt fails, submit a second post auth order request ( "authorizationstep" "post authorization" ) with processing details processor name processor response authorization result (text and code) 3ds result, if applicable status call if the first processing attempt is successful, send a status call with the authorization result if the second processing attempt fails, send a status call to report the failed authorization in the status call merchant needs to send processor name processor response authorization result (text and code) 3ds result, if applicable summary when to use order calls and status calls use case call needed 1st pre auth request order pre auth call (to get predictive routing decision) 1st successful processing attempt status call (send authorization result) 1st failed processing attempt post auth call (get 2nd routing decision) 2nd failed processing attempt status call (send authorization result) 2nd successful processing attempt status call (send authorization result) payment processor routing recommendation response matrix use case action processor routing reason billable notes processor recommendation process payment model recommendation true no optional processor no processor preference no optional processor true edge case monitor merchant to configure fallback analytics decided not to retry do not process ineffective true common transaction not under solution no processor preference out of scope false merchant to configure fallback exceeded processing attempts do not process exceeded processing attempts true only 2 iterations supported technical failure in analytics n/a n/a false merchant to configure fallback order call after successful payment do not process authorized payment true second iteration for 3ds policy do not process technical 3ds limitation true merchant does not allow multiple 3ds attempts hard fraud decline do not process hard fraud decline false control group processing process payment control true control group do not process do not process control true important disclaimer the optimal performance of predictive payments routing is subject to merchant following forter's routing recommendation and the respective psps not applying their own rules after forter's recommendation this api documentation may be subject to change as we make improvements or add features any updates will maintain backward compatibility, ensuring no breaking changes for existing integrations