Privacy Policy

2. Information we collect

We collect information you give us, information the platform generates as you use it, and information our payment providers return to us about a payment.

• Account and profile: your name, email address, phone number, business name, job title, time zone, language, and profile picture.
• Credentials and account security: your password is stored only as a cryptographic hash, and we keep hashes of your previous passwords so that when you change your password you cannot pick one you have used before. We also store your two-factor settings and whether your email is verified.
• Sign-in and device records: every sign-in attempt is recorded with the IP address, browser user agent, and device details, along with whether it succeeded and whether two-factor was used. Security audit records add a risk score and, where a lookup is configured, an approximate location. To recognise a device you have signed in from before, we store a fingerprint derived from your browser and device (not your IP address), with its browser, operating system and device type and when it first and last signed in.
• Request records: every request your browser or the BuyVerse.ai app makes to our API is written to a request log with the time, the method and the address requested (including anything in it, such as what you searched for), the response status and how long it took, a request identifier, your IP address, your browser's or the app's user agent, your account identifier when you are signed in, and, when the request comes from the app, the app’s version and its platform (iOS or Android). When our own web server makes a request while it builds a page for you, the log records your IP address and also names that server. Some of our services also log, for every request they handle, the method, the route (its pattern, not the address you requested), the response status, how long it took, how many query parameters it carried (not what they were) and the user agent. We keep these logs to keep the service secure, to detect and investigate abuse, and to find and fix faults. They are not sent to a logging service and are not part of our backups: they stay in the log files of the server that runs BuyVerse.ai, where each service keeps at most five files of ten megabytes each and overwrites the oldest as it writes new ones. (A request that fails because of an error on our side also produces an error report, which is separate and carries less; it is described under "Analytics and error tracking".) That limit is on size, not age, so how long a line lasts depends on how much traffic there is; nothing deletes these logs on a time schedule, and when traffic is light a line can last a long time. When a request is made with a business's API key, or by a signed-in member of a business, we also store a usage record in our database — the route, the method, the response status, the time taken and whether it succeeded, against that business and, if one was used, the API key — so that the business's API usage can be counted; it holds no IP address or user agent.
• Marketplace activity: your listings, orders, bookings, messages, invoices, ratings, disputes, and the trust signals calculated from them.
• Shipping details: the delivery name, company, street address, city, state, postal code, country, and phone number on an order, so a label can be bought and the shipment tracked.
• Verification documents: files you upload to verify your business. They are reviewed by BuyVerse.ai staff — we do not send them to a third-party identity-verification provider. Sellers who enable payouts complete a separate identity check with our payment processor; that is described under "How we share information".
• Payment details: we never store a full card number. A transaction keeps the card brand and last four digits only. A bank account number is stored encrypted, alongside the routing number and last four digits. Tokens for a connected payment account are stored encrypted.
• Connected calendars: if a seller connects a calendar, we copy the events already in it — their titles, descriptions, locations, and times, from 30 days ago to 90 days ahead — into BuyVerse.ai, so that a booking can be checked against them for conflicts. That copy is not limited to BuyVerse.ai bookings: it is whatever is in the connected calendar, including entries that have nothing to do with this platform.

3. How we use information

We use personal information to run the marketplace, to keep it secure, and to meet our legal obligations.

• Operate the marketplace, dashboards, orders, bookings, and messaging.
• Calculate trust scores, verification status, and fraud-risk signals, and show them to counterparties.
• Process payments, payouts, escrow, and plan billing.
• Buy shipping labels and track shipments.
• Detect and investigate fraud, abuse, chargebacks, and security incidents.
• Send service notices and security alerts. We record a separate marketing preference; see "Marketing" below for what that currently does.
• Comply with legal obligations and enforce our terms.

4. BuyVerse.ai and AI

BuyVerse.ai does not send your data to a generative AI provider. The platform has no outbound connection to any such service.

