Risk Engines

Risk engines are provided by Payment Service Providers (PSPs) or Independent Risk Engine Providers. We recommend looking directly at their appropriate documentation for more information.

BR-DGE supports both providers depending on your preference and BR-DGE REST API is designed to support multiple risk engines - please get in contact with support to align with your chosen integration.

Risk Engines Provided by PSPs

A PSP will only provide value for payments routed to this single PSP, so if a PSP fails the transaction that will be the end of that transaction.

PSP Integrated One-Step Risk Engine

1. You make a payment request using POST /v1/payments or using the Hosted Payment Page. If a payment is routed to a PSP with a one-step risk engine, then it will decide to proceed or decline the authorization due to risk.

The 4260 response code will be returned whenever payment is declined due to high risk.

PSP Integrated Two-Step Risk Engine

It is best practice to use a two-step risk engine as you will get a higher confidence level in your decision and most PSPs will use this model. The first step allows the PSP to ingest required data from the customer's checkout flow. The second step provides the PSP with the transaction data and risk instrument to complete the payment. The above diagram describes the flow, where:

1. The PSP will likely provide you with a device data collector library to run on your app, which will output a risk instrument you can include in BR-DGE payment requests.

2. You make a payment request with the risk instrument generated in step 1 via BR-DGE using POST /v1/payments. We recommend looking at the appropriate PSP documentation to ensure you provide any PSP-specific elements, you can also see more information in the riskInstruments object in the Body Params section of POST /v1/payments.

The 4260 response code will be returned whenever payment is declined due to high risk.

Risk Engines Provided by Independent Risk Service Providers

Independent One-Step Risk Engine

1. You make the payment request using POST /v1/payments or using the Hosted Payment Page. BR-DGE will then query the Independent Risk Engine. If the transaction passes the risk checks, BR-DGE will proceed and call the PSP.

You can see more information on your response on the Response Codes page.

Independent Two-Step Risk Engine

It is best practice to use a two-step risk engine as you will get a higher confidence level in your decision. The first step allows the independent risk engine solution to ingest required data from the customer's checkout flow, and the second step is mirroring the data to the independent risk engine solution to complete the payment. The above diagram describes the flow, where:

1. The risk engine will likely provide a device data collector library for you to run on your app, which will output a risk instrument you can include in BR-DGE payment requests.
2. You make the payment risk request via BR-DGE using POST /v1/payments.
   Make sure to provide the risk instrument in the RiskInstruments element.
3. BR-DGE requests the independent risk engine provider so they can make their decision separately. The independent risk engine provider returns the result to BR-DGE, if the transaction passes the risk checks we pass the transaction to the PSP and complete the transaction.
4. When the transaction is complete, you will receive a response containing either a success or failure, see more information on the Response Codes page. We may also send the transaction outcome to the independent risk engine provider.