Privacy Policy

Last updated: November 11, 2026

Brickmoat (“we”, “us”, “our”) is a Shopify app that helps merchants detect fake signups, fake orders, and risky storefront traffic. This policy explains what personal data we process, why, how long we keep it, and how merchants and their customers can exercise their rights.

Brickmoat is operated for merchants who install the app from the Shopify App Store. Our public site is at https://brickmoat.com. Privacy questions: qaisarmughal69@gmail.com.

1. Who this covers

• Merchants — store owners and staff who install and use Brickmoat.
• Merchant customers and visitors — people whose data Shopify sends us so we can score signups, orders, and storefront visits for fraud/bot risk.

2. Data we process

We process the minimum personal data needed to provide fraud and bot protection:

• From Shopify (Protected Customer Data, when approved): customer ID, name, email, phone, shipping/billing address fields used for risk checks, order IDs, and related risk signals Shopify exposes on customer/order webhooks.
• From the storefront: when the merchant has switched on the theme app embed and has visitor rules, the visitor’s IP address, user-agent, referrer and the page path being opened, plus what an IP lookup derives from the address (country, region, city, network / ISP, and VPN / proxy / Tor / hosting flags). Also form-shield outcomes tied to an email when a visitor submits a protected form. Section 3 describes the visitor log in full.
• At checkout: nothing is sent to our servers. The checkout blocklist runs as a Shopify Function inside Shopify (see section 4).
• Merchant account data: shop domain, encrypted Shopify access token, plan / subscription status, and merchant-chosen settings (blocklists, allowlists, watch mode, action toggles).
• Derived risk records: risk scores, reasons (“signals”), tags/actions taken, and short-lived pattern events used to detect bursts and repeats.

We do not collect payment card numbers or government IDs, and we do not track visitors across stores or build advertising profiles.

3. Storefront visitor log

When a merchant uses storefront visitor rules, Brickmoat keeps a rolling log of the decisions it makes so the merchant can see what was allowed, blocked or redirected and why. Each entry holds:

• the time of the visit and the decision (allowed, blocked or redirected);
• the reason and the rule that decided it;
• country, state / region and city derived from the IP address;
• network number (ASN) and ISP name;
• the page path that was requested;
• the referrer’s host and path, without its query string;
• the browser’s user-agent text, shortened;
• the IP address: truncated for visitors who were allowed, and the full address only for visitors who were blocked or redirected, so the merchant can review and undo a block.

Log entries are deleted after 30 days (90 days for shops on the Plus plan, which includes a longer log), and all of a shop’s entries are deleted when Shopify sends shop/redact after uninstall. The log is not linked to customer accounts and holds no names, emails or order details. IP lookup results are cached for up to 2 days so the same address is not looked up repeatedly, then deleted. Merchants can view, filter and export the log as CSV from inside the app; an export is the merchant’s copy to keep and protect.

4. Checkout blocklist

On plans that include it, the merchant’s blocklist can be enforced at checkout by a Shopify Checkout validation Function. To make that possible, a copy of the merchant’s lists (blocked emails, email domains, phone numbers and address fingerprints, optionally blocked countries, allow-listed emails and domains, any checkout conditions the merchant added for a buyer name or an order subtotal, and the error message the merchant wrote) is stored in an app-owned shop metafield inside Shopify. The Function runs on Shopify’s infrastructure, compares what the buyer entered (email, phone, name and delivery address) and the order subtotal against that copy, and either lets checkout continue or shows the merchant’s message. It does not send buyer data to Brickmoat’s servers, no Brickmoat script runs in checkout, and it cannot see the buyer’s IP address.

5. Purposes of processing

• Score new customers and orders for bot / fraud risk and show merchants the reasons.
• Apply merchant-configured actions only (for example tag, unsubscribe, fulfillment hold, or optional Pro cancel/delete). Watch mode scores without changing the store.
• Enforce merchant blocklists / allowlists and the merchant’s storefront visitor rules (IP, country, region, city, network, user-agent, referrer, page, VPN / proxy / Tor), and show the merchant a log of those decisions.
• Enforce the merchant’s blocklist at checkout through a Shopify Function.
• Send events to Shopify Flow or to a webhook address, only when the merchant has set that up (see section 8).
• Run cleanup scans with CSV backup before bulk delete of likely-bot accounts.
• Provide billing, support, security, and Shopify-required GDPR handling.

We do not sell personal data, use it for advertising networks, or use it for unrelated profiling.

6. Legal bases / merchant role

Merchants are the primary controllers of their customer data. Brickmoat processes that data as a service provider / processor to deliver the app’s fraud-protection features under the merchant’s instructions (including Shopify’s Partner and API terms). Merchants are responsible for telling their customers about apps they use, where required by law.

7. Geo-blocking is the merchant’s responsibility

Brickmoat is a traffic and fraud tool. It is not a legal-compliance, sanctions-screening or age-verification product. Merchants choose which countries, regions, networks and visitors to block or redirect, and they are responsible for making sure those choices are lawful where they sell, including consumer-protection, anti-discrimination and geo-blocking rules. IP-based location is approximate and can be wrong or bypassed, so it should not be relied on to meet a legal obligation.

8. Sharing and processors

We share data only with the services needed to run the app:

