3DS Recommendation

the 3ds recommendation integration offers access to forter's https //www forter com/platform/fraud management/ and https //www forter com/platform/payment optimization/ if you are already integrated with a 3ds provider integration flow flowchart td b\["send order data to forter via order api"] > c{"fraudulent transaction?"} c yes > d\["forter declines"] d > e\["send decline message to buyer"] c no > f{"authorization path"} f standard authorization > g\["forter approves"] g > h\["request authorization from psp"] h > z\["share order and authorization status with forter"] f psd2 exemption > i\["forter approves + recommends exemption"] i > j\["request authorization with exemption from psp"] j > z f 3ds recommended > k\["forter approves or declines + recommends 3ds"] k > l\["request authorization with 3ds from psp"] l > z integration steps confirm 3ds prerequisites verify that both forter's and your psp's integration requirements are met psp supports 3ds requests verify with your psp that you can request to trigger 3ds in the authorization call contact your psp to enable such a request as it is not always activated by default get the relevant reference details from your psp for calling the authorization api with the 3ds request psd2 regulation solution verify with your psp that you can request psd2 exemptions in the authorization call, such as for low value or low risk transactions get the relevant reference details from your psp, for calling the authorization api with the exemption request japan regulation solution notify forter which scenarios you are subject to under japan's 3ds regulation 3ds upon the merchant judgment, for high risk transactions and when preferred by issuers 3ds when registering a card number to an account (either at checkout or via the account page) and for high risk transactions 3ds on transactions with a saved card is not required as long as fraud check at checkout is in place 3ds on every transaction bin & last 4 verify that you can pass the card's bin number & last four digits in forter's order api request to cover both 6 digit and 8 digit bin scenarios, we ask you to provide 8 digits in the bin field https //docs forter com/front end integration follow the instructions for front end integration for fraud management, including installing mobile sdks on your mobile applications send order api request as with the https //docs forter com/checkout integration for fraud management, send forter the complete order details in the order api to get real time fraud decisions along with payment optimization recommendation for the authorization call the request should be sent before calling the payment gateway to authorize funds (pre auth flow) the full request and response data can be found in ourorder api reference documentation for japan solution only when saving a card, separately or during checkout, include in the order request at the event of saving the card (either separately or during checkout) payment\[0] saveddata chosetosavedata true payment\[0] saveddata usedsaveddata false payment\[0] creditcard threedsecure acquirerdata acquirername payment\[0] creditcard threedsecure acquirerdata acquirercountry at the event of transaction with the saved card payment\[0] saveddata chosetosavedata false payment\[0] saveddata usedsaveddata true payment\[0] tokenizedcard threedsecure acquirerdata acquirername payment\[0] tokenizedcard threedsecure acquirerdata acquirercountry handle order api response the response will include forter's fraud decision, along with a recommendation regarding whether to execute 3ds during the authorization call in situations where a psd2 solution or japan solution is applicable, the response may include a recommendation to request an exemption from 3ds during the authorization call outcome call to action order response fields forter approved transaction is approved by forter, 3ds was not recommended standard authorization "forterdecision" "approve", "verificationmethod" {} to simulate this response, use mailto\ approve\@forter com in the accountowner object in the order api request forter declined transaction is declined by forter, 3ds was not recommended do not authorize "forterdecision" "decline", "verificationmethod" {} to simulate this response, use mailto\ decline\@forter com in the accountowner object in the order api request forter declined & recommends 3ds borderline transaction which was declined by forter, and 3ds is recommended in order to approve it capture only following a successful 3ds "forterdecision" "decline", "recommendation" "verification required 3ds challenge" to simulate this response, use the email address mailto\ force 3ds risk recommendation\@forter com in the accountowner object in the order api request forter did not review transaction was not reviewed for a fraud decision act according to policy prior to forter integration "forterdecision" "not reviewed", "recommendation" "", "verificationmethod" {} to simulate this response, use mailto\ notreviewed\@forter com in the accountowner object in the order api request additional outcomes applicable only to frictionless 3ds solution outcome call to action order response fields forter approved & recommends frictionless 3ds authorize with 3ds "forterdecision" "approve" "recommendation" "verification required 3ds challenge" additional outcomes applicable only to psd2 solution outcome call to action order response fields forter approved & recommends requesting an exemption from psd2 transaction is approved by forter and forter recommends asking for an exemption from 3ds when requesting payment authorization authorize with exemption request please note that not all processors support all types of exemptions forter will recommend specific exemptions only if they are supported by the processor specified in the order request "forterdecision" "approve", "recommendation" "request sca exemption tra" to simulate, use card number 5222220000000006 and mailto\ force exemption tra\@forter com in the order api request "forterdecision" "approve", "recommendation" "request sca exemption low value" to simulate, use card number 5222220000000006 and mailto\ force exemption low value\@forter com in the order api request "forterdecision" "approve", "recommendation" "request sca exemption corp" to simulate, use card number 5222220000000006 and mailto\ force exemption corp\@forter com in the order api request forter approved & recommends requesting a psd2 exemption over 3ds rails psd2 transaction is approved by forter, and forter recommends asking for an exemption from 3ds over the 3ds rails when requesting payment authorization authorize with exemption over rails request please note that not all processors support all types of exemptions check with your psp to determine which exemptions are supported "forterdecision" "approve", "recommendation" "request sca exemption low value emvco" to simulate, use mailto\ force exemption low value emvco\@forter com and card number 5222220000000006 in the order api request "forterdecision" "approve", "recommendation" "request sca exemption tra emvco" to simulate, use mailto\ force exemption tra emvco\@forter com and card number 5222220000000006 in the order api request "forterdecision" "approve", "recommendation" "request sca exemption corp emvco" to simulate, use mailto\ force exemption corp emvco\@forter com and card number 5222220000000006 in the order api request forter approved & recommends 3ds to comply with psd2 psd2 transaction is approved by forter, and 3ds is recommended in order to comply with psd2 authorize with 3ds request "forterdecision" "approve", "recommendation" "verification required 3ds challenge" to simulate, use mailto\ force 3ds psd2 recommendation\@forter com in the accountowner object with in the order api request forter approved & transaction is excluded from psd2 transaction is approved by forter and the transaction is excluded from psd2 requirements, even if it involves an eu merchant and an eu consumer the exclusion recommendation serves as an informative indicator explaining the reason why the transaction is not considered for psd2 standard authorization the exclusion message is informative only, and you do not need to include any specific value in the payment authorization request "forterdecision" "approve", "recommendation" "request sca exclusion anonymous" to simulate, use card number 5222220000000006 and mailto\ force exclusion anonymous\@forter com in the order api request "forterdecision" "approve", "recommendation" "request sca exclusion moto" to simulate, use card number 5222220000000006 and mailto\ force exclusion moto\@forter com in the order api request "forterdecision" "approve", "recommendation" "request sca exclusion one leg out" to simulate, use card number 5222220000000006 and mailto\ force exclusion one leg out\@forter com in the order api request additional outcomes applicable only to japan solution outcome call to action order response fields forter approved & recommends avoiding 3ds with exemption standard authorization without 3ds "forterdecision" "approve", "recommendation" "request sca exemption" a response with an exemption is optional you may choose not to receive any recommendation in such cases, as unlike psd2, japan’s regulation does not require adding any exemption flag to the authorization request to simulate, use mailto\ force exemption jp\@forter com in the order api request forter approved & 3ds is recommended authorize with 3ds request "forterdecision" "approve", "recommendation" "verification required 3ds challenge" to simulate, use mailto\ force 3ds jp recommendation\@forter com in the order api request forter approved & transaction is excluded from japan 3ds regulation standard authorization without 3ds "forterdecision" "approve", "recommendation" "" no recommendation will be returned, only a fraud decision request authorization with 3ds pass the bank a request to trigger 3ds following forter's recommendation in the order response you should adjust your integration with the psp and include 3ds request flag in the psp authorization request as an example, https //docs adyen com/online payments/psd2 sca compliance and implementation guide/sca options/#perform 3d secure authentication describes how to flag the request in the payment request for psd2 exemption recommendations, follow the same instructions as in 3ds execution https //docs forter com/psp authorization https //docs forter com/post purchase updates as you receive payment authentication updates, including 3ds results, and the order fulfillment status changes, it's important to keep forter notified so that this information can be used in future decisions we strongly recommend using a webhook to send notifications about payment authorization and disputes if your psp is supported https //docs forter com/dispute notifications notifying forter of disputes (also called claims, chargebacks, or fraud alerts) is extremely important because it enables forter's system to learn and continually improve future decisions, tailoring our system to your company's needs you can send these updates to forter via a webhook from your psp or via forter's dispute api endpoint complete https //docs forter com/qa#uk1vi the purpose of forter's integration tests is to make sure that your integration covers all relevant use cases, while still in the sandbox or test environment each use case may need a different combination of attributes and values to make sure you have covered each of the use cases we expect in your integration, please go through the test scenario list in the integration tests section of portal for each, you'll need to create the scenario in your sandbox site that will generate a call to forter's api then, select the corresponding api request that forter received and click run to verify that the sample request meets the criteria deploy to production once the integration tests have passed, and you've reviewed any gaps with a forter implementation engineer please, deploy your code to your production environment, with two critical adjustments replace your site id and secret key with your https //docs forter com/reference/environments#x fxu update your javascript snippet and mobile sdks to use your production site id and the production hash keys, if relevant please note that this does not yet complete your integration until forter has switched your site to live (after data validation), all forter decisions will return "not reviewed" https //docs forter com/qa#qeexu once in production, forter uses a data validation tool to execute a set of automated tests across your live data in aggregation the test outputs are daily reports that validate the accuracy and completeness of the production data we receive from you you can monitor this output in forter portal under integration center tools we recommend checking the report daily to identify any failed tests go live as forter begins to send decisions and recommendations, confirm that your production site is handling responses as expected verify 3ds recommendations with psp confirm that your psp is correctly receiving authorization requests with 3ds recommendations on live transactions