What BuyVerse.ai does offer is the opposite direction: you can connect an external AI assistant of your own — for example one you already use — so that it can act on your BuyVerse.ai account on your behalf. If you set that up, you are the one choosing that assistant, and what it does with the data it reads is governed by its own provider's terms, not by this policy.

That cuts both ways, and the first sentence above should not be read as a promise about the other party to your transaction. A business you buy from can connect an assistant of its own, and what that assistant can read includes the business's transaction and quote records — which are records of the people who transacted with it. You did not choose that assistant, we cannot name it here because we do not know which one a given business connected, and once records reach it they are governed by its provider rather than by us.

5. Legal bases for processing

Where the law requires a legal basis — for example under the GDPR — we rely on performance of our contract with you, our legitimate interests in operating a trusted marketplace and preventing fraud, your consent where we ask for it, and compliance with legal obligations.

6. How we share information

We do not sell your personal information.

We share it with the other party to a transaction, to the extent the transaction requires it, and with the service providers the platform is built on. Each provider below is used only where that function is switched on for this service, and each receives only what that function needs. Several of them are reached only because a seller chose to connect their own account, or because an operator supplied an endpoint; where that is so, the entry says it. This list is built from the code rather than kept by hand, and a build check fails if the product is wired to a recipient this section does not name. The list is grouped by purpose:

• Payments and card processing: Stripe, PayPal, and Square. They receive the payment details and the identifiers needed to take, refund, and reconcile a charge. Sellers who enable payouts complete identity and payout onboarding on Stripe-hosted pages, and give Stripe the identity information Stripe requires for that. Stripe's own script also loads in your browser on our checkout and inside the checkout widget on a seller's website, so Stripe sees the page a payment is made on.
• Payouts and banking: Wise, for cross-border payouts; Plaid, where you link a bank account; and Circle, where a stablecoin settlement is used. They receive the account and identity details needed to move or verify funds.
• Shipping and carriers: EasyPost, which we use to buy labels and to track shipments, and through it the carrier that carries the parcel — UPS, FedEx, USPS, or DHL. They receive the full delivery details on the order: name, company, street address, city, state, postal code, country, and phone number. A tracking link we show you goes to that carrier's own tracking page. For a carrier outside those four we show the tracking number as text with no link, rather than handing it to a search engine.
• Email: Resend. Where Resend is not configured for a deployment, email is sent through an SMTP relay instead. Either way the recipient address and the content of the message are passed to the sender.
• Text messages and push notifications: Twilio for SMS, which receives your phone number and the message; and Expo for push, which receives your device token and the notification content. Expo hands that on to the operating system’s own push service — Google Firebase Cloud Messaging on Android, and the Apple Push Notification service on iOS — so each of those receives it too. Our mobile app gets that token from Expo, the framework it is built on: on a phone where you are signed in and push is switched on in the app’s settings (it is on until you switch it off), the app asks your permission to send notifications, and once you allow them it asks Expo for the token and registers it with us, together with the phone’s platform (iOS or Android) and the app’s version. It asks for no token on a simulator or after you decline notifications, and when you sign out or switch push off in the app it asks us to remove the token it registered from our records.
• File storage: an S3-compatible object storage provider — Amazon S3, or a compatible service such as Cloudflare R2, depending on how this deployment is configured — for uploaded images, documents, and message attachments.
• Social sign-in: Google, Microsoft, or GitHub, if you choose to sign in with one of them.
• Accounting, point-of-sale and inventory systems a seller connects: QuickBooks, Xero, FreshBooks, Wave, Square, Toast, Clover, Shopify, MarketMan, BlueCart, and an inventory API of your own if you point us at one. Connecting one authorises BuyVerse.ai to act on that account: we read purchase, order, and stock records out of it and can write stock levels back. Square and Shopify appear here as well as above because a POS connection is a second, separate authorisation from the payment one. Which system a seller connects is their choice; the account it reaches is theirs.
• Calendars a seller connects: Google Calendar, or Microsoft Outlook through Microsoft Graph. When a booking is made we create an event in that calendar. Unless the seller wrote their own note, the event carries the service name and the order number in its title, and the words "Service booking for" followed by the buyer's first and last name in its description. The connection also reads back: we copy the events already in that calendar — their titles, descriptions, locations and times, from 30 days ago to 90 days ahead — into BuyVerse.ai so we can spot booking conflicts. An event we have written into a calendar stays there; erasing your BuyVerse.ai account does not reach it, and the seller has to remove it themselves.
• Any endpoint a seller registers as a webhook: a business can register up to twenty HTTPS endpoints and choose which events go to them. An order event carries the order id, order number, status, order total, and the buyer's account identifier. Booking, payment, review, and trust-score events carry the equivalent identifiers. We do not control who operates those endpoints; the seller who registered them does.
• Storefront platforms, where a seller installs the BuyVerse.ai widget on their own shop: Shopify and Wix. Installing exchanges an authorisation code with that platform. Nothing about a buyer is in that exchange; what comes back is permission to act on the seller's shop.
• Logistics, fleet and freight services, where an operator has configured them: DAT, for lane rates — it receives the destination city of a real order's shipping address; and ShipBob, Samsara, Motive, and WEX, which we read warehouse, fleet, and fuel-card data out of. What we send those four is the credential; the personal information moves the other way, into BuyVerse.ai.
• Address and location lookup, where a deployment has configured an endpoint for it: a geocoding service, which receives a delivery address so it can be turned into coordinates for route and delivery planning; and an IP-geolocation service, which receives the IP address of a sign-in so a security record can name an approximate location. Neither has a provider built into the product — each is whatever endpoint an operator supplies — so we cannot name one here, and neither runs at all when none is supplied.
• Product analytics and error tracking: PostHog and Sentry. What each receives, and from where, is set out under "Analytics and error tracking" below.
• Law, regulators, and safety: we also share information where the law requires it, or where it is necessary to protect rights and safety.

