IN FORCE. See 00-README. Two things live here: Part A is a shopper-facing notice CIQRA shows on Storefronts to explain the CIQRA/Merchant/Stripe relationship; Part B is a model refund/return policy template CIQRA provides to Merchants to adopt and adapt.

Provider: CIQRA OÜ, Tallinn, Estonia · In force from: 2026-08-09 · Version: 1.0 · Adopted by: CIQRA OÜ

Key point: The Merchant is the seller and your contract is with the Merchant, not CIQRA. CIQRA provides the store software; Stripe processes payment. This document does not replace the Merchant's own terms and consumer-law obligations.

---

Part A — Shopper Notice (CIQRA-provided, shown on Storefronts)

Intended for a "Powered by CIQRA" / checkout footer or a linked notice. The Merchant's own terms, privacy notice and refund policy govern the purchase.

A.1 Who you are buying from. When you buy on this store, you are entering a contract with the store (the Merchant), who is the seller and merchant of record. CIQRA OÜ provides the e-commerce software the store runs on; CIQRA is not the seller and is not a party to your purchase.

A.2 How payment works. Payments are processed securely by Stripe. Card details are entered directly into Stripe's secure fields; the store and CIQRA never see or store your full card number. CIQRA does not hold your money — funds go to the store via Stripe.

A.3 Your consumer rights. Your statutory consumer rights apply against the store. If you are an EU/EEA consumer, this usually includes a 14-day right of withdrawal for distance purchases (with legal exceptions, e.g. made-to-order items, unsealed hygiene/health goods, and digital content/services you agreed to start immediately), plus statutory guarantees for faulty goods. The store must honour at least the legal minimum and may offer more. See the store's refund/return policy.

A.4 Refunds, returns, delivery, complaints. Requests about orders, refunds, returns, delivery, warranties and complaints are handled by the store under its published policy and applicable law. Contact the store using the details on its site.

A.5 Illegal content / product concerns. If you believe content or a product on this store is illegal or infringes rights, you can report it to the store and, for platform-level action, to CIQRA at abuse@ciqra.com (see the Acceptable Use Policy). For EU consumers, the EU Online Dispute Resolution (ODR) platform and your national consumer body are also available.

A.6 Data protection. For your order data, the store is the data controller; see the store's privacy notice. CIQRA processes that data as the store's processor (see the Privacy Policy and DPA).

---

A.9 🔴 Security claims on the checkout screen — PA-0402 · wording DECIDED, build OPEN

A Storefront must not tell a shopper more about payment security than CIQRA can show is true of that Storefront. Two rules, and both are about the shape of the claim rather than its subject: (i) a certification belongs to whoever holds it and must be attributed to them by name; (ii) an absolute claim ("never", "at no point") may only be shown where the fact behind it is enforced by something that fails when it stops being true.

🔒 CIQRA's determination — the same checkout screen makes two different promises

① Measured (lane/L @ ac0bda5a7, 2026-08-11; census of all 20 storefront string files, Ciqra.Api/Storefront/Data/ui-strings-*.json, key checkout.trust_encrypted):

wording	locales
"PCI-certified payment provider"	2 — en, tr
"card data never reaches our servers" (and its equivalents)	18 — all the rest

🔴 These are not translations of one another. The authoritative locale, en, does not make the claim that eighteen markets see, and the eighteen do not make the claim en makes.

Is the strong claim true today? Yes — measured, and conditionally. Storefront card fields are Stripe Elements mount points, not inputs: checkout-payment.liquid:100 is an empty div[data-stripe-field="cardNumber"] that Stripe fills with its own iframe, so the value is never posted to CIQRA. The platform's declared raw-PAN seam, IRawCardPaymentProvider / RawCardPaymentRequest (Ciqra.Modules.Payment/PaymentAbstractions.cs:103-119), is referenced only by its own declaration and a resolver comment — no implementer exists. Saved-card charges carry a StripePaymentMethodId and a StripeCustomerId, not card data.