• Vercel (hosting) — runs the app and handles requests, including storefront visitor checks.
• Supabase (database) — stores the records described in this policy.
• proxycheck.io (IP intelligence) — when a rule needs location, network or VPN / proxy / Tor data, we send the IP address only and receive country, region, city, network / ISP and risk flags.
• Cloudflare Turnstile (optional human check) — only when the merchant adds their own Turnstile keys to the signup form shield. The visitor’s browser then loads Turnstile from Cloudflare, and we send the resulting token to Cloudflare to verify it.
• Shopify — when we call Admin APIs, receive webhooks, store the checkout blocklist copy in a shop metafield, or send Flow triggers on the merchant’s behalf.

Destinations the merchant chooses. On plans that include integrations, a merchant can switch on Shopify Flow triggers and an outbound webhook. Brickmoat then sends event data (for example a blocked visitor’s IP address, country, reason and page path, or a flagged order’s or signup’s ID, score and reasons, or the email on a catch the merchant marked fake or real) to Flow and to the webhook address the merchant entered. Webhook requests are signed with HMAC-SHA256. The merchant is responsible for the service that receives them.

Klaviyo. A merchant on a plan that includes integrations can connect their own Klaviyo account with an API key. Brickmoat then sends Klaviyo the email address on a flagged signup, a flagged order or a catch the merchant marked fake or real, together with the score, the reasons and the Shopify customer or order ID, and can ask Klaviyo to suppress (or stop suppressing) that email address for marketing. Nothing is sent about storefront visitors. The key is stored encrypted, is never shown again, and is deleted when the merchant disconnects Klaviyo, moves to a plan without integrations or uninstalls. Klaviyo processes that data under the merchant’s own agreement with Klaviyo.

Support tickets. When a merchant opens a support ticket inside the app, we store what they write, the replies, and the email address they choose to leave for the answer. Tickets are read only by Brickmoat support, are kept while the app is installed so earlier answers stay available, and are deleted with the rest of the shop’s data when Shopify sends shop/redact after uninstall. If email or chat alerts are switched on for the support team, the text of a new ticket is sent to the alert service used (for example an email delivery service or a team chat tool).

We do not sell or rent personal data.

9. Retention

• Storefront visitor log: deleted after 30 days, or 90 days on the Plus plan. A shop that leaves Plus is trimmed back to 30 days within a day.
• Cached IP lookups: deleted after at most 2 days.
• Signal / pattern events (emails, IPs, phones used for burst/repeat detection): deleted after about 30 days.
• Cleanup CSV backups: deleted after about 30 days.
• Background jobs: a queued signup or order check holds only the fields the check reads (email, name, phone, IP address, address, order number and total), never the full order. Those details are erased as soon as the check finishes; the empty job record is deleted after about 7 days.
• Risk verdicts and list entries: kept while the merchant uses the app so they can review and train block/allow lists; removed on uninstall purge or GDPR redact.
• Shop record / encrypted token: kept while installed; cleared or purged on uninstall / shop/redact.
• Checkout blocklist copy: lives in an app-owned shop metafield inside Shopify, not on our servers. It is rewritten whenever the merchant’s lists change and emptied when the merchant turns the checkout blocklist off.

10. Security

• HTTPS for data in transit.
• Shopify access tokens encrypted at rest (AES-256-GCM) before storage.
• Database hosted with encryption at rest; row-level security enabled with no public policies — only the server secret key can read/write.
• Webhook HMAC verification and Shopify session tokens for admin UI access.
• Storefront visitor checks are sent from the visitor’s browser to Brickmoat over HTTPS and fail open: if a check cannot be completed, the visitor is let through.
• Staff access limited to people who operate the production systems; strong passwords / 2FA on admin accounts.

11. Automated decision-making

Brickmoat automatically scores customers and orders. Depending on the merchant’s plan and settings, that score may trigger tags, marketing unsubscribe, fulfillment holds, or (Pro, opt-in) cancel/delete. Merchants can use watch mode, disable auto-actions, and mark catches as Real or Fake. Customers who want changes to an order or account should contact the merchant store; we do not sell customer data and we do not make credit or employment decisions.

Storefront visitor rules and the checkout blocklist are also applied automatically, using only the rules the merchant has set. A visitor who is blocked or redirected, or a buyer who is refused at checkout, should contact the store, which can review the log and remove or change the rule. Verified search and social crawlers are let through, and a failed lookup never blocks anyone.

12. GDPR and Shopify webhooks

We implement Shopify’s mandatory compliance webhooks:

• customers/data_request — we gather every record we hold for that customer (risk checks on their signup and orders, pattern records, and any block or allow list entry that is their own email or phone) and deliver it to the merchant as a message on the app’s Support page, so the merchant can pass it on. We do not contact the customer ourselves.
• customers/redact — we delete that customer’s risk checks, including the checks on the orders named in the request, their pattern records, any block or allow list entry that is their own email or phone, and any queued work that still carries their details.
• shop/redact — after uninstall, we purge the shop’s data from our systems, including its storefront visitor log.

Visitor log entries are not linked to customer accounts, so they cannot be looked up by customer; they are removed by the 30-day limit and by shop/redact. A person who wants an IP address removed sooner can ask the store or write to us.

13. Children’s data

Brickmoat is not directed at children. We do not knowingly collect personal data from children under 16 for our own purposes.

14. International transfers

Data may be processed in the regions where our hosting providers operate. Merchants who need a specific region should contact us before relying on Brickmoat for that requirement.

15. Changes

We may update this policy. The “Last updated” date at the top will change when we do. Continued use of the app after an update means the revised policy applies to ongoing processing.

16. Contact

Privacy requests: qaisarmughal69@gmail.com
App: Brickmoat on Shopify · Site: https://brickmoat.com