7. Analytics and error tracking

Two providers outside BuyVerse.ai receive information about how the service is used, and both are switched on for this service today: PostHog, for product analytics, and Sentry, for error tracking. Each runs only where its configuration key is supplied to a deployment, and both keys are supplied to this one.

PostHog. On our website, and only after you have accepted the analytics category in our cookie banner, your browser sends PostHog an event when you do certain things there — for example viewing a product, a deal or the business directory, running a search, applying a filter, or taking a step in creating an account. Each event carries the time, the full address of the page you were on (including anything in it, such as what you searched for), the details of the event itself (for a search, the words you searched for and how many results came back), and a random identifier that your browser creates for this purpose and keeps in local storage as bv.analytics.did, so that events from one browser can be grouped together. Events are filed under that identifier rather than under your account. The events a seller's browser sends while the seller sets up its business's AI agent or its checkout widget also carry the identifier of that business. Until you accept analytics nothing is sent and the identifier is not created; if you refuse analytics, or later withdraw it in the cookie preferences, nothing more is sent and the identifier is deleted from your browser. As with any server your browser connects to, PostHog receives your IP address with each event. Our servers send PostHog nothing, and neither does the BuyVerse.ai app.

Sentry. When a request fails because of an error on our side, or an error escapes the code that should have handled it, our servers send Sentry an error report. It carries the error's type and message and its stack trace, with long, token-like strings masked; which service it happened in; for a failed request, the pattern of the route rather than the address you requested, the request method and the response status; and, when the request came from the app, the app’s version and its platform. It does not carry what you sent, your IP address, your user agent or your account identifier. On our website, when an error on a page is not handled, or a page fails and shows its error screen instead, your browser sends Sentry a report with the error's type, message and stack trace, which part of the website caught it, the pattern of the page's route rather than the address you visited, and, when the error happened on our server, the reference number the error screen shows you; as with any server your browser connects to, Sentry receives your IP address with it. That report is a diagnostic, not analytics, so it is sent whatever you chose in the cookie banner, and the website's error reporter stores nothing in your browser: no cookie, and nothing in local or session storage.