Is the other claim true? Yes, of Stripe — and that is the defect. Stripe is PCI DSS certified; CIQRA is not. CIQRA holds an SAQ A self-assessment posture, which is an attestation a company makes about itself, not a certification a body confers on it. 🔴 A shopper reading "PCI-certified payment provider" on a store's checkout has no way to tell which company the certificate belongs to, and claiming an approval or endorsement that one does not hold is on the UCPD's blacklist (Dir. 2005/29 Annex I item 4) — a practice that is unfair in all circumstances, with no balancing test. The sentence is saved only by the words "payment provider", which is doing more work than two words should. Attribute it: name Stripe.

② Why the absolute claim is the riskier one even though it is true. The fact is conditional and per-configuration; the sentence is unconditional and platform-wide. Three ways it becomes false with nobody editing it: an implementer of IRawCardPaymentProvider appears; a Merchant connects a BYO gateway (§1.7 of the Merchant Agreement) whose flow CIQRA has not measured; or a native/local acquirer stops using the hosted/3DS path. 🔑 An unconditional promise resting on a condition nobody re-checks does not stay true — it stays printed.

③ Ruling — three parts. ⓐ One claim in twenty places. Whichever wording is chosen, the twenty locales say the same thing. Today, if the strong claim is right, en and tr undersell; if it ever goes wrong, eighteen markets carry a false security statement — and the platform has no way to notice, because nothing compares the twenty. Same class as the second copy and as PA-0392: a statement kept in twenty places is twenty statements. ⓑ If the absolute claim is kept, it must be gated. The SAQ A posture is already recorded as a monitored invariant (DPA §3): an implementer of IRawCardPaymentProvider moves the attestation from SAQ A to SAQ D. The shopper-facing sentence must be tied to the same trigger, so that implementing the interface breaks something rather than quietly making eighteen storefronts wrong. ⓒ The certification is attributed or dropped. "PCI-certified payment provider" becomes a named attribution or goes; it must not read as CIQRA's or the Merchant's certificate.

🔒 Owner decision 2026-08-11 — option (c): BOTH claims, and the certificate carries Stripe's name

The three options and their costs were put to the owner (register: INSA-KUYRUGU §📌①). The decision is (c), and the reason given is the one that matters legally as well as commercially: it is the only sentence that is true today, and naming Stripe does not conceal that CIQRA is not certified — it is what stops the sentence concealing it.

The sentence, in the authoritative locale. en is the source; the other nineteen are translations of it, not variants of it:

Encrypted checkout · card details never reach our servers; payments are processed by Stripe, a PCI DSS certified provider.

Four conditions, all of which are testable. A decision on wording that does not say how it is checked is a decision that will be half-applied:

	condition	how it fails visibly
①	Twenty locales, one claim. All 20 ui-strings-*.json carry a translation of the sentence above — not two different promises.	a census comparing the twenty, not their timestamps
②	🔴 The absolute half stays gated. "never reach our servers" is true conditionally; an implementer of IRawCardPaymentProvider must break the build or a test, exactly as option (b) required.	the SAQ A monitored invariant (DPA §3)
③	The attribution is to Stripe by name, never to CIQRA or the Merchant.	UCPD Annex I item 4 is not satisfied by a true certificate held by someone else
④	BYO gateway suppresses the sentence. A Merchant on their own gateway (§1.7 of the Merchant Agreement) is a flow CIQRA has not measured, so neither half may be shown.	the gate in ② must read the gateway, not only the interface

🔴 The gate is not optional because the claim moved. Option (b) was the gated one, and the gate travelled with the strong claim into (c) — the owner said so explicitly. 🔑 A condition attached to a sentence belongs to the sentence, not to the option it was first written under; choosing a different option does not discharge it.

⚠️ One word is deliberately NOT in the sentence: a LEVEL. Stripe is commonly described as a PCI DSS Level 1 service provider, and that may well be right — but CIQRA has not sourced it, and a level is a second factual claim about a third party. It may be added only with a dated source in 16-sources. 🔑 Attributing a claim to the right company does not make the claim measured; it only moves who has to be right.

⛔ What this does not close. The strings are not written yet, and ②/④ are build work, not text work — D and P own them. A turn that changes twenty strings and stops has satisfied ① alone, and ① alone is the half that looks finished.

