Forter Managed

forter's orchestration service provides one unified integration that unlocks multiple services fraud prevention, predictive payment routing (ppr), and payment orchestration each service can be enabled independently or combined, with no additional engineering work, allowing merchants to start with any capability and expand seamlessly over time end to end flow flowchart td a\["customer enters card details"] > b\["hosted fields tokenizes card"] b > c\["create payment via api"] c > d{"fraud check"} d decline > e\["transaction rejected"] d approve > f{"3ds required?"} f yes > g\["execute 3ds challenge"] g > h{"challenge success?"} h no > e h yes > i\["route to optimal psp"] f no > i i > j{"authorization success?"} j no > k\["ppr retry with next psp"] k > j j yes > l\["payment captured"] l > m\["webhook notification"] integration steps add hosted fields sdk add forter's checkouttools library to your checkout page, wherever the card entry iframe is located the script should be pasted directly before the closing html \</body> tag generate an auth token before using the forter hosted fields sdk, your backend must generate a temporary authentication token make a request from your backend to /v1/tokenization/client key endpoint in the tokenization api, including the required authentication headers example request { "ttlminutes" 60 } example response { "clientkey" "token value" } tokenize card data using hosted fields sdk initialize the sdk call the init method on the hosted fields sdk, passing in the auth token you received in the previous step const fortercollect = await window\ checkouttools collect init({ environment 'sandbox', authtoken 'token value' }); add hosted fields placeholders to the checkout page form initialize the hosted fields using the sdk instance fortercollect addfields({ 'cc holder' { type 'card holder name' }, 'cc number' { type 'card number', }, 'cc exp' { type 'card expiration date', }, 'cc cvc' { type 'card cvc', } }); submit the form & receive a token when the customer submits the form, call the submit() method to receive a single use token const tokenresult = await fortercollect submit(); console log(tokenresult); response example { "success" true, "token" "ftr12d4e830283b647d4b3b2a3d65f02b8ab" } upgrade token (optional) if you need to store the payment method and/or provision a network token for it, you must use the /upgrade endpoint calling this endpoint creates a new multi use token and invalidates the existing single use token along with its cvc you can also choose to provision a network token during the upgrade, allowing forter to use it later during authorization example request { "token" "ftr1d8a56cfa6b3745a39e4a42d5ab1048c8", "networktoken" { "provision" true } } example response { "token" "ftr1efsdfew54wetg54ugdn58ns0482ko", "networktokenstatus" { "created" true } } create payment post /api/payments initiates a payment forter performs fraud check, routing, and authorization fortertokenstring is the token generated in the previous section amount field is expressed in cents set confirm true for immediate capture set capturemethod to automatic or manual example request { "cartitems" \[ { "name" "testitem", "price" 1099, "quantity" 1, "type" "tangible" } ], "amount" 1099, "currency" "usd", "paymentmethod" { "type" "token", "fortertokenstring" "{{token}}" }, "capturemethod" "automatic", "confirm" true, "connectioninformation" { "customerip" "127 0 0 2", "useragent" "mozilla/5 0" }, "primarydeliverydetails" { "deliverymethod" "", "deliverytype" "digital" } } example response { "id" "string", "amount" 9876, "amountreceived" 9876, "created" "2025 07 14t12 34 56 789z", "currency" "aud", "status" "succeeded", "connector" "adyen", "capturemethod" "automatic", "paymentmethod" "card", "paymentmethodtype" "string" } execute 3ds (if required) if forter determines that 3ds is recommended or required, the payment create response will include a 3ds sdk token you'll need to pass this token to the frontend so it can run the 3ds flow example response (with 3ds sdk token) { "status" "requires action", "nextaction" { "type" "use sdk", "usesdk" { "token" "sdk token 123" } } } 3ds sdk usage await window\ checkouttools managedorders manageorder( managedordertoken, { challengecontainer () => { // render custom container for challenge modal if needed return htmlelement; // can be null to render forter's default modal } } ); authorize payment post /payments/ \ id /confirm used in case of confirm false example response { "id" "string", "amount" 9876, "amountreceived" 9876, "created" "2025 07 14t12 34 56 789z", "currency" "aud", "status" "succeeded", "connector" "adyen", "capturemethod" "automatic", "paymentmethod" "card", "paymentmethodtype" "string" } capture payment post /payments/ \ id /capture used only if capturemethod was set to manual in /api/payments the amounttocapture is optional and should be provided only for partial captures example request { "amounttocapture" 1000 } example response { "id" "string", "amount" 9876, "amountreceived" 9876, "created" "2025 07 14t12 34 56 789z", "currency" "aud", "status" "succeeded", "connector" "adyen", "capturemethod" "automatic", "paymentmethod" "card", "paymentmethodtype" "string" } automatic retry logic – predictive payment routing (ppr) if the selected psp declines or fails, forter automatically generates a new routing recommendation the previous psp + failure reason is sent to ppr the next best psp is returned based on live success metrics forter retries authorization with the new psp transparently retries are idempotent and bounded by configurable limits this is an internal process and does not require any merchant action webhooks forter delivers asynchronous updates for every lifecycle event event type description payment authorized payment successfully authorized payment captured funds successfully captured payment failed payment or capture failed payment cancelled payment was cancelled (by merchant or by forter) refund succeeded refund processed successfully refund failed refund failed to process example webhook payload { "type" "payment authorized", "eventid" "123456", "timestamp" "2024 11 07t05 31 56z", "data" { "paymentid" "pay 9981", "processor" "adyen" } } forter webhooks include x forter signature and x forter timestamp headers for validation implementation notes forter's hosted fields must be used for pci compliance merchants are never exposed to raw pci data single use forter token expires within a maximum of 24 hours in case the customer chooses to store the payment method, you can upgrade to a long lived token using the forter tokenization api each transaction is idempotent by idempotency key to prevent double charges