PayU Risk

Reduce your risk of fraud and prevent expensive chargebacks with our risk service.

Online fraud drives the large card networks to enact more regulatory measures to help mitigate potentially fraudulent transactions. To help you to comply with these market requirements, our risk service evaluates the risk probability of your transactions based on the information you collect from your shopper.

Using the Risk Service

The most recommended and straightforward way to use our risk service is within your Create Authorization and Create Charge requests, i.e., as an embedded service. In this scenario, the risk evaluation is performed in the pre-authorization stage, after which PaymentsOS either calls the processing provider or cancels the transaction, according to the risk rules you pre-configured via your Decision Engine. To start using the service, follow these steps:

  1. Add PayU Risk as a Provider.

  2. Configure Blocking Rules Based on Risk Evaluation Result.

  3. Pass the Risk Configuration ID in the Request Header.

  4. Include Mandatory Risk Fields

Step 1: Add PayU Risk as a Provider

Go to Account -> Providers -> ‘PayU Risk’.

Step 2: Configure Blocking Rules Based on Risk Evaluation Result

The risk evaluation we provide is a recommendation only, meaning that you will need to decide whether to act upon it or not— and manually set blocking rules to prevent high risk transaction from being sent to authorization. Note that all transactions are sent to authorization by default, so our recommendation is to block all transactions that receive a ‘Failed’ risk status (See Risk Analysis Results evaluation via the decision engine, as demonstrated in the image below.

Step 3: Pass the Risk Configuration ID in the Request Header

To ensure transactions are reviewed and evaluated, you will need to pass the configuration ID (from your provider configuration) in your Authorization or Charge request header, under the x-risk-provider-config-id field:

x-payments-os-env: test 
api-version: 1.3.0 
x-risk-provider-config-id: 4efe54ff-5956-4df3-a295-b23c17836d21 
private-key: bede7ee5-eaaq-4c9a-bc1f-617ba28256ae 
app-id: com.zooz.docapp 
idempotency-key: AGJ8FJLkGHIpHUTK 

Step 4: Include Mandatory Risk Fields

To run a risk analysis, you will need to include several mandatory fields in your Create Authorization, or Create Charge requests. To generate sample requests that include these fields, use our Bodybuilder and make sure to check the box for Include risk fields before generating the request. Note that this option is disabled for providers where risk assessment is not supported.

Risk Analysis Results

PaymentsOS maps the result of the risk evaluation to one of the following statuses: Pending, Succeed, Failed, or Unreviewed.

  • Pending means that the transaction is undergoing risk evaluation review.

  • Succeed indicates that the transaction is approved and safe to proceed with.

  • Failed means that the transaction is (likely) fraudulent, and you are advised not to proceed with the authorization or charge requests.

  • Unreviewed indicates that the transaction hasn’t been reviewed. Possible reasons might be due to a missing Risk Provider Configuration ID from the request header, due to an API error, or in case of an unsupported Alternative Payment Method (APM).

Webhook Notification of a Risk Status

To get notification when a transaction risk status is created or updated, you can configure webhook notifications via your control center (Account > Webhooks).

Using the Risk Service Separately (as a Standalone)

You can also use our risk evaluation separately— i.e., without performing the risk assessment as part of the Create Authorization or Create Charge requests. When you perform a fraud risk analysis, the result will be a fraud risk score and a recommendation to either approve or reject the transaction. Regardless of how you use the service (standalone or embedded in your PaymentsOS payment flow), the risk analysis is always performed on an initiated payment request, so the first step would be to call the Create Payment API.

You can then initiate the risk analysis for the payment that was initiated, by invoking the Perform a Risk Analysis request for the specific payment ID and passing the customer’s payment method in the request body. Optionally, you can also include a provider_specific_data object with additional_details about the order. Here’s an example:

    var request = new XMLHttpRequest();
    request.open('POST', 'https://api.paymentsos.com/payments/{payment_id}/risk-analyses');
    request.setRequestHeader('Content-Type', 'application/json');
    request.setRequestHeader('api-version', '1.3.0');
    request.setRequestHeader('x-payments-os-env', 'test');
    request.setRequestHeader('app-id', 'com.zooz.docapp');
    request.setRequestHeader('private-key', '0047c4ef-f658-4e6d-a040-5882e2285f34');
    request.setRequestHeader('idempotency-key', 'cust-34532-trans-001356-c');
    var body = {
        {
            "transaction_type": "charge",
            "payment_method": {
                "holder_name": "John Travolta",
                "card_number":"5105105105105100",
                "type":"untokenized",
                "source_type": "credit card"
            },
              "provider_specific_data": { // Optional object for passing more information about the order
                "payu_risk": {
                  "additional_details": {
                    "product_desc_extra1": "product_desc_extra1",
                    "product_desc_extra2": "product_desc_extra2",
                    "product_desc_extra3": "product_desc_extra3",
                    "payer_birthday": "1975/06/30"
                  }
                }
              }
        }
    };
    request.send(JSON.stringify(body));
  
    curl --compressed -X POST \
      https://api.paymentsos.com/payments/{payment_id}/risk-analyses \
      -H 'Content-Type: application/json' \
      -H 'api-version: 1.3.0' \
      -H 'x-payments-os-env: test' \
      -H 'app-id: com.zooz.docapp' \
      -H 'private-key: bede7ee5-eaaq-4c9a-bc1f-617ba28256ae' \
      -H 'idempotency-key: cust-34532-trans-001356-p' \
      -d '{
        {
            "transaction_type": "charge",
            "payment_method": {
                "holder_name": "John Travolta",
                "card_number":"5105105105105100",
                "type":"untokenized",
                "source_type": "credit card"
            }
              "provider_specific_data": { // Optional object for passing more information about the order
                "payu_risk": {
                  "additional_details": {
                    "product_desc_extra1": "product_desc_extra1",
                    "product_desc_extra2": "product_desc_extra2",
                    "product_desc_extra3": "product_desc_extra3",
                    "payer_birthday": "1975/06/30"
                  }
                }
              }
          }
    }'    
  

When to Perform the Risk Analysis

If you use the service as a ‘standalone’, you can choose when to run the risk analysis depending on your own business logic. For example, you could first authorize the transaction and then run the risk analysis, i.e., post-authorization.

However, by performing the risk analysis in the pre-authorization stage, and by running it in the request header as specified here, you are able to stop ‘risky’ transactions before authorization itself, so we highly recommend that you opt for this option.

Last modified October 19, 2022