Summary

There are different types of Alerts, or pre-chargeback disputes, and with that, different ways to handle what type of alert should be refunded. Vrio makes it easy to differentiate when processing alerts - should a refund occur from Vrio to the Gateway or not. You can easily define this in the Alert process.

🚧

By default, Vrio will not allow for multiple alerts on a single transaction.

With the adoption of RDR's, Vrio has expanded to allow for additional Alert reporting by allowing multiple alerts on a single transaction. This is an opt-in option for additional alert visibility within the analytics.

📘

Key Takeaways

• A single transaction can have more than 1 Alert Type - through different Risk Management Tools
• Vrio has logic to allow for reporting on multiple Alerts on a single transaction, while blocking multiple refunds
• Alert Refunds can be sent to the gateway from Vrio OR have external refunds
• Pay attention when and if a Refund should go to the Gateway

❗️

RDR transaction data has a day delay

This could allow for an RDR to have occur and an Ethoca to also occur. While Vrio can only add validation logic if the RDR is submitted to Vrio prior to the Ethoca alert, we can provide analytics between both.

*At the time of this article, real time API was not available from Verifi.

Marking an Alert with a Refund

For report and handling best practices surrounding an Alert type where a refund should be triggered to the Gateway, passingrefund_transaction:true and code: {alert provider} will adequately allow for Vrio to handle and report correctly for these alerts.

An alert use case would be that of an Ethoca alert, where the customer needs a refund issued through the gateway.

Utilizing the API - /transaction/{id}/Alert

Request Example:

{
  "date": "",enter the date the alert occurred
  "refund_transaction": true,
  "amount": "",amount to be refunded
  "code": "Ethoca",note - use to notate the Alert Management Type
  "alert_case_id": "",
  "cancel_all_customer_order_offer": true note-only mark true if all active offers should be cancelled  
}

Within the Vrio UI

In Vrio, once you are on the charge transaction, from the dropdown select "Mark as Alert"

Refund Transaction: Check Yes
Date: Set date of the Alert
Code: Enter the alert provider, example: Ethoca

Alert Case ID: Add the case ID of the alert for reference
Cancel all customer order offers: Check Yes

Learn more about Alert marking here.

Marking an Alert with No Refund

For report and handling best practices surrounding an RDR Alert type, passingrefund_transaction: false and code: "RDR" will adequately allow for Vrio to handle and report correctly for RDR alerts.

This is to be used when there is an external refund, outside of the Vrio system. However you still want to track that a refund did occur, although externally.

An alert use case would be that of an RDR alert, where the customer refund is issued outside of the gateway.

👍

Reporting Tip!

Vrio will still record the refund under Alert Revenue across all dispute metrics and reports, even though the refund happened externally.

This gives full visibility on the revenue lost on external refunds and accurate profitability metrics.

Utilizing the API - /transaction/{id}/Alert

Request Example:

{
  "date": "",enter the date the alert occurred
  "refund_transaction": false,
  "amount": "{transaction_total}",
  "code": "RDR",note - use to notate the Alert Management Type
  "alert_case_id": "",
  "cancel_all_customer_order_offer": true note-only mark true if all active offers should be cancelled  
}

Within the Vrio UI

In Vrio, once you are on the charge transaction, from the dropdown select "Mark as Alert"

Refund Transaction: UnCheck = No
Date: Set date of the Alert
Code: Enter the alert provider, example: RDR

Alert Case ID: Add the case ID of the alert for reference
Cancel all customer order offers: Check Yes

Learn more about Alert marking here.

Vrio Validation Opt-In

Vrio has opt-in logic setup to account for multiple alerts that happen to a single transaction. By opting in to this setting, you will now have visibility to see all alert transactions that are happening, without applying duplicate refunds to that transaction.

Why Opt-In

An RDR happens and then an Ethoca alert also happens. Since the Gateway does not know about the RDR there could be double refunding.

We want a way to set logic so there are as minimal scenarios of multiple refunds happening on a single transaction, while also adequately reporting on how often this may occur.

🚧

Beware of timing!

If a RDR comes in to Vrio after an alert that has been refunded, there is no logic that can get in front that RDR.

How to opt-in to Vrio Alert Logic

1. Navigate to Company Profile and check Vrio Alert Management
2. by checking Vrio Alert Management, you will opt in to have Vrio Logic handle multiple alerts

Once opted in, the following logic will apply:

1. /doAlert API call comes in from external resource
2. Vrio will check the following:
   1. Check if refund = True
   2. Check if parent transaction has an existing Alert or Chargeback
   3. If #1 and #2 are true:
      1. Vrio will not issue the refund to the Gateway
      2. Vrio will set the alert transaction total = $0 (for reporting, to not over-report on alerted revenue)

Use Case Examples:

RDR is submitted, then Ethoca

1. RDR will be marked, based on the API logic a refund will not happen within Vrio
2. Ethoca alert will be flagged as an alert, however no refund will be submitted.
3. Vrio will show 2 alerts for this transaction and the Alert Revenue will = that of the RDR Alert Revenue

Ethoca is submitted, then RDR

1. Ethoca will be marked, based on the API logic a refund will happen within Vrio and hit the gateway
2. RDR alert will be flagged as an alert, however no refund will be submitted, as this happens outside of the gateway.
3. Vrio will show 2 alerts for this transaction and the Alert Revenue will = that of the Ethoca Alert Revenue + RDR Alert Revenue