The BuyVerse.ai app contains Sentry’s crash reporter. It runs only in a release build of the app that carries a Sentry key, and never in a development build. It sends Sentry a report when the app crashes, freezes, is stopped by the phone’s system, or meets an error. A report carries the error, its stack traces and the time it happened. It describes the phone: its make and model, its operating system and version, and its processor. It gives the phone’s memory and storage and how much of each is free, its battery level, whether it is charging, and how warm it is running. It gives the screen’s size, resolution and orientation, when the phone last started up, its language, region and time zone, its clock and calendar settings, and its type of network connection. It says whether the phone is an emulator, or has been rooted or jailbroken. It describes the app: its name, version and build, how it was installed, when it started, how much memory it is using, and whether it was on screen. It names the over-the-air update the app is running, when that update was published, its channel and runtime, and how the app loaded it. It lists the versions of the software the app is built with and, on Android, the permissions the app holds. It carries a short trail of what the app did just before: its recent log lines, the screens it showed and their titles, and what you tapped, with a button’s label where it has one. The trail also shows when the app moved to or from the background; changes to the network connection, with its type, speed and signal strength and whether a VPN is on; and system events, such as low memory, a battery change, the screen turning, the keyboard opening, a screenshot being taken or a change of time zone. It shows the errors the app reported just before, and each recent network request with its method and result, and its address cut off before any question mark or hash sign. The reporter also tells Sentry about each session of use: when it began, how long it lasted, how many errors it had, and whether it ended normally, in a crash, or was cut short. It tells Sentry, too, how many reports it could not send, and why. Reports and sessions are filed under a random identifier that the reporter creates for this installation of the app. On an iPhone, a report also carries a one-way code made from the identifier the phone gives our app. No account identity is attached: not your name, your email address or your account identifier. As with any server the app connects to, Sentry receives your IP address with each report, and it is set not to store it.

Whether each provider runs is a deployment setting rather than a change to the product, so we will not promise it cannot change without you noticing. What we commit to is that this section is updated whenever one is switched on or off, or what it receives changes.

8. How long we keep it

No retention policy is configured for this service today, so nothing is deleted or anonymised on a time-based schedule simply because it has aged. Personal information is retained until you delete your account, or we remove it for another reason. We are not stating a fixed retention period per record class, because we do not yet enforce one and we would rather say that than publish a period we do not keep.

Request logs are limited by size rather than by age, as described under "Information we collect": the oldest lines are overwritten as new requests arrive, not deleted after a set number of days.

Deleting your account is not a schedule: it happens straight away, as described below. One schedule does run: where a business is closed, its catalog — products, services, deals, and connected agent records — together with the internal records created when the business was closed are purged after a retention window that defaults to 90 days and is configurable for the deployment. That purge is deferred while the business still has an open order, booking, invoice, payout, escrow hold, active service subscription, or an undisbursed balance.

Records connected to orders, payments, and disputes are kept after you delete your account so the transaction history stays intact for the other party and for accounting purposes. Exactly what a deletion removes, and what it keeps, is set out next.

9. Your rights and what we can actually do today

Depending on where you are, you may have rights to access, correct, delete, port, or restrict the processing of your personal information. Here is what the product supports right now, right by right, so you can tell the difference between a right you have and a button that works.

