Verifi RDR Merchant Hosted Decision API
Frequently Asked Questions
Previously, the only way merchants decided RDR case outcomes was to use pre-configured rules on the Verifi Decision Engine, e.g., based on transaction amount or dispute category. In contrast, the new Decision API allows merchants to decide RDR case outcomes using their own internally developed decision engine, obviating the need for Verifi’s pre-configured rules. This allows merchants to be more sophisticated and bespoke in their decision logic. It also allows merchants and resellers to self-serve, so they do not need to rely on Verifi client support to set up or modify rules for them.
Decision API is a good option for:
- Resellers who prefer not to have Verifi manage the RDR rules for them.
- High-volume, low-risk merchants whose pre-dispute strategy is not to accept all RDR cases; rather, they have the desire and the ability to build a more sophisticated decision logic. Decision API lets data from the merchant’s own system factor into the RDR decision. For example, they may decline cases:
- Where the disputed transaction has already been refunded.
- Where the goods/services have already been delivered.
- Where they detect the dispute could be won, if represented (say, because they detect it is friendly fraud).
- Based on customer/cardholder history.
Both resellers and direct clients may use the API. The primary benefit for resellers is that Decision API eliminates the need to rely on Verifi Client Support to create and modify RDR rules; however, Decision API doesn’t eliminate the need to engage with Verifi Client Support to onboard clients, enroll BIN/CAIDs, etc.
Merchants like this are a better candidate for the Notifications API, which is a separate set of functionalities from the Decision API. The Decision API is meant for merchants who seek more bespoke rules than Verifi’s RDR rules allow, and data privacy from 3rd party vendors.
With Notifications API, merchants receive an RDR notification and respond to what the outcome should be. The merchant platform knows that the consumer was trying to dispute, and the outcome based on their automated response. Notifications API conveys this information directly, rather than SFTP data extract, which is a day behind. This information is very valuable in specific use cases such as pausing subscription access for the customer.
No, RDR cases are billed at the same rate regardless of Decision Source.
As a rule of thumb, a reseller/merchant’s decision engine is a black box to Verifi, so Verifi has limited ability to help troubleshoot. With Decision API, Verifi will not have access to know what a reseller/merchant’s decision logic is, so Verifi cannot evaluate whether the logic makes sense or is “correct”. This allows for greater merchant privacy. In certain cases, Verifi may be able to provide some assistance, but as a general principle, the way a reseller/merchant’s decision engine is up to them.
Relatedly, if a merchant using the Decision API has a high case decline rate (where those cases have the general decline status code 957), Verifi will have no way of knowing whether that is intentional or instead a mistake.
RDR is part of the existing synchronous Visa dispute flow. VROL (Visa Resolve Online – Visa’s dispute processing platform) maintains its own VMPI timeout threshold for PREVENT, RESOLVE, and INFORM, and Verifi must work within those parameters.
One technical approach some merchants may consider in order to ensure they meet the response SLA is to “pre-register” an RDR decision for each transaction in their system, which indicates, “if this transaction receives an RDR case, we will accept/decline the case”. This way, they do not need to decide on each case in real-time.
In this scenario, Verifi will time out the Decision Response. The RDR case will be set to:
- Outcome = Declined
- Status = Closed
- Status Code = 910
- Is_Filtered = False
With Decision API, timed out cases will be included in the Partner’s RDR Daily Extract. So, if a merchant’s Decision Response was timed out, they will find that out the next day via the extract, by seeing the case with Status Code 910. Verifi will also have internal reporting on system performance which will indicate when Decision Responses are being timed out.
After March 2025, the response time SLA is increasing to three seconds.
There is a (very small) number of timeouts that happen even with the Verifi hosted decision engine for RDR. Merchants are encouraged to pick the option for decisioning that best suits their business.
No, not at this time. If a merchant does not respond in time, the case is thereby declined.
VROL only gives Verifi a limited window of response time. At this time, it is not feasible to wait for the merchant to time out and then process the case via a backup rule because both steps would need to happen within the timeframe allotted by VROL.
Verifi will monitor Decision API clients for chronic response time timeouts to catch issues if they arise.
Yes. Merchant’s can set rules are to accept RDR cases under a certain amount across multiple currencies.
With the Verifi hosted decision engine, merchant can specify up to 10 currencies, since each merchant can have only 10 rules.
With the Decision API, the decision logic/rules are entirely up to the merchant.
Customers would have access to the same reports that they have had access to historically. And in particular, they may still opt to receive the RDR Daily Extract via SFTP.
Rules-based RDR allows rules based on (any combination of) these attributes:
- PAN First 6
- Transaction date
- Authorization datetime
- Transaction amount
- Transaction currency
- Purchase identifier
- Dispute category
- Dispute condition code
With the Decision API, we send the merchant each case, which contains 29 attributes (the ones above, plus many others). On top of that, the merchant has transaction attributes only available in their own systems (e.g., shipping/fulfillment status, refund status, cardholder history, etc.). The merchant can create a decision algorithm based on any combination of all of these attributes.