Terms of Service
IN FORCE. See 00-README.
Legal basis. Every provision below rests on one of three things: a measured fact about the platform (cited to file and line), a rule of law (cited to the instrument and article in the Legal Basis Register), or a commercial choice CIQRA has made where the law leaves it open. Prepared and adopted by CIQRA OÜ.
🔴 §7.4 describes a DSA notice-and-action mechanism that does not exist, and §5.4 depends on it. Both are launch-blocking. §8.3 (European Accessibility Act) records an obligation already in force since 28 June 2025 against which no conformance assessment has been done.
Provider: CIQRA OÜ, registry code 16465907, Veskiposti tn 2, Kesklinna linnaosa, Tallinn, Harju maakond, 10138, Estonia ("CIQRA", "we", "us", "our"). Effective date: on publication (see version history) · In force from: 2026-08-09 · Version: 1.0 · Adopted by: CIQRA OÜ
1. Who these Terms are for and how they fit together
1.1 These Terms of Service ("Terms") govern access to and use of the CIQRA platform, websites (including ciqra.com), storefront hosting, dashboards, APIs, and all related software, features and services (together, the "Services").
1.2 The Services are used by two very different groups, and different rules apply to each:
- Merchants (also "you" where context indicates) — businesses and their authorised users that create and operate an online store ("Storefront") on CIQRA. Merchants are additionally bound by the Merchant Agreement, and, if they enable CIQRA Pay, by the payment terms and the Stripe agreements referenced there.
- Customers / Shoppers — end users who browse or buy from a Merchant's Storefront. Customers contract with the Merchant, not with CIQRA, for the purchase of goods or services (see §4).
1.3 CIQRA is a platform / intermediary, not the seller. Except for CIQRA's own subscription and platform services sold directly to Merchants, CIQRA does not sell, and is not the merchant of record for, any goods or services offered on a Storefront. The sales contract for those goods/services is concluded directly between the Customer and the Merchant, who is the merchant of record.
1.4 Order of precedence. If a signed Enterprise Master Services Agreement (MSA) or Order Form exists, it prevails on the matters it covers. Otherwise: Merchant Agreement → DPA → these Terms → ancillary policies (Cookie, Acceptable Use, Refund/Chargeback/Reserve) and the applicable market overlay. Mandatory consumer-protection and data-protection law prevails over any conflicting term.
CIQRA's determination: the precedence ladder is CIQRA's own construction. It has not been reviewed for consistency with the Stripe agreements, which state that they prevail on payment mechanics (Merchant Agreement §1.4) — so on payment matters the true top of the ladder is a contract CIQRA is not party to. Mandatory consumer and data-protection law overrides all of it.
1.5 Incorporated policies. The Privacy Policy, Cookie Policy, Acceptable Use Policy, Refund/Chargeback/Reserve Policy, and any applicable market overlay (e.g. the TR overlay) are incorporated into and form part of these Terms.
2. Eligibility, accounts and security
2.1 Merchant eligibility. To register as a Merchant you must be at least 18 years old and either an individual acting for business purposes or a duly authorised representative of a legal person, and you must have authority to bind that person. You must provide accurate identity, business and (where CIQRA Pay is used) KYC/beneficial-ownership information, and keep it current.
CIQRA's determination: the 18+ and authorised-representative requirements are representations collected at signup, not verified. No age or authority verification mechanism was found. Identity checking happens only later, and only for merchants who onboard to CIQRA Pay, where Stripe performs it (
Payments/Stripe/StripeConnectService.cs:60-72) — a merchant using a BYO gateway is never verified by anyone.
2.2 Customer eligibility. Customers must be at least 16 years old to create a Customer account or consent to processing on their own behalf; below that age, a Customer may use a Storefront only with the consent of a holder of parental responsibility. The applicable digital-consent age is applied per market (GDPR default 16; Estonia 13; certain jurisdictions 13–15). Nothing here overrides a Merchant's own age restrictions for age-restricted goods.
CIQRA's determination: the 16+ threshold with a per-market digital-consent age (GDPR default 16; Estonia 13 under IKS §8) is stated as policy. No age gate or per-market consent-age mechanism was found at storefront signup. In practice age assurance rests with the Merchant (AUP §2), and this clause should not be read as a platform control.
2.3 Accounts. You are responsible for all activity under your account, for safeguarding credentials, and for the acts and omissions of your authorised users. Notify us immediately at support@ciqra.com of any unauthorised use. We may require multi-factor authentication.
2.4 Verification & sanctions screening. We (and our payment partner) may verify your identity and business and screen against sanctions and watchlists. We may suspend or refuse Services where verification fails or where required by law. You represent that you and your beneficial owners are not subject to sanctions and are not located in a prohibited jurisdiction.
CIQRA's determination: sanctions and watchlist screening is performed by Stripe, not CIQRA — no screening code exists. What CIQRA implements is a supported-market gate at CIQRA Pay onboarding (
StripeConnectService.cs:50-57), which refuses unsupported countries. A market gate is not a sanctions screen; the two should not be conflated.
3. The Services; plans, fees and billing
3.1 Provision of the Services. Subject to these Terms, we grant you a non-exclusive, non-transferable, revocable right to access and use the Services during your subscription term for your internal business purpose of operating your Storefront(s).
3.2 Plans. CIQRA is offered on paid subscription tiers — Entry, Growth and Pro — plus transaction-based CIQRA Pay commission (Merchant Agreement §3). There is no free plan. ⛔ Subscription prices are not stated in these Terms — see the note below. The price for your plan is the amount published on CIQRA's pricing page or stated in your Order Form at the time you subscribe, charged through the corresponding Stripe Price object. A 14-day free trial applies; each tier carries feature and usage limits and a corresponding CIQRA Pay commission rate. The live pricing page and your Order Form are authoritative and prevail over these figures. (Prices are illustrative pending final confirmation; the DRAFT status applies.) Some features are plan-gated; using a feature above your plan's limits may require an upgrade.
✅ Measured 2026-08-09 (
lane/L@81807dc44): the plan structure is implemented as described — Entry / Growth / Pro / Enterprise, no free plan, with Enterprise sales-led (Ciqra.Api/Billing/PlanCatalog.cs:135-145,IsSelfServe: falsefor Enterprise) and a 14-day trial (:46,TrialDays = 14). The figures carried in code are Entry €19 / Growth €49 / Pro €149 (annual equivalents €16 / €41 / €124) — recorded here as a measurement of the source tree, not as prices; see the withdrawal note below.⛔ Subscription prices are NOT IN FORCE — same class as the withdrawn commission schedule. The source says so itself (
PlanCatalog.cs:29): "PRICES ARE ILLUSTRATIVE pending the commercial launch decision; the real amounts live in Stripe (the Price objects referenced by StripeBillingOptions.Prices)". A figure the code calls illustrative is a placeholder, and adoption would convert it into a price CIQRA had agreed to charge. €19 / €49 / €149 are therefore withdrawn from force.What applies instead: the subscription price is the amount published on CIQRA's pricing page or stated in your Order Form, charged through the corresponding Stripe Price object. The plan structure (Entry / Growth / Pro / Enterprise, no free plan, Enterprise sales-led) and the 14-day trial remain in force — both are measured in the code (
PlanCatalog.cs:135-145,:46).
3.3 Enterprise. Enterprise customers may contract under a separately negotiated MSA / Order Form ("contact sales"), which may include custom pricing, an SLA and custom DPA terms, and which prevails over these Terms and the Merchant Agreement to the extent of any conflict. ⛔ Staff single sign-on (SSO) is not offered — see the determination below.
🔴 CIQRA's determination — SSO removed from this clause (PA-0375). As at 2026-08-10 there is no staff SSO in the platform: the string
ssooccurs in exactly three places in the source tree — the entitlement constant (Billing/PlanCatalog.cs:57), the Enterprise entitlement list (:128), and a source comment recording this very finding. There is no SAML, no OIDC staff federation, no identity-provider integration of any kind.settings/social-loginis shopper login on the storefront, not staff SSO.⚠️ "May include" did not save the clause. In a negotiated-MSA sentence, a list of things the MSA may include reads to a prospect as a menu of things that can be had. Nothing on that list can be had here at any price, so the word may describes a possibility that does not exist.
🔑 How this survived. PA-0375 was raised against the Enterprise tagline in the product, and the tagline was corrected. This clause makes the same claim, in a document in force, and was not checked at the time — the surface that raised the defect became the surface that bounded the fix. The claim is removed here and at README §3; the entitlement list still carries it in code (item 18).
3.4 Trials. If a trial is offered, it converts to a paid subscription at the end of the trial unless cancelled beforehand. We may modify or withdraw trials.
3.5 Fees, taxes and auto-renewal.
(a) Subscription fees and CIQRA Pay commission are billed exclusive of applicable VAT and other taxes. CIQRA is VAT-registered in Estonia (VAT/KMKR no. EE102934712). CIQRA's subscription and platform-commission supplies are electronically supplied services; VAT is applied by place-of-supply rules: EU business customers — no Estonian VAT, reverse charge applies (you self-account; CIQRA validates your VAT ID via VIES and shows both VAT IDs and a "reverse charge" mention on the invoice); EU non-business customers — destination-country VAT via the EU One-Stop-Shop (OSS); non-EU customers — outside EU VAT scope (local taxes may apply). You are responsible for taxes other than taxes on CIQRA's net income, and for providing a valid VAT ID where you have one. [Approach: EU VAT Directive Arts. 44/58/196; Union OSS.]
CIQRA's determination: the VAT treatment (reverse charge for EU business customers under Art. 196, OSS for EU non-business, out of scope for non-EU) is CIQRA's own reading and has not been reviewed by tax counsel. This reconciliation did not verify that VIES validation runs at onboarding or that invoices carry both VAT IDs and the "reverse charge" annotation — both are stated to merchants as facts. Estonian VAT is 24% from 01.07.2025. See Merchant Agreement §3.5. (b) CIQRA Pay commission and pass-through fees are described in the Merchant Agreement and charged per transaction. (c) Subscriptions auto-renew for successive periods at the then-current price unless cancelled before the renewal date. (d) No pro-rata refunds on cancellation: cancellation takes effect at the end of the current paid period, and you retain access until then. Statutory consumer withdrawal rights, where they apply to a given user, are unaffected (see §4.6).
CIQRA's determination: the no-pro-rata / auto-renewal terms are drafted on the basis that Merchants are traders (§2.1). Because that is a representation rather than a verified fact, a sole trader may still qualify as a consumer for some purposes, which is why the statutory carve-out follows. As a standard term it is subject to the mandatory rules of Estonian law. CIQRA's determination is that the term applies to the maximum extent Estonian law permits and no further: where a mandatory rule limits it, the mandatory rule prevails and the remainder of the clause stands severed and effective (VÕS / TsÜS, Legal Basis Register rows 3.4 and 5.4); where the counterparty is in fact a consumer, the statutory withdrawal right in §3.5(d) applies and prevails. (e) Price changes to subscription fees or CIQRA Pay rates take effect on 30 days' prior notice; continued use after the effective date constitutes acceptance, and you may cancel before then.
[Approach: Shopify/Stripe 30-day change-notice standard.](f) Overdue amounts may accrue statutory interest and lead to suspension. We may set off amounts you owe us against payouts (see Merchant Agreement).
3.6 Changes to the Services. We may add, modify, deprecate or remove features. For material adverse changes to a paid feature you rely on, we will give reasonable prior notice.
3.7 Usage limits, API and fair use. You must not use the Services (including our APIs) in a way that
imposes an unreasonable or disproportionate load, threatens stability or security, or degrades other
Merchants' experience, and you must not circumvent a limit that applies to you. Automated access must use
our documented APIs within their published rate limits. Where a limit is stated as a number — in your
plan, your Order Form, or published API rate limits — that number applies. Where CIQRA considers that your
use is disproportionate on a dimension for which no number is stated, CIQRA will tell you in writing
what it has observed, and give you at least 30 days to discuss or adjust, before applying any
restriction; CIQRA will not charge you for that use retrospectively. [Approach: BigCommerce/Shopify API-limit & fair-use standard.]
3.7a What is actually metered — measured, and mostly absent. CIQRA can attribute AI usage to a Merchant. It cannot presently attribute storage, bandwidth, email volume, search queries or platform request counts to a Merchant. Where a dimension is not metered, §3.7's written-notice route is the only route: there will be no usage charge and no automatic restriction on it.
🔴 CIQRA's determination (PA-0390) — how to write a limit on something you cannot measure
① Measured (lane R,
FIYAT-TABANI.tsvrowsC-030–C-036, 2026-08-09). Six per-tenant cost axes; one has a meter and five do not:
axis per-tenant meter? evidence AI tokens 🟢 yes AiUsageRecord/AiUsagePeriod(Ciqra.Modules.Ai/Domain/AiUsageRecord.cs:25); quota viaAiCreditBalance/AiCreditGrantstorage (GB) 🔴 no media is held as MediaAsset/MediaFolder; no per-tenant byte totalbandwidth / egress 🔴 no no per-tenant egress counter anywhere in a 260-entity surface emails sent 🔴 no EmailDeliveryrecords individual sends; there is no periodic per-tenant countersearch queries 🔴 no Typesense is one shared container app; queries are not attributed platform requests 🔴 no AnalyticsEventcounts storefront events for marketing, not platform requests🔴 And the previous wording of §3.7 named four of the five unmetered ones as examples of plan limits — "storage, bandwidth, API call rates, ... product/order volume" — while obliging the Merchant not to exceed them. That is an obligation stated against a quantity neither party can compute: the Merchant cannot know whether they are complying, and CIQRA cannot show that they are not.
⚠️ PA-0390 is not PA-0346, and the difference is the whole point. PA-0346 asks for the meter. PA-0390 governs how the clause lives without one — so closing 0346 does not close 0390 by itself (the clause must then be rewritten to state numbers), and closing 0390 does not reduce the need for 0346 by one line. 🔑 One is an instrument; the other is how you behave until you have it.
② Rule — the four things a limit needs, and which ones a missing meter removes. A usage limit is enforceable when it has: (i) a stated quantity, (ii) an observation showing it was passed, (iii) a procedure before consequence, and (iv) a proportionate consequence. A missing meter removes (i) and (ii) and leaves only (iii) and (iv). 🔑 So the honest clause is not a vaguer number — it is a clause that gives up the number and keeps the procedure. A number that cannot be computed is worse than no number: it invites the Merchant to rely on it, and gives CIQRA nothing to prove breach with.
③ The three things §3.7 must therefore NOT do, and now does not: ⓐ No retrospective usage charge on an unmetered axis. Billing for excess consumption presupposes a figure for the excess. Invoicing a sum CIQRA cannot substantiate would be a charge the Merchant can refuse and CIQRA cannot evidence — and on a prepaid annual term it would be a demand on top of money already taken. ⓑ No automatic restriction on an unmetered axis. An automatic control needs a trigger; there is no signal to trigger on. What exists is a human noticing something, which is a conversation, not a control. ⓒ No unilateral cut-off without reasons. Where a restriction is applied, the reason is stated to the Merchant at or before the time it takes effect (Merchant Agreement §8.3a — P2B Art. 4 would require this if P2B applies to CIQRA, which is unmeasured; CIQRA commits to it here either way, so the commitment does not depend on that question).
④ Prepaid annual terms — the combination that had to be broken. CIQRA's standard terms say there is no pro-rata refund on cancellation. Combined with a right to restrict on fair-use grounds and a year paid in advance, that would let CIQRA withhold service while keeping the whole prepayment. 🔒 Determination: where CIQRA restricts or suspends a Merchant on fair-use grounds under §3.7 and the Merchant has prepaid, the unused portion of the prepaid term is refunded pro rata. The no-refund rule covers a Merchant who chooses to leave; it must not cover a Merchant CIQRA stops serving.
⑤ Self-closing. This paragraph is written for the platform as measured on 2026-08-10 and is meant to stop applying to each axis as that axis gains a meter. ⚠️ Its trigger is an event a person performs, not a date: a per-tenant counter shipping for an axis is what moves that axis from §3.7's notice route to a stated number. 🔑 A clause that describes an absence must say what ends it, or it becomes a description of the platform forever.
⛔ What this does not fix. The exposure R recorded at
C-036is unchanged: a Merchant consuming heavily is invisible until the Azure bill arrives, and that bill is at subscription level, so it does not say which Merchant. This clause governs what CIQRA may do about it; it creates no ability to see it (PA-0346). 🔑 Writing a fair-use clause is not the same as acquiring fair-use vision, and the clause must not be read as evidence of the vision.
4. Storefronts, sales, and the CIQRA / Merchant / Customer relationship
4.1 Merchant is the seller and merchant of record. Each Merchant is solely responsible for its Storefront, products, pricing, descriptions, availability, content, order fulfilment, delivery, returns, warranties, after-sales support, and for all consumer-law, product-safety, labelling, tax (incl. VAT/OSS) and sector-specific obligations relating to its sales. CIQRA provides tooling (including tax-calculation, invoicing and VAT/OSS helpers) but does not assume the Merchant's legal obligations.
✅ Measured 2026-08-09 (
lane/L@81807dc44): the merchant-of-record allocation is not merely contractual — it follows from the payment topology. Charges are created on the Merchant's own Stripe connected account (Payments/Stripe/CiqraPayStripeProvider.cs:69) with CIQRA's fee riding as anapplication_fee(:61), and not as a destination charge (on_behalf_of/transfer_dataare absent repo-wide). Full measurement: Merchant Agreement §1.3.
4.2 No CIQRA liability for Merchant sales. CIQRA is not a party to, and is not liable under, any Customer↔Merchant sales contract. Claims about products, delivery, refunds or warranties are between the Customer and the Merchant. This does not limit any non-excludable statutory right a Customer has against CIQRA in its capacity as an online-platform operator under mandatory law (e.g. DSA duties).
CIQRA's determination: this follows from the measured topology above and is CIQRA's central liability position. Against a consumer who deals with a Merchant through a CIQRA-hosted storefront, this allocation operates only so far as mandatory consumer law permits: under Directive 2011/83/EU and the Estonian Tarbijakaitseseadus (Legal Basis Register rows 3.1 and 3.5), mandatory consumer protection prevails over any contrary contractual allocation. Consumers are not party to these Terms in the same way, and platform liability toward consumers is an area of active EU development.
4.3 Consumer information. Merchants must present, on their Storefront, all information mandatory under applicable consumer law (seller identity and geographic/e-mail address, total price incl. taxes and delivery, right-of-withdrawal information and model form, complaint handling, guarantees, and — for EU consumers — a link to the EU ODR platform). CIQRA's themes provide fields and templates to support this; accuracy remains the Merchant's responsibility.
CIQRA's determination: the mandatory pre-contract information duties are imposed on the Merchant. This reconciliation did not verify that the storefront provides the fields or templates a Merchant needs to discharge them. Note the related gap: the Estonian "withdraw from contract" button required from 01.09.2026 is not implemented — see Refund/Chargeback/Reserve Policy A.2.
4.4 Payments. Where a Merchant uses CIQRA Pay, funds from Customers are collected via Stripe Connect on a direct-charge basis to the Merchant's connected account, with CIQRA's platform fee applied; payout, reserve, refund and chargeback mechanics are governed by the Merchant Agreement and Refund/Chargeback/Reserve Policy. Where a Merchant uses its own (BYO) gateway, that gateway's terms apply between the Merchant and its provider.
4.5 Card data / PCI. CIQRA operates on a PCI DSS SAQ A basis: raw card numbers are captured directly by Stripe's hosted fields and are never stored, processed or transmitted by CIQRA systems.
✅ Measured 2026-08-09 (
lane/L@81807dc44): the SAQ A statement holds. Card fields on the storefront checkout are Stripe Elements iframes —data-stripe-fieldmount points for number, expiry and CVC (Storefront/Themes/default/checkout-payment.liquid:99,110,117) — and the platform's declared raw-PAN seam has no implementation:IRawCardPaymentProvider/RawCardPaymentRequest(Ciqra.Modules.Payment/PaymentAbstractions.cs:103-119, labelled SAQ D in source) is referenced only by its own declaration. Local acquirers route through the hosted/3DS-redirect path (INativePaymentProvider.cs:48).⚠️ One named condition: this holds only while that interface stays unimplemented. Implementing it would put raw PAN into CIQRA systems and move the attestation to SAQ D. Note separately that PCI DSS v4.0.1 SAQ A (all 2026 assessments) now requires the merchant's entire website to be protected against script-based attacks, not only the payment page — CIQRA's determination is that the whole-site script-protection requirement applies to CIQRA and is not yet evidenced: the current SAQ A + AoC has not been completed against v4.0.1. Completing it is an open item (00-README §6).
4.6 Consumer withdrawal (EU). Where the buyer is an EU/EEA consumer, the statutory 14-day right of withdrawal for distance contracts applies to the Merchant's sale, subject to the legal exceptions (e.g. made-to-order goods; sealed goods unsealed after delivery; and digital content/services where performance began with the consumer's prior express consent and acknowledgement of loss of the withdrawal right). Merchants must honour this minimum and may offer more generous terms (hybrid model). From 01.09.2026, Estonian law additionally requires an online "withdraw from contract" button for consumer distance contracts; CIQRA will provide storefront support for this, but the Merchant remains responsible for compliant handling. This clause governs the Merchant's sales; for CIQRA's own subscription sales to consumer-Merchants, see §3.5(d).
CIQRA's determination: the 14-day withdrawal right and its exceptions are stated at EU-directive level and enforced by the platform as a single global default rather than per market, while 00-README §3 commits to global availability from launch. CIQRA's determination is that the EU-level default is the floor, not the ceiling: the platform enforces the 14-day statutory minimum everywhere, and where a market's mandatory consumer law is stricter, that law prevails and the Merchant must meet it (Directive 2011/83/EU; Legal Basis Register row 3.1). Estonia implements withdrawal through the VÕS, whose amendments (including the withdrawal button) take effect 01.09.2026.
5. Your content and licence to CIQRA
5.1 Your Content. "Merchant Content" means everything you or your users upload or configure — product data, media, text, themes, code snippets, storefront pages, and Customer personal data processed through your Storefront. You retain all rights in Merchant Content.
5.2 Licence to operate the Services. You grant CIQRA a worldwide, non-exclusive, royalty-free licence to host, store, reproduce, adapt (e.g. image derivatives/format conversion), transmit, cache and display Merchant Content solely to provide, secure, and improve the Services and as instructed by you. For Customer personal data within Merchant Content, CIQRA acts as processor under the DPA; this licence is subject to the DPA.
5.3 Responsibility & warranties. You represent that you own or are licensed to use Merchant Content, that it does not infringe third-party rights or violate law, and that it complies with the Acceptable Use Policy.
5.4 User-generated content (reviews, Q&A, comments). Storefronts may host Customer-generated content (product reviews, ratings, Q&A). The Merchant is the primary host/moderator of such content on its Storefront; CIQRA provides moderation tooling and, as platform operator, maintains a notice-and-action mechanism for illegal content. See the Acceptable Use Policy and.
🔴 CIQRA's determination: the Merchant is named as primary host/moderator, which is a sound allocation — but it does not displace CIQRA's own duties as a hosting service under the DSA, and the mechanism those duties require does not exist: no notice-and-action endpoint, takedown flow or statement-of-reasons record was found anywhere in the platform. See §7.4 below and AUP §4.2, where the same finding is recorded. The programme also maintains a standing rule that review data is never fabricated during migration, which this clause supports.
5.5 Feedback. If you send us suggestions, we may use them without restriction or obligation.
6. CIQRA intellectual property
6.1 The Services, CIQRA software, default themes, design system, trademarks and documentation are owned by CIQRA or its licensors. Except for the limited rights granted here, no rights are transferred.
6.2 Themes & templates. Default and CIQRA-provided themes are licensed for use only to operate Storefronts on CIQRA and may not be redistributed or used off-platform. Third-party theme/asset licences (where applicable) may impose additional restrictions; you are responsible for licences for any assets you upload.
CIQRA's determination: the restriction on redistributing CIQRA-provided themes is straightforward. A separate constraint the programme operates under is relevant to this clause: third-party themes licensed from a marketplace may only be ported for CIQRA's own brands, not offered to merchants generally. Whether the shipped default theme set is entirely CIQRA-originated has not been verified in this reconciliation, and a licensing error here would surface as a claim against CIQRA rather than against a Merchant.
6.3 Beta features are provided "as is", may change or be withdrawn, and may carry additional terms.
7. Acceptable use; prohibited businesses; suspension
7.1 You must comply with the Acceptable Use Policy, which lists prohibited conduct and prohibited business/product categories (Stripe Restricted Businesses plus CIQRA-specific bans — adult content; weapons/ammunition; tobacco/vape/nicotine; CBD/cannabis/unregulated supplements; crypto/NFT; gambling/betting).
CIQRA's determination: the prohibited-category list is enforced by Stripe's Restricted Businesses controls and manual review, not by a platform mechanism — no category screening code was found. Several CIQRA-added categories (CBD/cannabis, supplements) are jurisdiction-variable and have not been reviewed per market; see AUP §2.
7.2 Suspension / termination for cause. We may suspend, restrict or terminate access (in whole or part) immediately where we reasonably believe you have breached these Terms, the AUP, the Merchant Agreement, or law; where required by our payment partner, a bank, or authority; or to protect the Services, other users, or third parties (e.g. fraud, security, chargeback abuse, sanctions). Where practicable and lawful, we will give notice and an opportunity to cure.
7.3 Effect on funds. Suspension may pause payouts; funds are handled under the Merchant Agreement and Refund/Chargeback/Reserve Policy.
7.4 Illegal-content & IP notices (DSA / DMCA). Reports of allegedly illegal content or intellectual-property infringement are received at abuse@ciqra.com and acted on under the Acceptable Use Policy §4. ⛔ The structured notice-and-action mechanism required by DSA Arts. 16–17 — a permanent record per notice, a decision returned to the notifier, a statement of reasons per restriction, and a repeat-infringer counter — is NOT YET BUILT (PA-0350). This clause states the channel that exists; it does not claim the mechanism that does not. Notices may be sent to abuse@ciqra.com (illegal content, DSA) and [copyright/IP: abuse@ciqra.com] (infringement/DMCA-style notices and counter-notices). We provide a statement of reasons for content actions and an internal complaint path, consistent with the EU Digital Services Act, and may terminate repeat infringers.
🔴 CIQRA's determination: this clause describes a facility that does not exist. "We operate a notice-and-action mechanism… and a repeat-infringer policy" is written in the present tense; a repo-wide search for an abuse/illegal-content report endpoint, takedown flow, statement-of-reasons record or repeat-infringer counter returns zero implementations. DSA Arts. 16–17 apply from day one to a hosting service serving EU users and cannot be deferred like a market overlay. Either the mechanism ships before launch or this clause is withdrawn — it must not be published as a description of an existing facility. Same finding: AUP §4.2, IP / Copyright / DMCA Policy. Launch-blocking.
8. Availability, support, SLA and accessibility
8.1 We aim to provide the Services with reasonable skill and care and to keep them available, but except where an SLA is expressly agreed, the Services are provided on a commercially reasonable-efforts basis and may have downtime for maintenance, updates or factors beyond our control.
8.2 Support & SLA. Standard plans receive email support and a help centre during business hours (Mon–Fri, ~09:00–18:00 EET, excluding public holidays), with a target first response within 1 business day; there is no uptime guarantee or service credit on standard plans. Enterprise plans receive priority support and a defined SLA, targeting 99.9% monthly uptime with priority response targets (e.g. within 4 business hours for critical issues) and service credits as the sole and exclusive remedy for missed uptime, subject to standard exclusions (scheduled maintenance, force majeure, Merchant fault, third-party outages) and a claim window. Exact Enterprise SLA figures and credit schedule are set in the Order Form/MSA. [Approach: BigCommerce/Shopify-Plus SLA-credit structure; İkas-style "no SLA on standard tier" differentiator.]
8.3 Accessibility. We design the platform to support Merchant compliance with applicable accessibility law, including the EU European Accessibility Act (in force from 28 June 2025) and WCAG-aligned standards, for the platform-provided interfaces. Accessibility of a Storefront's own content, themes and configuration is the Merchant's responsibility.
CIQRA's determination: the European Accessibility Act (Directive (EU) 2019/882) has been in force since 28 June 2025 — it is a current obligation, not a forthcoming one. CIQRA has not conducted a WCAG or EAA conformance assessment of the storefront or the admin, and none was found in this reconciliation. The clause says CIQRA designs the platform "to support Merchant compliance", which is carefully worded, but a Merchant cannot reach EAA conformance on a storefront whose conformance is unknown. An accessibility audit is an unstarted work item, not a drafting matter.
8.4 Platform-to-business transparency (P2B Regulation (EU) 2019/1150). As an online intermediation service for business users, we provide: plain-language terms with reasons and notice periods for changes; a description of the main parameters determining ranking of products in Storefront listings/search and their relative importance; the treatment of any CIQRA-favoured or paid placement; and an internal complaint-handling system for Merchants (via support@ciqra.com), plus access to mediation. Ranking within a Merchant's own Storefront primarily reflects the Merchant's configuration and genuine relevance/popularity signals.
CIQRA's determination: the P2B Regulation (EU) 2019/1150 applies to CIQRA as an online intermediation service for business users. The clause commits to plain-language terms, notice periods for changes, statements of reasons for restrictions/suspensions, and an internal complaint-handling system. Of these, the internal complaint-handling system (Art. 11) was not found — and it overlaps with the missing DSA notice-and-action mechanism in §7.4. Art. 11 exempts small enterprises; whether CIQRA qualifies is determined as stated above. The 30-day change-notice commitment is real as a drafted term but is not enforced by any platform mechanism.
9. Third-party services and integrations
9.1 The Services integrate third parties (e.g. Stripe for payments; Microsoft Azure (Germany) for hosting; Cloudflare; email delivery; error monitoring/observability; AI/LLM providers; advertising platforms and pixels/CAPI; and any Merchant-connected marketplace channels). Your use of an integration may be subject to that third party's terms, and you authorise the associated data flows described in the Privacy Policy and DPA. CIQRA is not responsible for third-party services except as expressly stated.
🔴 CIQRA's determination: this list requires correction as at 2026-08-09. The AI/LLM providers actually integrated are Anthropic, OpenAI, Voyage AI and fal.ai — all four in the US, all reached directly, with no self-hosted gateway keeping inference in the EEA (the earlier gateway claim was incorrect). Voyage AI and fal.ai were absent from every prior subprocessor disclosure. Email delivery is Azure Communication Services only — the previously listed Amazon SES fallback does not exist in the code. Additional recipients not previously listed: shipping carriers, Turkish SMS providers, and hCaptcha. Corrected inventory: Subprocessor List; AI detail: AI Terms §1.
9.2 AI features. Where you use AI features (e.g. AI product-description/SEO generation, semantic search/recommendations, image generation/editing, chatbot), your inputs are processed by AI/LLM providers under contracts that require zero-retention / no-training-on-your-data and appropriate data-protection terms. You must not submit content you are not entitled to submit, and you remain responsible for reviewing AI outputs before publishing them. AI-assisted or AI-generated content and AI interactions are disclosed/marked where required by law.
CIQRA's determination: AI inputs are processed by third-party providers outside the EEA — see the correction above and AI Terms §2.4. No-training/zero-retention rests on published vendor policy, not verified executed terms. Art. 50 marking of generated images is implemented (IPTC Digital Source Type,
Ciqra.Api/Ai/AiProvenanceMetadata.cs:15-20), but the platform records provenance without being able to enforce disclosure (AI Terms §3.2).
10. Warranties and disclaimers
10.1 Each party warrants it has authority to enter these Terms.
10.2 Disclaimer. Except as expressly stated and to the maximum extent permitted by law, the Services are provided "as is" and "as available", and CIQRA disclaims all implied warranties (merchantability, fitness for a particular purpose, non-infringement) and does not warrant that the Services will be uninterrupted, error-free, or that they will meet a specific commercial or legal outcome (e.g. tax correctness for your specific facts, or sales results). Nothing in these Terms excludes liability that cannot be excluded by law, including certain consumer rights.
CIQRA's determination: the "as is" disclaimer is drafted at the maximum the law allows and is deliberately paired with the carve-outs below. As a standard term it is subject to the mandatory rules of Estonian law. CIQRA's determination is that the term applies to the maximum extent Estonian law permits and no further: where a mandatory rule limits it, the mandatory rule prevails and the remainder of the clause stands severed and effective (VÕS / TsÜS, Legal Basis Register rows 3.4 and 5.4). It cannot exclude the mandatory items listed in §11.3. It cannot exclude the mandatory items listed in §11.3.
11. Limitation of liability
11.1 Excluded losses. To the maximum extent permitted by law, neither party is liable for indirect, incidental, special, consequential or punitive damages, or for lost profits, revenue, goodwill, or data, arising out of or relating to the Services.
11.2 Cap. To the maximum extent permitted by law, CIQRA's total aggregate liability arising out of or relating to the Services in any 12-month period is limited to the greater of (a) the fees you paid to CIQRA (excluding pass-through payment-processing fees and taxes) for the Services in that period, or (b) €500 (③ commercial choice, confirmed — see the note below).
€500 floor — ③ commercial choice, confirmed 2026-08-09. The floor was surfaced by the same test that withdrew the commission rates (00-README §6A), and it was kept. It operates in the Merchant's favour: limb (a) alone could set the cap at zero for a Merchant still in trial, so withdrawing the figure would have worsened the Merchant's position.
🔑 The rule this settles, recorded because the test will meet it again: the reason for withdrawing an undecided number must not be that it makes the term worse. Withdrawal exists to stop CIQRA committing to something nobody agreed — not to strip a protection the other side already reads as theirs. Where an undecided figure runs in the counterparty's favour, the correct move is to decide it, and it is decided here.
[Approach: SaaS "fees paid in prior 12 months, or small floor" cap standard.]
11.3 Carve-outs. The exclusions and cap do not apply to: liability that cannot be limited by law; a party's liability for death or personal injury caused by its negligence; fraud or wilful misconduct; a Merchant's indemnity obligations (§12); or amounts owed under the payment/reserve/chargeback provisions of the Merchant Agreement. Consumer statutory rights are unaffected.
CIQRA's determination: the carve-out list follows the conventional pattern. Note that it must also, as a matter of law, leave intact a data subject's Art. 82 GDPR compensation right — the DPA §12 records the same point. The cap itself is subject to the mandatory rules of Estonian law. CIQRA's determination is that the term applies to the maximum extent Estonian law permits and no further: where a mandatory rule limits it, the mandatory rule prevails and the remainder of the clause stands severed and effective (VÕS / TsÜS, Legal Basis Register rows 3.4 and 5.4).
12. Indemnity (Merchants)
Merchants will defend and indemnify CIQRA and its officers, employees and partners against third-party claims, losses, and reasonable costs arising from: (a) Merchant Content or products/services sold; (b) breach of these Terms, the Merchant Agreement, the AUP, or law; (c) a Customer or tax/consumer/regulatory claim relating to the Merchant's sales; or (d) infringement of third-party rights. CIQRA will notify the Merchant, allow it to control the defence (without settling in a way that admits CIQRA liability without consent), and cooperate reasonably. Consumer indemnities are not sought from Customers.
13. Term, termination and offboarding
13.1 These Terms apply while you use the Services. Either party may terminate for material breach not cured within 30 days of notice (or immediately where cure is impossible or where §7.2 applies). You may cancel your subscription at any time, effective at period end.
13.2 Effect of termination. Access ends; outstanding fees remain due; CIQRA Pay balances, reserves and chargeback exposure are settled per the Merchant Agreement.
13.3 Data export & deletion. For 30 days after termination, you may export Merchant Content (read-only access to export tooling). Thereafter CIQRA will delete or anonymise it per the Data Retention policy and the DPA, subject to legal retention obligations (e.g. 7-year accounting records).
13.4 Survival. Clauses that by nature should survive (IP, fees accrued, disclaimers, liability limits, indemnity, governing law/disputes, confidentiality) survive termination.
14. Changes to these Terms
We may update these Terms. For material changes we will give reasonable prior notice (e.g. email or in-dashboard) before they take effect. Continued use after the effective date constitutes acceptance; if you do not agree, you must stop using the Services and may cancel. Consumer users receive changes consistent with mandatory consumer law.
CIQRA's determination: "reasonable prior notice" is unquantified here, while the Merchant Agreement §12.2 commits to 30 days for material payment-term changes and the P2B Regulation sets a minimum notice period for business users (generally 15 days, longer where the change requires technical adaptation). These Terms should state a definite period rather than leave it to be read across from another document; an unquantified notice period is weaker than the one CIQRA has already committed to elsewhere.
15. Governing law and disputes (hybrid)
15.1 Governing law. These Terms and any non-contractual obligations arising from them are governed by the laws of Estonia, excluding its conflict-of-laws rules and the UN CISG. For consumers, this choice does not deprive them of the protection of mandatory rules of their country of habitual residence.
15.2 B2B (Merchants). Disputes between CIQRA and a Merchant are subject to the exclusive jurisdiction of Harju Maakohus (Harju County Court), Tallinn, Estonia, or, where the Merchant Agreement so provides, to arbitration.
CIQRA's determination: exclusive jurisdiction in Harju Maakohus follows CIQRA's establishment and is conventional. It has not been reviewed for enforceability against merchants established outside the EU — relevant because CIQRA serves global markets from launch — and the arbitration alternative is unspecified (no seat, rules, language or tribunal). An unspecified arbitration option is not an operable dispute mechanism; either name a set of rules or remove it.
15.3 B2C (Customers). Disputes with consumers may be brought in the courts of the consumer's country of habitual residence, and consumers retain all mandatory local consumer-protection rights. EU consumers may also use the EU Online Dispute Resolution (ODR) platform and applicable national ADR/consumer bodies.
CIQRA's determination: the consumer forum rule and preservation of mandatory local consumer protection are correctly stated. The EU ODR platform referenced in 00-README §3 ceased operating on 20 July 2025; any reference to it as a live route should be removed from consumer-facing text rather than carried forward.
15.4 Nothing prevents either party from seeking injunctive relief to protect IP, confidential information, or security.
16. General
16.1 Assignment. You may not assign these Terms without our consent; we may assign to an affiliate or successor (e.g. merger, reorganisation).
16.1a No exclusivity. These Terms are non-exclusive. Nothing prevents CIQRA from providing the Services to any other person, including your competitors, or from developing similar products or working with third parties.
16.1b Publicity. CIQRA may identify you as a customer and use your name and logo in customer lists and marketing, in a manner consistent with your brand guidelines where provided; you may opt out at any time by writing to legal@ciqra.com. Neither party may otherwise issue a press release about the other without consent. [Approach: SaaS publicity-with-opt-out standard.]
16.1c Third-party beneficiaries. Except for Stripe (and, where relevant, card schemes/payment providers) as stated in the Merchant Agreement, and except for rights data subjects have under the SCCs/DPA, these Terms create no third-party rights.
16.2 Entire agreement. These Terms and the incorporated documents are the entire agreement and supersede prior understandings on their subject matter.
16.3 Severability / no waiver. If a term is unenforceable, the rest remains in effect; failure to enforce is not a waiver.
16.4 Force majeure. Neither party is liable for delay/failure due to events beyond reasonable control.
16.5 Notices. To CIQRA: legal@ciqra.com. To you: the contact details/dashboard on your account. Statutory notice requirements are preserved.
16.5a A channel CIQRA names in a notice must exist, and the person told about it must be able to reach it (PA-0407). Where CIQRA's own message invites a recipient to reply, complain, contest, cancel or otherwise act through a named route, that route is part of the notice and not decoration.
🔒 CIQRA's determination — the rule, drafted for P2's build
This is written as a general clause rather than two repairs, because it was found twice in one day in two unrelated subsystems, and a rule that names only its two instances will be satisfied by fixing two instances. 🔑 The defect is never that a promise is wrong; it is that nobody compares what the platform SAYS it will accept with what it can actually receive.
A named channel is compliant only when all four hold. The fourth is the one that fails. ① It exists — an address, route or control is actually there. ② It is reachable by the named recipient, in the role they are in. 🔴 An operator-only endpoint is not a channel for a consumer; a mailbox nobody reads is not a reply address. ③ It carries enough to be acted on — a reference, an identifier, or a link that supplies one. A free-text "please stop it" with nothing to match it against is a puzzle handed to a stranger. ④ It is open for as long as the message implies, and ⚠️ no longer than the underlying act is reversible. A cancellation offered after the deletion has run is worse than none, because the record then says the subject could have stopped it.
Two measured instances (tree
8614e63f3, 2026-08-11T04:50Z) — both written up at 07 A.0c and 02 §8.3b: ⓐ the scheduled-erasure email invites a reply with noReply-To, no reference, and an operator-only cancel route — guarding an irreversible deletion; ⓑ four notice-decision texts, one of them the Art. 17 statement of reasons itself, invite a complaint through an internal complaint channel that does not exist.🔴 Two defences are pre-emptively refused, because both are available and both are wrong. ⓐ "We are exempt." DSA Art. 19(1) excuses a small enterprise from building the Art. 20 system. It says nothing about announcing one. 🔑 An exemption is a defence to an obligation, never to a statement. ⓑ "The mailbox is monitored, someone will see it." That answers ② and leaves ③ and ④ open, and it converts a stated right into a favour performed by whoever happens to read the message.
What the build must produce — a census first, then repairs. Every outbound text that proposes an action, in all twenty locales, classified as: route exists · sentence removed · route to be built, with a date. ⚠️ "Declared exclusion" is not available here: a locale can be left unopened, but a message already sent cannot be treated as unread.
⛔ What this clause does NOT do. It does not choose, for either instance, between building the route and deleting the sentence — both discharge it, and the choice is commercial. ⚠️ And one input is unmeasured: whether
privacy@,legal@andabuse@are provisioned as mailboxes. The zone's MX resolves (ciqra-com.mail.protection.outlook.com, measured 2026-08-11T04:52Z), which proves the domain accepts mail and not that those three names do. 🔑 An MX record answers "can this domain receive mail", and the question in this clause is "does this ADDRESS reach a person" — the first is cheap to check and is routinely mistaken for the second. These three are the set's statutory contact points (GDPR Art. 13, DSA notice-and-action, and §16.5 above), so they belong in the census as its first rows.
16.6 Language. The English version prevails, except where mandatory local law (e.g. the Turkish overlay) requires a local-language version to govern for that market.
CIQRA's determination: English-prevails is the right default for an EN-only set. The Turkish carve-out is no longer moot — the condition it was written against is met. Türkiye is a launch market (owner resolution 7, 2026-08-13) and the TR overlay is in force, so where mandatory TR law requires the Turkish text to govern for that market, it governs. The clause is kept rather than rewritten, because the general rule it encodes is unchanged: where mandatory local law requires a local-language version to govern, it will, regardless of what this clause says. Until 2026-08-13 this note recorded the carve-out as moot while the overlay was held back; that reading is retired — the clause was never conditional on CIQRA's plans, only on whether the market was entered.
Provision register (this document)
| Provision | Basis | Where |
|---|---|---|
| order of precedence | (B) Stripe agreements actually top the ladder on payment mechanics | §1.4 |
| merchant / customer eligibility | (B) ×2 — representations, not verified; no age gate found | §§2.1–2.2 |
| verification & sanctions | (B) screening is Stripe's; CIQRA's gate is a market check, not a sanctions screen | §2.4 |
| plans & prices | ✅ (A) measured structure + 14-day trial; ⚠️ prices illustrative, Stripe is authority | §3.2 |
| VAT | (B) unreviewed; VIES + invoice annotation unmeasured | §3.5(a) |
| no pro-rata refund | (B) micro-trader unfair-terms exposure unassessed | §3.5(d) |
| merchant of record | ✅ (A) measured direct-charge topology | §4.1 |
| no liability for merchant sales | (B) effect toward consumers unassessed | §4.2 |
| consumer information | (B) storefront support unmeasured; withdrawal button missing | §4.3 |
| SAQ A | ✅ (A) measured + ⚠️ v4.0.1 whole-site script requirement unassessed; AoC not completed | §4.5 |
| 14-day withdrawal | (B) single global default vs per-market unassessed | §4.6 |
| UGC | 🔴 (A) measured ABSENT — depends on the missing §7.4 mechanism | §5.4 |
| themes & templates | (B) third-party theme licensing not verified for the shipped set | §6.2 |
| prohibited categories | (B) enforced by Stripe + manual; jurisdiction-variable rows unreviewed | §7.1 |
| notice-and-action | 🔴 (A) measured ABSENT — present-tense claim, launch-blocking | §7.4 |
| — | (B) in force since 28.06.2025; no conformance assessment exists | §8.3 |
| — | (B) Art. 11 internal complaint-handling system not found | §8.4 |
| third-party integrations | 🔴 (A) measured list corrected: 4 US AI providers, no gateway, no SES | §9.1 |
| AI features | (B) + (A) Art. 50 marking implemented, enforcement not | §9.2 |
| disclaimer / carve-outs | (B) ×2 — VÕS standard-terms control unassessed; Art. 82 unaffectable | §§10.2, 11.3 |
| changes to Terms | (B) notice period unquantified — weaker than CIQRA's own commitments elsewhere | §14 |
| B2B forum | (B) arbitration option unspecified, therefore inoperable | §15.2 |
| B2C forum | (B) + EU ODR platform ceased operating 20 July 2025 — remove the reference | §15.3 |
| language | (B) TR carve-out live — TR is a launch market and overlay 09 is in force (2026-08-13) | §16.6 |
Composition: 4 measured facts · 19 declared positions · 3 corrections (§5.4/§7.4 absent mechanism, §9.1 integration list, §15.3 ODR).
End of Terms of Service . Cross-references: Merchant Agreement · Privacy · DPA · Refund/Chargeback/Reserve · TR overlay.