⛔ What this determination does not do. It does not choose the wording — that is a product and commercial decision. ⚠️ And it was found by reading, not by a tool: the translation-freshness checker orders strings by date and cannot see that two dates agree while two sentences do not. 🔑 A staleness check answers "was this updated?"; nobody had asked "does it say the same thing?"

---

Part B — Model Refund & Return Policy (template for Merchants)

CIQRA's determination: Part A (the shopper-facing notice) is the only document in this set written for consumers, and its accuracy is measured. The statement that the Merchant — not CIQRA — is the seller follows from the payment topology: charges are created on the Merchant's own connected account with CIQRA taking an application_fee, not a destination charge (Payments/Stripe/CiqraPayStripeProvider.cs:61,69; on_behalf_of/transfer_data absent repo-wide). Part B is a template CIQRA hands to Merchants, and CIQRA does not verify what any Merchant publishes. One dated gap affects both parts: the Estonian "withdraw from contract" button required from 01.09.2026 is not implemented — see Refund/Chargeback/Reserve Policy A.2 — so a Merchant cannot offer it through the storefront even if this template tells them to.

For Merchants: This is a starting template, not legal advice or a finished policy. You are the merchant of record and are responsible for a compliant refund/return policy for your goods/services, markets and customers. Fill the {{placeholders}}, adjust to your products and law, and have it reviewed. It must meet at least the mandatory consumer law of the markets you sell to.

CIQRA's determination: CIQRA supplies this template but does not review, approve or verify what any Merchant publishes, and no platform mechanism checks that a Storefront has a refund policy at all. The template is drafted to the EU baseline (14-day withdrawal and its exceptions); a Merchant selling outside the EU is given no market-specific guidance here, while 00-README §3 commits CIQRA to global availability from launch.

B.1 Right of withdrawal (EU/EEA consumers)

If you are a consumer in the EU/EEA, you may withdraw from a distance purchase within 14 days without giving a reason, starting the day you (or a third party you name) receive the goods (or the last item, for multi-item orders), or the day of contract for services/digital. To withdraw, tell us by a clear statement (you may use the model withdrawal form, or the online "withdraw from contract" button where provided). We will refund all payments (including standard delivery) within 14 days of being informed, using the same payment method, and may withhold the refund until we receive the goods back or proof of return. You bear the direct cost of returning the goods unless we state otherwise. (Estonia: from 01.09.2026 an online withdrawal button is required for consumer distance contracts.)

Exceptions (no withdrawal right): made-to-order/personalised goods; sealed goods unsealed after delivery for health/hygiene reasons; goods that deteriorate quickly; and digital content/services where you expressly asked us to begin during the withdrawal period and acknowledged you would lose the right. {{adjust exceptions to your products}}

B.2 Returns & refunds (our policy)

• Return window: {{e.g. 14 / 30 days}} from delivery. (Must be ≥ statutory minimum where a consumer withdrawal right applies.)
• Condition: items must be {{unused / in original packaging / with tags}} unless faulty.
• How to return: {{instructions / address / RMA process}}.
• Refund method & timing: to the original payment method within {{X}} days of {{receiving the return / approving the request}}.
• Return shipping cost: {{customer pays / we pay / free over €X}}.
• Exchanges: {{policy}}.

B.3 Faulty, damaged or wrong items (legal guarantee)

Separate from any voluntary policy, consumers have statutory guarantee rights for goods that are faulty or not as described. If your item is faulty, damaged or incorrect, contact us within {{period}} and we will offer repair, replacement, or a refund as required by law. Statutory rights are not affected by this policy.

B.4 Non-returnable items

{{list, e.g. perishable goods, personalised items, gift cards, downloaded software/digital goods once accessed}} — consistent with the legal exceptions in B.1.

B.5 How to contact us

{{Merchant legal name, address, email, phone}}. EU consumers may also use the EU ODR platform ({{link}}) and their national consumer/ADR body.

B.6 Payments & who is responsible

Payment is processed by Stripe; we (the Merchant) are the seller and are responsible for refunds, which are issued via Stripe against the original payment. The platform provider (CIQRA) is not the seller.

---

End of Shopper Notice & Refund Template . See: Refund/Chargeback/Reserve Policy · Terms of Service §4 · Payment Terms.