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 imposes both per-merchant and per-merchant-customer rate limits as described below.
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 service auto-scales to meet demand, and therefore our per-merchant rate limits also adjust automatically. We will only block traffic if it increases faster than our system can scale. If that does happen we will drop traffic from merchants whose traffic has increased faster than our scaling models allow for. Merchants whose traffic has increased at reasonable rates should be unaffected.
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 requested a recommendation then you should 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.
Rate limits do not apply to requests made from the dashboard.
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.
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.
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.
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.
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.
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.
Was this page helpful?