Migrate to Pre-Auth

Overview

Using a pre-authorization flow is a prerequisite for accessing 3DS services. If you are updating your existing Forter integration from post-auth to pre-auth, the are three main changes:

Move the Order API request to an earlier stage

In pre-authorization, call Forter's Order API before calling the PSP for authorization and before executing 3DS, ideally at a point where the routing is already known, so the relevant MID can be provided.

In the Order API request, add the authorizationStep field and include all of the same data as in the post-auth request except the authorization results, since you won't have them yet:

creditCard.verificationResults

tokenizedCard.verificationResults

paypal.paymentStatus

applePay.verificationResults

androidPay.verificationResults

digitalWallet.paymentSuccessStatus

installmentService.serviceResponseCode

venmo.verificationResults

bankTransfer.paymentSuccessStatus

paymentGatewayData or paymentProcessorData

Upgrade to Order v3 (Required for 3DS Execution)

If you are leveraging Forter's 3DS Execution services, you must also upgrade to v3 of the Order API. If your current custom API version does not include Order v3, request an updated version from your Forter Implementation Engineer or utilize the standard version published on this site.

The API request structure is unchanged from v2 to v3, but the API response differs. Be sure to update your handling for each.

Fraud decision in Order response

Fraud decision (APPROVE \ DECLINE \ NOT REVIEWED) is included in the forterDecision field instead of an action field.

{
  "action": "approve"
}

{  
  "forterDecision": "APPROVE",  
}

If you are are guided to retain your post-auth integration while adding a pre-auth integration (i.e. receive fraud decisions both before and after authorization), you should take into account the post-auth decision only in the event of successful authorization. If payment was authorized but Forter decision was DECLINE, you should void the authorization.

3DS recommendation in Order response

3DS recommendation (VERIFICATION_REQUIRED_3DS_CHALLENGE) is included in the recommendation string field, instead of the recommendations array.

{  
  "action": "approve",  
  "recommendations": ["VERIFICATION_REQUIRED_3DS_CHALLENGE"]  
}

{  
  "forterDecision": "APPROVE",  
  "recommendation": "VERIFICATION_REQUIRED_3DS_CHALLENGE"  
}

PSD2 exemption in Order response

PSD2 exemption recommendation (REQUEST_SCA_EXEMPTION_*) is included in the recommendation string field, instead of the recommendations array.

{  
  "action": "approve",  
  "recommendations": ["REQUEST_SCA_EXEMPTION_TRA"]  
}

{  
  "forterDecision": "APPROVE",  
  "recommendation": "REQUEST_SCA_EXEMPTION_TRA"  
}

3DS execution in Order response

The v3 response will include the managedOrderToken field. Continue with the integration guide for 3DS Execution.

Send payment authorization details

You can streamline the process of sending payment authorization updates by creating a webhook notification from your payment processors that they will send directly to Forter. Forter can accept payment webhook notifications from Adyen, Primer, and Worldpay.

For all other PSPs, send an update via the Order Status API that includes the verificationResults object with all values from your processor including 3DS results. Also include an updated status for the order with this request. When the authorization succeeds, updatedStatus: “PROCESSING”. When the authorization fails, updatedStatus: “CANCELED_BY_MERCHANT”.