Sin impuesto Con impuesto
RKR Purchase Limits: Purchase limits per customer against resellers and hoarders

RKR Purchase Limits: Purchase limits per customer against resellers and hoarders

€108.78
First year:€108.78tax incl.
From the second year:€27.20/yeartax incl.
  • One year of technical support and lifetime updates; from the second year, support is extended for €27.20/year and includes taking on your general improvement ideas for the module.
  • Renews automatically; cancel whenever you want, with no minimum term.
One-time payment:€108.78tax incl.
  • One year of technical support and lifetime updates; after that, support ends (with the subscription it is extended for €27.20/year).
  • A single payment, with no automatic charges.
€89.90 + VAT = €108.78

Set a maximum number of units per customer , either in total or per set period, and ensure it's strictly enforced: tally all orders from the moment they're placed (including bank transfers, cash on delivery, and pending payments), update the shopping cart on the server, and detect duplicate accounts. Ideal for launches, limited editions, and offers where you don't want a single buyer to claim all the units. Rekire module, tested in real stores.

Compatible with PrestaShop 1.7.8 to 9.x, with PHP 7.2 or higher.

Try the demo

Front officeBack office

Anti-resale and anti-hoarding

Make sure your launch reaches many customers, not just one reseller.

You release a limited edition or a special offer, and within minutes someone buys up all the stock to resell it. RKR Purchase Limits It sets how many units each customer can buy, in total or at certain times, and enforces this in the shopping cart and when validating the order.

4 modes
block, only notify, reduce the cart to the maximum allowed, or hide the purchase button
Every 30 days
or every N days, weeks or months, or in total: one rolling window per customer, not a permanent cap
1.7.8 → 9.x
a single version of the module for all your stores, with PHP 7.2 or higher and six languages

/ The limit is met, it cannot be circumvented

They count all orders, from the moment they are placed.
A customer cannot place five orders without paying to circumvent the limit: bank transfers, cash on delivery, and pending payments are all counted from the start. Only canceled orders, orders with payment errors, or refunded orders result in the return of units.
The shopping cart is being corrected on the server
It doesn't depend on the browser recognizing it: it also corrects itself in one-click purchase modules, one-page checkouts, and when repeating an order.
A final check when validating the order
If an order slips through a path that the module doesn't see coming (two tabs, an express payment), it goes to the "Purchase limit exceeded - review" status, with a private note and an email notification so you can decide.
If you return it, you get your quota back.
Cancellations, returns, and partial refunds free up the corresponding units, so you don't penalize those who actually return items.

/ Rules tailored to each product

By product, combination, category, manufacturer or supplier
"2 watches every 30 days" for an entire category, or a limit only for one size or color.
Exceptions that replace the rule
Your limited edition may have 1 unit per customer even if its category allows 2: the product exception takes precedence over the general rule.
You choose how the store reacts
Block and explain, warn without preventing, lower the amount to the maximum allowed, or hide the button when you can no longer buy more.

/ Guests and duplicate accounts

Buying without an account is not a shortcut
Guest orders from the same email address are combined. You can also apply the IP limit within a window, or require an account only for limited products.
Detects duplicate accounts
Compare email, phone number, address and IP, and you can share the quota between similar accounts, only register them or activate strict mode, which requires that two different types of data match.
Designed for GDPR compliance
Identity traces are stored as salted hashes, not as plaintext data.

/ The customer sees it before hitting the limit.

Sticker showing the number of units remaining
In the listings, on the miniature, with its position to choose from nine.
Notice on the product page and in the shopping cart
It tells you how many units you can buy, how many you've already bought, and when it will be available again. The text is yours, in each language.
24 visual themes and editor
Choose one that matches your store or adjust colors and borders in the editor. The brand one. Rekire It comes as standard.

/ And to work with him every day

Statistics
A panel with indicators, graphs, and tables to see which limits are triggered and by how much.
AI assistant, optional
It helps you write the rule texts. It's optional and requires your own key from your chosen provider; the module works just as well without it.
Multistore and six languages
Panel and emails in Spanish, English, French, Italian, German and Portuguese, with configuration per store.

/ Try it before you buy it

The demo includes a watch category with a "2 every 30 days" rule and a limited-edition watch with 1 per customer. Sign up as cliente.limites@example.com with the password RkrDemo123!: You already bought 2 watches 12 days ago and can't add any more until 30 days have passed. Demo: demo.https://rekire.com/gb/module/rkrtotaltranslator/urlstranslation.

/ What you should know

A limit per customer reduces bulk purchases, but it doesn't reliably identify an individual: someone using different data, emails, and connections for each order can evade detection. That's why the module alerts you and lets you review suspicious orders instead of making the decision for you. The module doesn't replace your store's terms and conditions: if you limit quantities, it should be clearly stated there.

Compatible with PrestaShop 1.7.8 to 9.x, with PHP 7.2 or higher

Developed and maintained by REQUIRE

  • Reference
    rkrpurchaselimits

v1.2.1

  • Product page with a limit in debug mode: a PHP notice ( Undefined index: id_cart ) stopped the page with an error 500 when PrestaShop's debug mode was on. With debug mode off the page already worked; the limits themselves do not change.

v1.2.0

Full review of the quota engine: the limit now holds in the real life of a shop.

  • Every order counts from the moment it is placed. Bank wire, check, cash on delivery and pending card payments used to be ignored until paid, so a customer could place several unpaid orders over the limit. Only cancelled, payment errors and refunded orders give the units back.
  • Last check when the order is placed. Whatever path the cart took (one page checkout modules, express payments, two tabs), an order over a blocking limit gets a private note, the merchant alert and the new state "Purchase limit exceeded - review".
  • The cart is corrected on module pages too (one page checkouts, one click buy, re-order), not only on the core cart and checkout pages.
  • Partial returns and refunds release their units (the hook parameters were wrong, so nothing was released), and a later state change no longer wipes them.
  • Per combination limits no longer block when several combinations are in the cart; a combination rule only applies to its combinations.
  • Product exceptions replace the general rules of the product (they could only make the limit stricter).
  • Guests: guest checkouts with the same e-mail add up, the IP modes really count the orders placed from the same connection, and "require an account" only affects limited products.
  • Duplicate accounts: strict mode (two matching identity types) on by default, Gmail-only dot normalization, the IP match window and "warn only" now do what they say.
  • Orders edited in the back office update the counters; orders placed before the module are counted only in valid states.
  • Merchant alert e-mail actually sent (templates per language in mails/ ), in the shop language, at most one per product and hour.
  • Multistore: no SQL error on product names, default configuration for every shop.
  • Back office in English, Spanish, French, Italian, German and Portuguese; menu tabs translated; period shown as "every 30 days" / "in total".
  • Security: messages through the core HTML purifier, custom CSS without markup, AI links only to public HTTPS hosts and without redirects, import goes through the same filters.
  • Clean-up for the PrestaShop Addons validator: AFL-3.0 license, no Context:: , $_GET or deprecated calls, Smarty without raw nofilter , PrestaShop coding standards.

4 other products in the same category

Questions and answers

Nobody has asked anything about this product yet.

Cookie consent
Back to top