3DS Execution

the 3ds execution integration grants full access to forter's fraud management https //www forter com/platform/fraud management/ and payment optimization https //www forter com/platform/payment optimization/ in a streamlined approach that reduces your development effort it transparently manages the entire 3ds challenge flow , minimizing the communication needed between frontend and backend for a more efficient integration process 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 over authorization > i\["forter approves + recommends exemption"] i > j\["request authorization with exemption from psp"] j > z f psd2 exemption over 3ds > q\["fetch 3ds exemption results from order api response"] q > r\["request authorization with 3ds results (eci, cavv) from psp"] r > z f 3ds recommended > k\["forter returns managedordertoken"] k > l\["call forter js with managedordertoken"] l > m\["forter js executes 3ds flow and triggers your js on completion"] m > n\["trigger your backend to fetch results from forter"] n > o\["fetch results via results api"] o > p\["request authorization with 3ds results (eci, cavv) from psp"] p > z integration steps confirm 3ds prerequisites https //docs forter com/prerequisites verify that both forter's and your psp's integration requirements are met psd2 regulation solution exemption support in the authorization request confirm that your psp can accept and act on an exemption flag in the authorization call this is not always enabled by default — contact your psp to activate it and obtain the relevant api reference forter will return the exemption recommendation in the order response (request sca exemption low value, request sca exemption tra, or request sca exemption corp) pass the exemption flag to your psp in the authorization request as described above exemptions over the 3ds rails certain markets, such as france, require that sca exempt transactions be routed over the 3ds rails (i e , the exemption is embedded within the 3ds message) rather than sent directly in the authorization request (dta path) forter manages this flow end to end internally no additional action is required on your side this is a regulatory routing requirement only — no real 3ds authentication takes place and no challenge will be presented to the cardholder unless the exemption is declined by the bank (soft decline), which will trigger a 3ds authentication flow eci value in the authorization response confirm that your psp returns the eci (electronic commerce indicator) value as part of the authorization or authentication response, and that your system captures and forwards it to forter via the post authorization / status call update the eci value allows forter to accurately assess liability shift, inform future decisioning, and determine whether the exemption was processed over the 3ds rails or via the standard dta path 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 front end integration for 3ds https //docs forter com/front end integration for 3ds in addition to the forter's javascript snippet and mobile sdks that share user behavior information, you'll need to icorporate forter's 3ds client components into the front end of your website and mobile applications these are used in the 3ds initialization and 3ds challenge phases for easier integration checkout with 3ds https //docs forter com/checkout with 3ds send forter the complete order details in the order api to get real time fraud decision, or alternatively an indication to process the response in your checkout page using forter js sdk in order to execute 3ds for the transaction for the forter psd2 solution, a recommendation to request an exemption may be provided in addition to the fraud decision request 3ds results https //docs forter com/3ds results after processing the order response in your checkout page using forter js sdk, call forter to get the fraud decision and 3ds results note this phase is required only in case 3ds is executed for the transaction psp authorization https //docs forter com/psp authorization in cases where forter approved the transaction, call your psp authorization api with the 3ds results (or psd2 exemption request) provided by forter if forter is acting as your 3ds executor and the issuer returns a soft decline after an exemption attempt, forter can continue the flow by initiating 3ds authentication in this case, the transaction is not treated as a final failure yet instead, the soft decline is the issuer’s signal that authentication is required before authorization can proceed to support this flow, your integration should send forter a post authorization update with the authorization result and the relevant 3ds input, in the same general way forter receives data in the pre authorization stage after receiving the soft decline result, forter evaluates whether 3ds should be executed and returns the next step in the authentication flow, including a challenge when applicable if a challenge is required, the customer should remain on the payment page so the authentication can be completed in session once authentication succeeds, pass the 3ds result to your payment service provider on the same transaction, and then send forter the final post authorization update post purchase updates https //docs forter com/post purchase updates as you receive payment authentication updates 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 dispute notifications 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 integration tests 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 production credentials https //docs forter com/reference/environments#x fxu update both javascript snippets and both 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" data validation 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 executing 3ds on live transactions, confirm that your production site is handling responses as expected if you are rolling out gradually, work with your implementation engineer to coordinate ramp up verify 3ds results received by psp confirm that your psp is correctly receiving authorization requests with 3ds results on live transactions