Rate Limits

This document talks about two different types of rate limit that Ravelin applies, and also about rate limits that Ravelin merchants should apply to customer actions.

Ravelin Rate Limits

Ravelin imposes both per-merchant and per-merchant-customer rate limits as described below.

Per-merchant rate limits

Ravelin is designed to process high volumes of merchant data in real time. We can easily process all the data you send to us at peak times and still respond quickly. But we do need to apply rate limits to protect our service for all our merchants if one merchant sends an unreasonable burst of data.

Our intention is to set rate limits at levels where they will not normally be hit. The rate limit for normal traffic is 3000 requests per minute. For backfill requests, the default rate limit is 6000 requests per minute. The rate limit for sandbox traffic is 300 requests per minute. Rate limits can be raised if necessary. Rate limits do not apply to requests made from the dashboard.

When the limit is hit we return a 429 response. If we do return a 429 then we still retain and process the data you have sent. We put the request on an internal queue and process it when demand is lower. This means that the data in the dashboard, and the data used for subsequent fraud scoring will be complete. There is no need to retry your request from this point of view.

If you set score=true on the request then we recommend that you treat the response as if Ravelin is uncontactable (so either allow the transaction or apply 3DS depending on your internal policies). We do not recommend you retry the request as this will likely extend the period of rate limiting. Please consult our guide on handling errors for more detail.

Per-merchant-customer rate limits

Ravelin also imposes a per-customer rate limit of 50 events per minute, per CustomerID. We’ve set this at a level that only badly-behaving customers should reach, so we only expect this limit to be triggered in the event of a customer that is deliberately behaving badly or where there is a bug in the integration.

When this limit is hit we return a 200 response with action set to PREVENT and source set to RATE_LIMIT. We do not retain the data from the request in this case. Please do not retry sending the data. If you hit this condition please investigate why the customer is generating so many events and contact us so we can resolve the situation.

The customer rate limit does not apply to backfill data.

Merchant Rate Limits

There are a number of rate limits that any company should apply to its customer traffic in order to safeguard itself, its customers and the wider community.

Account creation

Impose a per-IP address or per-device limit on account creation to mitigate against automated creation of new accounts. If a fraudster can create a large number of accounts they can submit large numbers of fraudulent orders without any individual account appearing fraudulent.

Login

Impose limits on logins. As well as limiting logins per IP address and/or device it also makes sense to limit logins by user ID to mitigate against distributed password enumeration attacks. These are attacks where the fraudster tries to login with the same user ID from a large number of different machines, and tries different passwords from each machine.

Card validation

Don’t allow users to validate too many credit cards. Fraudsters may exploit this to discover valid card details by enumerating through a set of possible combinations. Even if the user doesn’t go on to submit an order, they may use the validated details on another site or with another identity. In particular, be careful allowing anonymous users to validate cards. This can be used as a free card-checking service by nefarious actors.

Orders

Every merchant loves orders. But there’s a point where the number of orders from a single customer is not believable. In particular you should not allow a customer to generate multiple orders by simply pounding on a button. Fraudsters will attempt to exploit this by sending in orders as fast as possible in the hope that something will fail and one of the attempts will be allowed through. You can mitigate against this by waiting for the first order to be fully processed before re-enabling the button for the next order.