Skip to main content
CartPresets records one piece of personal data: a redemption row. It’s written when an order containing a preset reaches one of the statuses that count towards purchase limits: on hold, processing or completed by default. On Pro you choose them under Settings → Usage limits. Nothing is recorded while a customer is browsing, and nothing is recorded when they follow a preset link. The row is written at the order, and it’s removed again if that order leaves the counted statuses, so a cancelled order doesn’t leave a claim behind.

​
What is recorded, and why

A purchase limit has to recognise the same customer twice, or it can’t count. Alongside the key, the row holds the preset, the order, and when the claim happened. No IP address is recorded, and nothing else about the person is stored. A developer can change how customers are identified with cartpresets_redemption_customer_key. See the hooks reference.

​
While an order is waiting for payment

A limited preset holds the customer’s slot between checkout and payment. That hold stores a scrambled form of the same key (a SHA-256 hash), never the address itself. It’s gone once the order is paid or cancelled, or after a day at most. The hash can still be matched by anyone who already knows the address, so the erase tool clears it too.

​
Export Personal Data

WordPress’s own Tools → Export Personal Data screen lists CartPresets among its sources. An export returns every preset that address claimed, under the heading Preset claims: An address covers both keys it can have. Somebody who bought once as a guest and later opened an account with the same address is one person, whatever the table says, so you get back the guest rows and the account rows. The account is found by its login email or its billing email, the same accounts a per-customer purchase limit counts.

​
Erase Personal Data

Tools → Erase Personal Data finds the same claims an export does: the address’s guest rows, and the rows of any account whose login email or billing email is that address. It anonymises them rather than deleting them. The customer key is replaced with a value derived from nothing about them. WordPress reports the rows as retained, with a message explaining why.
A redemption row records who claimed a preset, and that the preset was claimed. The first is personal data. The second is stock.
Deleting the row would give a limited run its slot back. A preset capped at fifty could sell a fifty-first, because the record of one sale had gone. One customer exercising their rights would change what another customer can buy. Anonymising keeps the count honest and leaves nothing that identifies anyone. After an erasure:
  • The address is gone from the plugin’s tables.
  • Any hold still waiting on a payment loses its link to the customer, and keeps the slot until the order is paid or cancelled.
  • The claim still counts against the preset’s total limit.
  • The person can claim that preset again, because nothing links the old claim to them.

​
What the tools do not touch

Order line item meta stays. Every preset order line carries the preset’s ID and its name as it was at the time. That’s order history, not personal data: it names a preset, not a person. See Order line item meta. WooCommerce’s own exporters and erasers still handle the order itself, the customer record and any downloads, as usual.

​
Nothing on your storefront

Both handlers register in wp-admin only. A shopper browsing your store never loads them, and the privacy tools add nothing to a front-end request.

​
Uninstalling

Erasing a customer isn’t the same as removing the tables. What an uninstall deletes is a separate, opt-in decision. See Data and uninstall.
Last modified on September 28, 2026