Smart Payments 3DS Recommendation

Suggest Edits

3DS Recommendations Only - Integration Overview

Forter's Smart 3DS/PSD2 Recommendations allow merchants to maximize transactions authorized by their psp and minimize the friction for legitimate customers by providing recommendations for the application of 3DS while balancing risk, regulation, and customer experience needs.

Required APIs

Step 1: Front End Integration

In your dedicated Forter portal, you will receive a JavaScript snippet for both sandbox and production. For native mobile apps, you will receive links to download Forter's Native SDKs. You'll paste the JS script on the appropriate pages of your website or call mobile SDK methods on relevant mobile app screens so that it can load and asynchronously collect important behavioral data from your customer. The script or mobileUID generated by the mobile SDK will also generate a unique token for each user on your site that should be included in the Account Sign Up API Request Body.

Step 2: Pre-Auth Validation API

**Pre-Auth Validation API Request** The Validation API should be called _prior_ to the call made to your payment gateway to authorize customer funds. This API is used to provide Forter with all relevant data points that will help Forter determine whether the entity conducting the transaction/engagement is legitimate or fraudulent. Key data points include:

Please see the Order Validation API Reference section for more details.

  • Order ID - the unique identifier for the order in your system
  • Account Data - Information collected about the account owner such as the account owner name, email, etc..
  • Authorization Step - an indicator that the API is being called prior to authorization
  • Device and browsing data, to enable our system to distinguish between legitimate and suspicious signals
  • Payment Data such as Credit card BIN, last 4, expiration date ( Note - Forter is PCI DSS Level 1 Certified and does NOT collect the full credit card)
  • Billing Address details (when applicable)
  • Recipient details such as name, address, phone and email
  • Cart Item Data - details about the goods being purchased. Note some item data will depend on the vertical of the merchant (e.g. travel items contain different data than apparel items)

For more details and code samples please see our Validation API reference documentation.
Depending on your precise industry and use case, we may ask for some extra data points that aren’t in this table, but they’ll all be the same kind of information you see listed here - data points which have an obvious relevance and impact when it comes to making sure you can trust the right customers on your site.

In the case of a Pre-auth integration, Forter can return a decision and a recommendation prior to the PSP/gateway authorizing the payment. In some cases, we may request you make an extra API call post-auth, so we can incorporate the relevant new information from the auth request into our decisions.

Pre-Auth Validation API Response
The API response will contain Forter's decision and applicable recommendations (for example, relating to policy enforcement or 3DS). We may ask your company to make an additional API call post-auth in order to provide an updated decision once supplemental data such as AVS/CVV check and 3DS data are available, as this data can play a helpful role in ensuring accurate decisions. For more details and code samples please see our Order Validation API Reference

Step 3: Order Status API

**Order Status API Request** The Order Status API is used to provide Forter with updates after the initial decision was made in order to provide valuable information to inform our decision models after the order was submitted. It does not provide updated decisions. We use the orderID provided in the Pre-Auth Validation API as the identifier to connect to the original order and ensure orders are tracked seamlessly.

Please see the Order Status API Reference section for more details.

Important data for this purpose includes:

  • Payment Authorization Data - such as the amount authorized, AVS and CVV check results (when applicable), the authorization code, and gateway/processor used and the transaction ID, which can help with chargeback matching (see step 4).
  • Order fulfillment data - most important is to send ongoing updates on the order’s fulfillment status, using both the Forter standardized status types and your company’s free text status.

For more details and code samples please see our Order Status API Reference

Order Status API Response
The response details whether or not the order status update was completed successfully. It will NOT return a new decision.

Step 4: Claims API

The Claims API is used to notify Forter about chargebacks and fraud alerts. This is extremely important because it enables Forter’s system to learn and continually improve future decisions, tailoring our system to your company’s needs.

Additionally, companies who have chosen to take advantage of Forter’s chargeback coverage option also need the Claims API to make sure Forter knows which chargebacks have been submitted and should be reimbursed.

While the Claims API is used to notify Forter about chargebacks, Forter also supports claims webhooks for supported payment gateways including:

  • Braintree
  • PayPal
  • Checkout.com
  • Stripe
  • Adyen

Claims API Request
The Claims API is used to provide Forter with information about chargebacks and fraud alerts in order to improve future decisions (and allow Forter to reimburse covered merchants). The full Claims API Request and Response data can be found in our Claims API Reference.

Key data points include:

  • orderId/matching transaction ID - the ID that corresponds to the original transaction that Forter received
  • amount of the claim
  • claim currency - the currency the claim is generated in
  • reason Code - the code provided by the payment processor (from the list of card scheme codes) to determine if the Chargeback is due to Fraud or Service issues
  • processorChargebackCaseId - the unique identifier of the claim that can be used for disputing it.
  • type of claim (e.g. Chargeback, Fraud alert)
  • additionalCost - any supplementary fees associated with the chargeback
  • status of the claim (e.g. OPEN / WON / LOST)
  • sourceType of the claim (e.g. PROCESSOR_CB) and sourceDetails (e.g. Worldpay)
  • issue date of the chargeback
  • due date to dispute the chargeback

Claims API Response
The response details whether or not the claim was received successfully. Chargebacks will also show on the original transaction in the Forter portal and can be included in relevant claims reporting in the portal as well.

Updated 6 months ago