• Correct: you can edit your name, contact details, and profile from your account settings at any time.
• Delete your account: this deletes your account straight away, and it is the same deletion whether you do it in the BuyVerse.ai app (More, then Settings, then Delete account), on the web (Settings, then Profile and sign-in, then Delete account), or by asking us at privacy@buyverse.ai if you cannot sign in. Step-by-step instructions are on our account deletion page at buyverse.ai/account-deletion. We refuse a deletion, and tell you exactly what to finish first, while money is still moving for you or your customers: a payout on its way to your bank, money held in escrow for an order you bought or sold, a BuyVerse.ai balance your business has not withdrawn, or paid orders your business has not sent yet. Once your account is deleted you are signed out on every device and can never sign in to it again, and your email address is freed. Your name, contact details, profile picture, password and the hashes of your previous passwords, sign-in methods, two-factor settings, devices, settings, notifications, sign-in history and saved items are erased. Everything you published for other people is deleted: your reviews with their stars, text and photos, your feature-board posts, and the words of your forum posts. Any business you own is closed, even if other people on its team also manage it: its listings are taken down, its API keys stop working, and its BuyVerse.ai plan is cancelled so the plan is never charged again. A deletion cannot be undone.
• What deleting your account keeps: only the records the law or another person relies on — your orders and payments, invoices, payouts and tax records, disputes, your messages with buyers and sellers and the order notices they received, your support conversations, and security logs, from which the network address, browser, device and location are removed. They are no longer linked to your account, but what you wrote in them stays as written. A closed business keeps its own name, legal name and address, the name on its payout account, and the verification documents it submitted, in those records. Card details for a BuyVerse.ai plan are held by our payment processor, Stripe, under its own retention rules. Files uploaded to our file storage, such as listing images, are not removed from that storage by the deletion; email privacy@buyverse.ai and we will remove them. Working copies are not edited and expire on their own: internal event queues after about 7 days, caches and database backups on their own schedules, and service logs as they are overwritten by size (see "Request records" under "Information we collect").
• Access and port: you can submit a request from Dashboard → Settings → Privacy, and it is recorded. There is no automated process that produces the file, so a request submitted there can sit marked as being prepared and never complete. Email privacy@buyverse.ai and ask for a copy directly; we will respond within one month of your request.
• Restrict or object: there is no self-service control for this. Email privacy@buyverse.ai and we will handle it manually, within one month of your request.

10. Marketing

Your notification settings include a marketing category, which covers deal, price, promotion, digest, and insight notifications. Turning that category off stops those notifications on the channels you have switched on, and it takes effect for every message the platform classifies that way.

Separately, the cookie banner records a marketing consent choice for your browser. Nothing acts on that choice today, because no marketing or advertising technology is in use on the site. It is stored so that it is already in place if that ever changes.

11. Trust scores and profiling

Trust scores, tier badges, and verification status are calculated from your activity on the platform and from the documents you submit. They are visible to counterparties and influence how your business appears to them. They are calculated automatically, and BuyVerse.ai staff review verification documents by hand.

12. International transfers

The providers listed above operate internationally, so your information may be processed outside the country you are in. We are not stating a specific transfer mechanism here, because the hosting and storage arrangements for the production service are still being finalised and we would rather say nothing than say something we cannot stand behind.

13. Security

We encrypt traffic in transit, store passwords only as hashes, encrypt stored bank account numbers and connected-account tokens at the application level, offer two-factor authentication, lock accounts after repeated failed sign-ins, and keep audit records of security-relevant events. One qualification belongs here rather than only in the Cookie Policy: the short-lived access token your browser sends with each request is held in your browser's local storage, where a script running on the page could read it. The longer-lived refresh credential is held only in a cookie that no script on the page can read, however you signed in. No system is perfectly secure, and we cannot guarantee absolute security.

14. Children's privacy

The Services are for businesses and for people aged 18 and over. We do not knowingly collect personal information from children. We do not run an age check — the age requirement is a representation you make when you register.

15. Changes and contact

We may update this policy and will tell you about material changes. For privacy questions, or to exercise any of the rights above, contact privacy@buyverse.ai or use our contact page. For what we store in your browser, see our Cookie Policy.