Merchant Agreement
IN FORCE. See 00-README. This Agreement supplements the Terms of Service; on payment/merchant matters it prevails over the ToS. An Enterprise MSA, if signed, prevails over both.
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Ü.
Between: CIQRA OÜ, registry code 16465907, Veskiposti tn 2, Kesklinna linnaosa, Tallinn, Harju maakond, 10138, Estonia ("CIQRA") and the business that registers a Merchant account ("Merchant", "you"). Effective: on acceptance at onboarding / continued use. In force from: 2026-08-09 · Version: 1.0 · Adopted by: CIQRA OÜ
⛔ §3.1 (commission) is NOT IN FORCE. The rates in earlier drafts were never decided by CIQRA and have been withdrawn; commercial terms are notified separately (pricing page / Order Form). No commission rate is stated, owed or enforceable under this Agreement. Everything else in this Agreement is in force. See §§3.0–3.1.
1. Scope and role of the parties
1.1 This Agreement governs your use of CIQRA to operate a Storefront and, where enabled, to accept payments through CIQRA Pay. The Payment Terms (CIQRA Pay) form part of and are incorporated into this Agreement and set out the regulatory characterisation of CIQRA Pay; on payment matters, read this Agreement together with them.
1.2 You are the merchant of record. For every sale on your Storefront, you — not CIQRA — are the seller and merchant of record. You contract directly with the Customer, and you are responsible for the goods/services, pricing, taxes (incl. VAT/OSS), fulfilment, returns, warranties, refunds, and all consumer-, product-, and sector-law obligations. CIQRA provides software and payment facilitation only.
1.3 CIQRA Pay is built on Stripe Connect — measured. CIQRA Pay uses Stripe Connect (direct charge): payments from your Customers are charged directly to your Stripe connected account, and CIQRA applies a platform fee (application_fee) representing its commission/spread. CIQRA is a platform enabling payments; it is not a bank, payment institution, money transmitter, or escrow agent, and it does not take custody of your settled funds.
The topology in §§1.2–1.3 is measured, not asserted (2026-08-09, lane/L @ 81807dc44):
| Fact | Evidence |
|---|---|
| Connected accounts created as Express | Payments/Stripe/StripeConnectService.cs:62 — Type = "express" |
| Charge created on your account | Payments/Stripe/CiqraPayStripeProvider.cs:69 — RequestOptions { StripeAccount = account.StripeAccountId } |
CIQRA's fee rides as application_fee | CiqraPayStripeProvider.cs:61 — ApplicationFeeAmount = applicationFee |
| Not a destination charge | on_behalf_of / transfer_data absent repo-wide — the measurement that establishes CIQRA is never in the funds flow |
| Commission returned on refund | Payments/Stripe/StripePaymentOperations.cs:43 — RefundApplicationFee = true; pro-rata at StripePaymentEndpoints.cs:217 |
The code reaches the same conclusion in its own words: "Chargeback liability sits with the seller in the direct model" (CiqraPayStripeProvider.cs:14). This closes the payment-liability question as a matter of fact; the regulatory characterisation built on it remains unreviewed — see Payment Terms §1.
1.4 Stripe agreements (mandatory; you must accept before transacting). CIQRA Pay requires you to enter into and remain bound by Stripe's agreements — the Stripe Services Agreement (SSA) and the Stripe Connected Account Agreement (SCAA) (which incorporates the SSA), together with Stripe's Prohibited & Restricted Businesses list. You must accept the correct Stripe service agreement through CIQRA's onboarding before your connected account can process any transaction, and keep it accepted and in compliance. Those agreements are between you and Stripe and govern the payment relationship; on any conflict about payment mechanics (charges, settlement, payouts, disputes, reserves, fund recovery), the Stripe agreements prevail over this Agreement. If Stripe suspends, restricts, or terminates your connected account, or you have not accepted or fall out of compliance with the Stripe agreements, CIQRA Pay for you is suspended or terminated accordingly and CIQRA may block your ability to transact. [Approach: Stripe SSA/SCAA mandatory-acceptance & precedence flow-down.]
CIQRA's determination: the Stripe-agreement precedence and flow-down wording mirrors what Stripe requires of Connect platforms. This reconciliation did not verify that onboarding actually blocks transacting until the Stripe agreement is accepted — the clause states that as a fact to the merchant. What is measured is that a charge cannot be created before Stripe enables the account:
CiqraPayStripeProvider.cs:45-48throwsPaymentProviderNotConfiguredExceptionunlessaccount.ChargesEnabled. That is Stripe's gate, not CIQRA's acceptance gate, and the two are not the same control.
1.5 Relationship with Stripe; no misrepresentation. CIQRA is a Stripe Connect platform, not a bank, payment institution, money transmitter, or acquirer, and does not itself process card payments. You must not misrepresent your (or CIQRA's) relationship with Stripe, present CIQRA's fees as Stripe's or vice versa, or use Stripe's name or marks except as Stripe permits. Stripe (and, where relevant, card schemes and other payment providers) are intended third-party beneficiaries of the provisions of this Agreement that concern them and may enforce those provisions. [Approach: Stripe SCAA §4.2 fee-separation + third-party-beneficiary flow-down.]
CIQRA's determination: the third-party-beneficiary construction is drafted to mirror Stripe's flow-down requirement. A contract in favour of a third party is recognised by Estonian law, and this stipulation 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).
1.6 Payment network rules prevail. Card-scheme and payment-network rules, and Stripe's rules, apply to your transactions and supersede any conflicting term of this Agreement to the extent required.
CIQRA's determination: card-scheme rules are not published in full to merchants, so this clause incorporates terms neither party can read in their entirety. That is standard market practice. The incorporation 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); a scheme rule that a Merchant could not reasonably have known of does not bind that Merchant beyond what those rules allow.
1.7 Alternative (BYO) gateway. If instead you connect your own payment gateway, that provider's terms govern the payment relationship, CIQRA does not take a payment spread on those transactions, and the CIQRA-Pay-specific clauses (fees, payout, reserve, chargeback handling) apply only to CIQRA Pay.
2. Onboarding, KYC and eligibility
2.1 You must complete onboarding, including identity/business verification and beneficial-ownership (KYC/KYB) information required by CIQRA and Stripe, and keep it accurate and current. As an online platform, CIQRA is subject to trader-traceability duties under the DSA before you can sell.
CIQRA's determination: no separate trader-traceability mechanism was found. CIQRA relies on Stripe's KYC/KYB as the identity check (
StripeConnectService.cs:60-72creates the Express account and requests capabilities; Stripe collects and holds the documents). DSA Art. 30 places the duty on the online platform, specifies the data points, and requires best-efforts assessment of the information's reliability (Legal Basis Register row 2.1). CIQRA's determination is that Stripe's onboarding does not by itself discharge Art. 30, and that the obligation is CIQRA's own. Relying on a payment provider's KYB to satisfy a platform-regulation duty is a common assumption and not obviously correct. The earlier wording asserted CIQRA "must also collect and verify" this data, which reads as a description of a control CIQRA operates; it does not operate one.
2.2 You must be an eligible business (ToS §2) and must not operate a prohibited business (see Acceptable Use Policy). CIQRA and Stripe may screen you against sanctions/watchlists and may refuse, suspend, or terminate onboarding.
2.3 You are responsible for the security of your account and for your users, staff and integrations.
2.4 Sanctions, AML & prohibited jurisdictions. You represent and warrant, on a continuing basis, that you, your business, your beneficial owners and your goods/services are not the target of, and you will not use CIQRA Pay in violation of, applicable EU, US (OFAC), UK or UN sanctions, anti-money-laundering, counter-terrorist-financing or export-control laws, and that you are not established or operating in a prohibited/embargoed jurisdiction. CIQRA and Stripe may screen you and your transactions and may freeze funds, suspend, or terminate where required by such laws, by Stripe, or by a card scheme (including the card networks' MATCH/terminated-merchant listings). [Approach: Stripe SSA sanctions/AML + scheme MATCH-list flow-down.]
CIQRA's determination: sanctions and watchlist screening is performed by Stripe, not by CIQRA — no screening code exists in the platform. What CIQRA implements is a jurisdiction gate at onboarding:
StripeConnectService.cs:50-57refuses CIQRA Pay for unsupported countries viaStripeSupportedCountries.IsSupported, with an explicit message directing the merchant to bank transfer, cash on delivery or installments. That is a supported-market check, not a sanctions screen, and the two should not be conflated. Whether CIQRA is itself an obliged entity under Estonian AML law (RahaPTS) is determined as stated above — see Retention A.2.1.
2.5 Change-of-business notification. You must promptly notify CIQRA (and keep your Stripe account information current) of any material change to your business, including a change of control/ownership or beneficial owners, legal form, business model or product mix, name, bank/settlement account, contact or registered address, a materially adverse financial event (e.g. insolvency, bankruptcy, administration), or any regulatory action, so that CIQRA and Stripe can reassess risk and compliance. [Approach: Stripe SCAA change-notification duty.]
3. Fees — commission / spread
3.0 🔴 The published schedule and the implemented calculation do not agree
🔴 CIQRA's determination — the rates were never decided, and adoption is what made that dangerous. The table formerly in §3.1 described a plan-tiered commission with a fixed per-transaction component and two surcharges. No such schedule was ever agreed by CIQRA, and none of it is implemented. It has been withdrawn from force (§3.1).
The measurement below is retained because it remains the operative fact about what the platform charges.
Measured (
lane/L@81807dc44): the platform fee is computed asamountMinor × PlatformFeeBps / 10000at both charge sites —Payments/Stripe/CiqraPayStripeProvider.cs:53andPayments/SavedCards/SavedCardStripeService.cs:186.PlatformFeeBpsis a single platform-wide configuration value with a default of 200 (= 2.0%) (Payments/Stripe/StripeOptions.cs:19).grep -rn 'PlatformFeeBps' src/ tests/returns those three source lines and three test lines — the merchant's plan is never read when the fee is calculated.For the record, this is what the withdrawn figures would have meant against what the code actually charges — retained because it shows the exposure adoption created:
Withdrawn draft figure (never agreed) What the code charges Exposure adoption would have created Entry ≈ 1.4% + €0.05flat 2.0%, no fixed component Merchant overcharged on percentage Growth ≈ 0.9% + €0.05flat 2.0% Merchant overcharged ~2.2× Pro ≈ 0.4% + €0.05flat 2.0% Merchant overcharged ~5× non-EEA card +1.5%not applied CIQRA undercharged FX conversion +1%not applied CIQRA undercharged No fixed per-transaction component exists anywhere in the fee computation (
grepfor a fixed/per-transaction fee returns nothing), and no card-origin or currency-conversion surcharge is applied.Why withdrawal was the only safe move. §3.1 was a fee schedule inside a contract a Merchant accepts at onboarding. Once in force, charging a different rate would breach it against every Merchant on Growth or Pro, and the divergence grows with volume. But correcting §3.1 to match the code was equally wrong, because 2% was not a decided rate either — it is a configuration default (
StripeOptions.cs:19), not a commercial decision. A number with no measurement behind it, no legal article behind it and no owner decision behind it cannot stand in a document that is in force in any form. The commercial terms are therefore notified separately, and this Agreement no longer states a rate.
PlatformFeeBpsbeing operator-configurable does not change this: it is one value for the whole platform, so no configuration could have produced three plan rates.
3.1 Commission — ⛔ NOT IN FORCE
⛔ NOT IN FORCE — commercial terms to be notified separately
The figures in this section were never decided. They stood in the working draft as placeholders and were carried into the 2026-08-09 adoption. Adoption converted them from placeholders into commitments, which is exactly what they must not be. They are therefore withdrawn from force as of 2026-08-09.
What applies instead: CIQRA's commercial terms — commission rates, per-transaction components and any surcharges — are notified separately and take effect only when CIQRA has published them on its pricing page or stated them in an Order Form accepted by the Merchant. No rate in this section is charged, owed or enforceable.
The remainder of this document remains in force. Only this section is withdrawn.
CIQRA Pay commission is charged per successful transaction as an application_fee on top of Stripe's own processing fees. The rate is not set by this Agreement. It is the rate published on CIQRA's pricing page or stated in your Order Form at the time of the transaction.
The table below is retained only as a record of what the withdrawn draft said, so that a Merchant who read an earlier version can see precisely what has been withdrawn. It is not a fee schedule and nothing in it is payable:
| Plan | Withdrawn draft figure — not in force, not payable |
|---|---|
| Entry | |
| Growth | |
| Pro | |
| Enterprise | Negotiated rate, stated in the Order Form / MSA |
Surcharges — ⛔ not in force. non-EEA / international cards +1.5%; currency conversion +1% (pass-through) — never decided, withdrawn. Any surcharge that CIQRA applies will be stated on the pricing page or in the Order Form before it takes effect. Digital wallets (Apple Pay / Google Pay) are priced as the underlying card.
Measured 2026-08-09: neither surcharge is applied by the fee calculation, and no fixed per-transaction component exists in code — consistent with their withdrawal above.
3.1a The rate you are quoted is the rate that will be charged. Where CIQRA states a commission rate in an Order Form and you accept it, that rate is the rate CIQRA charges on your transactions from the effective date stated in that Order Form.
🔴 CIQRA's determination — §3.1a is a commitment the platform cannot presently keep
① Measured (
lane/L@c12bb9733, 2026-08-10). The platform fee is computed at two charge sites and both read the same single value:
site expression source of the rate interactive checkout amountMinor * _options.PlatformFeeBps / 10000Payments/Stripe/CiqraPayStripeProvider.cs:53saved-card / off-session charge amountMinor * _stripe.PlatformFeeBps / 10000Payments/SavedCards/SavedCardStripeService.cs:186
PlatformFeeBpsis a single property onStripeOptionswith a default of 200 (= 2.00%) (Payments/Stripe/StripeOptions.cs:19), bound from the"Stripe"configuration section and injected everywhere asIOptions<StripeOptions>— a process-wide singleton (CiqraPayStripeProvider.cs:22,SavedCardStripeService.cs:34,StripeVaultGateway.cs:89).🔴 And the plan has nowhere to put a rate.
PlanDefinition(Billing/PlanCatalog.cs:17–25) carriesCode,Name,Tagline,MonthlyEur,AnnualMonthlyEur,IsSelfServeandEntitlements. There is no commission field on a plan, and no commission field on a tenant. So the defect is not that the fee calculation forgets to read the Merchant's plan — it is that there is nothing to read.🔑 The consequence is not "the wrong rate is charged". It is that one rate is charged to everyone, so the platform cannot charge two Merchants differently even if it has promised to.
② Rule of law / of contract. The instrument that binds here is this Agreement, not an external one. §3.1 was withdrawn precisely by pointing the rate at the Order Form; §3.1a is what that pointer commits CIQRA to. Charging 2.00% to a Merchant whose Order Form says anything else is a breach of CIQRA's own term — and because CIQRA Pay uses Stripe Connect direct charge (§1.3), the fee is taken as an
application_feeout of funds settled to the Merchant's own connected account. An overcharge is therefore not an invoicing error to be corrected later; it is money already deducted from the Merchant's balance. The two directions are not symmetric: undercharging costs CIQRA revenue, overcharging takes the Merchant's money without a contractual basis.⚠️ P2B is cited elsewhere in this set for this obligation — see §8.3a. Its applicability has never been measured, so it is not relied on here. The contract above binds regardless of how that question resolves, which is why it, and not the Regulation, is the anchor.
③ Commercial choice — and the reason this moved to the front of the queue. As at 2026-08-10 CIQRA is issuing price offers to existing customers. An accepted Order Form is exactly the event §3.1 names as the moment a rate takes effect. Until now the absence of any published schedule meant there was no rate to contradict — a gap is consistent until it is filled. The first signature fills it.
What must be true before an Order Form stating a commission rate is signed — either: (a) the rate offered is exactly the rate the platform charges today (2.00% at both sites), and the Order Form says so in those words; or (b) the fee calculation reads a per-Merchant rate at both sites before the Order Form's effective date. There is no third option in which a rate is promised and the platform is left to catch up, because the charge happens on the Merchant's first transaction after the effective date, not at some later reconciliation.
🔒 OWNER DECISION 2026-08-11 — exit (a) taken. §3.1a is satisfied by the OFFER, not by code.
The determination above set out two ways to make §3.1a true and the owner chose the first: every Order Form states the commission as exactly 2.00%, which is what the platform charges today at both sites. No code is required, and offers can be signed now.
🔴 The cost was stated before the decision and was accepted: a negotiated commission rate is not possible. Every Merchant is on 2.00% until the fee calculation reads a per-Merchant rate. If a Merchant asks for 1.5% on volume, the answer is no — and that is not a negotiating stance, it is an absent capability. 🔑 A commercial constraint that comes from an engineering fact is still a commercial constraint, and it is met at the table, not in the repository.
Three drafting rules follow, and they are what actually keep §3.1a true: ① The Order Form states the figure,
2.00%. ⚠️ Not "standard commission", not "our published rate" — a pointer re-creates the original defect without naming it, because the pointer's target can change while the platform cannot. ② The Order Form states the charge basis in the same line: per successful transaction, as anapplication_feeon top of Stripe's own fees (§3.0/§3.2). ③ 🔴 A change to the rate is a change to the platform, not to a document. Until a per-Merchant rate exists,PlatformFeeBpsis global: changing it for one Merchant changes it for all of them. So a later concession to one Merchant is a breach of everyone else's Order Form. This is the sentence to re-read before agreeing to anything on a call.PA-0354 stays open — the exposure is closed for today's offers, the mechanism is not, and the next Merchant who needs a different rate reopens it in full. Template: Order Form.
⛔ How this closes wrongly. By fixing
CiqraPayStripeProvideralone. That is the interactive checkout path; saved-card and off-session charges go throughSavedCardStripeServiceand would keep charging the global default — silently, and to the Merchants most likely to be on a negotiated rate, because they are the ones with repeat and stored-card volume. 🔑 A fee correction that lands on one of two charge paths is not half-correct; it is a system that charges two different rates to the same Merchant.
3.2 Stripe fees are separate. Stripe's processing fees are set by Stripe and are additional to (or, depending on configuration, netted alongside) CIQRA's commission. The total effective cost to you is CIQRA commission + Stripe fees + any surcharges.
3.3 Subscription fees. Your plan's recurring subscription fee is billed under the Terms of Service §3 (paid tiers; no free plan; auto-renew; no pro-rata refund). ⚠️ Where you prepay a term in advance, the no-pro-rata rule covers a Merchant who chooses to leave; it does not apply where CIQRA restricts or suspends you on fair-use grounds — in that case the unused portion of the prepaid term is refunded pro rata (ToS §3.7). Where an Order Form states the fee in a currency other than EUR, that currency is the currency of the invoice for the fees it covers; CIQRA does not convert it at an unstated rate.
3.4 Fee changes. CIQRA may change commission rates or surcharges on 30 days' prior notice (immediately where a change is required by Stripe, a card scheme, a bank, law, or to address fraud/security). Continued transacting after the effective date is acceptance; you may stop using CIQRA Pay before then. [Approach: Shopify/Stripe 30-day fee-change-notice standard.]
3.5b Payments are free and clear of withholding — gross-up. All amounts payable to CIQRA under this Agreement are payable free and clear of, and without deduction or withholding for, any tax. If you are required by law to deduct or withhold any amount from a payment to CIQRA, the sum payable is increased so that CIQRA receives, after the deduction or withholding, the amount it would have received had no deduction or withholding been required. You make the deduction, pay it to the tax authority within the time allowed by law, and on request give CIQRA evidence of the payment. This clause applies to every Merchant, in every country; it is not specific to any one jurisdiction.
3.5c Treaty relief — CIQRA's side of it. Where a double-taxation treaty reduces the rate that must be withheld, CIQRA will supply a current Estonian certificate of tax residence, and any notarised or apostilled translation the treaty procedure requires, so that you can apply the treaty rate rather than the domestic one. ⚠️ Request it before the first payment falls due — in most procedures the reduced rate cannot be applied retrospectively to a payment already made.
3.5d Turkish Merchants — VAT specifically. If Turkish law requires you, as the recipient, to account for VAT on this supply, you do so under your own registration and CIQRA does not charge Turkish VAT.
🔒 CIQRA's determination — why the gross-up clause is general, and why the certificate is not optional
③ Commercial choice — the clause is written for every country, not for Turkey. The question arrived as a Turkish one, and drafting it as a Turkish one would have been the mistake: withholding on cross-border service fees is an ordinary feature of many tax systems, and a clause that names one country tells the next country's Merchant that their case was not thought about. 🔑 A term that answers only the question you were asked will be reopened by the second Merchant.
② Why gross-up rather than absorption. CIQRA quotes one fee to every Merchant. If withholding came out of CIQRA's side, the same quoted number would yield a different revenue in each jurisdiction, and the price list would silently stop meaning one thing. ⚠️ The cost does not disappear — it lands on the Merchant, so it belongs in the offer and not in the small print. A Merchant who discovers at invoice time that the fee has grown has been surprised by their own contract.
① Why §3.5c is a clause and not a courtesy — measured. Under KVK 5520 Art. 30 a payment abroad for intangible rights bears 20%; the Turkey–Estonia treaty Art. 12(2)(b) caps it at 10%, and the Revenue Administration is explicit that the treaty rate is not automatic: without an Estonian certificate of residence, domestic law applies (Legal Basis Register rows 5.3–5.4). 🔴 So with the gross-up clause in place, the certificate does not protect CIQRA — it protects the Merchant, by halving what they have to gross up. That is why §3.5c is an obligation CIQRA takes on rather than a favour it offers, and why the timing warning is in it.
🔒 CIQRA's determination — the Turkish VAT is cost-neutral for a Merchant who can deduct
② Rule of law. A service supplied by a provider with no residence, place of business, legal seat or business centre in Turkey, but used in Turkey, is within Turkish VAT (KDVK 3065 Arts. 1 and 6(b)), and the tax is declared and paid by the recipient in a responsible capacity on the No. 2 VAT return (Art. 9). 🟢 The Revenue Administration's ruling on exactly this fact pattern — cloud and e-mail services from an EU-resident supplier — states the other half too: that VAT may be deducted on the No. 1 return for the same period (Art. 29). (Legal Basis Register row 5.3.)
🟢 So for a VAT-registered Merchant making taxable sales this is a cash-flow entry, not a cost — a stated fee does not become a fifth larger in real terms. ⚠️ The condition has to be said out loud: it holds only where you are entitled to deduct. A Merchant who is not VAT-registered, or whose own supplies are exempt without credit, carries the VAT as a real cost.
⛔ Nothing here is a Turkish tax opinion, and it is not offered as one. The rulings cited are the administration's answers to other taxpayers on their own facts, and in Turkish practice a ruling binds only its applicant. Your own certified accountant (SMMM/YMM) should confirm your position before you rely on the deduction above.
3.6 Metered add-ons — you can see the counter you are billed from. Where CIQRA offers an optional add-on charged by measured usage (today: AI features), (a) the add-on is opt-in and the Services work without it; (b) the charge is computed from a usage counter recorded per Merchant; (c) that counter is visible to you for the billing period, itemised by what generated it, before the charge falls due; and (d) if the counter is unavailable for a period, CIQRA does not estimate it — the period is not billed on that add-on. CIQRA does not charge by usage on any dimension it does not meter per Merchant (ToS §3.7a).
🔒 CIQRA's determination — why the meter, not the price, is the clause
① Measured. AI is the only one of six per-tenant cost axes with a real meter —
AiUsageRecord/AiUsagePeriod, itemised by Feature, Capability, Provider, Model, KeySource and Outcome, with quota viaAiCreditBalance/AiCreditGrant(lane R,FIYAT-TABANI.tsvC-030). That is exactly why AI is the one thing that can honestly be priced by use, and it is the reason this clause exists here rather than as a general metering clause.② Rule. A usage charge is a claim about a quantity. The Merchant can only accept or dispute it if they can see the quantity, so (c) is not a courtesy — it is what makes the charge arguable, and a charge that cannot be argued with cannot fairly be imposed. (d) closes the other half: an estimated counter is a charge presented as a measurement, and once estimation is permitted the meter stops being the source of truth and becomes a starting point.
③ Commercial. (a) opt-in matches CIQRA's existing position that AI features are opt-in and default-off; a metered add-on that is on by default converts a Merchant's inattention into a bill.
🟢 And (c) is not aspirational — it is measured.
GET /ai/usage(Ciqra.Modules.Ai/Endpoints/AiAdminEndpoints.cs:107-109) returns the current period's summary with a per-feature breakdown — requests, blocked calls, input and output tokens, and billed micro-USD (Application/AiUsageMeter.cs:148-176). Two details in that code are the difference between a view and an argument the Merchant can actually make: refused calls are shown rather than folded into the total, and credits are rounded once per feature rather than per call, so a feature made of many sub-credit calls is not inflated into a figure the Merchant never spent. ⚠️ Read from source, not from the socket — L holds no tenant credential; that the route exists and what it returns is established, that a signed-in Merchant reaches it is not.⚠️ What this clause does not cover. A per-unit price for AI has not been decided; when it is, it is notified under §3.1 like any other rate — and §3.1a applies to it in the same terms, because a metered add-on quoted in an Order Form is a quoted rate.
3.5 Taxes on fees (VAT). CIQRA fees are exclusive of VAT. CIQRA is VAT-registered in Estonia (VAT/KMKR no. EE102934712). CIQRA's subscription and commission are electronically supplied services: for EU business Merchants, the reverse charge applies (no Estonian VAT; you self-account under Art. 196; CIQRA validates your VAT ID in VIES and shows both VAT IDs + "reverse charge" on the invoice); for EU non-business recipients, destination VAT via OSS; for non-EU Merchants, outside EU VAT scope. Provide and keep current a valid VAT ID where you have one. See ToS §3.5(a).
CIQRA's determination — ② rule of law. The VAT treatment above is applied under Directive 2006/112/EC and the Estonian Käibemaksuseadus (Legal Basis Register row 5.2): CIQRA's subscription and commission are electronically supplied services; for EU business Merchants the reverse charge applies and the Merchant self-accounts, for EU non-business recipients CIQRA accounts through OSS, and supplies to non-EU Merchants are outside EU VAT scope. Estonian VAT is 24% from 01.07.2025. Two implementation points are measured rather than assumed, and neither was verified in the 2026-08-09 reconciliation: that VIES validation runs at onboarding, and that invoices carry both VAT IDs and the "reverse charge" annotation. Both are stated to Merchants as facts in §3.5, so both must be confirmed against the running system before an invoice relies on them.
4. Payouts
4.1 Rolling payout (Stripe standard). Settlement of your sales, net of Stripe fees, refunds, CIQRA commission, reserves and any amounts you owe, is paid to your linked bank account on a rolling schedule (T+N) consistent with Stripe Connect's standard payout timing. New EEA connected accounts are typically subject to an initial hold of about 7 days before the first payout, after which payouts roll (e.g. T+2/T+7 depending on Stripe/risk configuration).
CIQRA's determination: payout timing is entirely Stripe's, set on the connected account, not by CIQRA. The "~7 days initial hold" and "T+2/T+7" figures describe Stripe's standard behaviour and are not values CIQRA sets or can measure from its own source tree. They should be presented as Stripe's schedule, not as CIQRA's commitment.
4.2 Minimum payout / thresholds — measured, and the answer is "none". Settlement of sales proceeds runs Stripe → your connected account on Stripe's schedule; CIQRA does not impose a separate minimum-payout threshold beyond Stripe's applicable minimum, and any balance below Stripe's threshold carries to the next cycle.
✅ Measured 2026-08-09: this claim is confirmed. A search across
ciqra-saas/srcfor a payout minimum or threshold (PayoutMinimum,MinimumPayout,PayoutThreshold) returns no implementation. The only payout code paths are thepayout.paidwebhook handler and ledger recording (Payments/Stripe/StripePaymentEndpoints.cs:133,290-306) — CIQRA observes payouts, it does not gate them. There is no CIQRA-added threshold to reconcile against the technical configuration.
4.3 CIQRA discretion. CIQRA may change payout frequency, delay a payout, or route settlement differently where required for risk, fraud, chargeback exposure, verification, legal/AML reasons, or by Stripe/a bank/authority. Where practicable and lawful, CIQRA will notify you.
4.4 Netting / set-off. CIQRA (and Stripe) may deduct from your balance or future payouts: Stripe fees, CIQRA commission, refunds and reversals, chargebacks and related fees, reserve amounts, taxes CIQRA must withhold, and any other amounts you owe CIQRA. If your balance is insufficient, §7 (negative balance) applies.
4.5 Currency & FX. Payouts are made in your settlement currency; currency conversion (if any) uses the applicable rate plus the disclosed FX surcharge. Multi-currency support and FX snapshotting are provided where enabled.
⚠️ The FX surcharge is not applied by the fee calculation — see §3.0. Multi-currency handling itself is real (amounts are converted using each currency's true ISO-4217 exponent rather than a hardcoded ×100,
CiqraPayStripeProvider.cs:52, and ECB rates are referenced in source), but the +1% FX surcharge in §3.1 has no implementation.
5. Reserve (risk-based / conditional)
🔴 CIQRA's determination: no reserve mechanism exists in the platform. The only occurrence of the concept in the payments code marks it as future work — "reserve/risk = F1.O-06" (
Payments/Stripe/CiqraPayStripeProvider.cs:14). There is no code that sets, holds, releases, accounts for or displays a reserve.§5 is retained because Stripe's Reserves mechanism requires the platform's reserve policy to be disclosed in its Terms before a reserve can be applied — removing it would foreclose the option. But §5.1's opening words, "CIQRA operates a risk-based, conditional reserve", describe a running system and are not accurate today. Read §5 as the terms that would govern a reserve if one were imposed, which would presently have to be arranged manually through Stripe. Full treatment: Refund/Chargeback/Reserve Policy C.0.
5.1 When a reserve applies. CIQRA operates a risk-based, conditional reserve. A reserve is not applied to low-risk Merchants by default. CIQRA may impose or adjust a reserve where risk signals warrant, including: elevated or rising chargeback/refund/fraud rates; high-risk or long-fulfilment business models (pre-orders, deposits, tickets, travel, subscriptions); sudden volume spikes; disputes, investigations, or verification gaps; or a requirement from Stripe, a bank, card scheme, or authority.
⚠️ No mechanism — see the note opening §5. The triggers listed are a declared standard, not signals the platform computes. Merchant risk flags are explicitly manual: "context for a human, never automatic enforcement" (
Ciqra.Modules.Operator/Domain/OperatorRiskFlag.cs:20,27). No chargeback, refund or fraud rate is calculated anywhere.
5.2 Reserve mechanics (③ commercial choice, owner-confirmed; no mechanism yet — see the note opening §5). A reserve may be structured as (a) a rolling reserve — typically up to 10% of processed volume held for a rolling 90 days and then released (the exact percentage and period are set to the assessed risk and disclosed to you); (b) a fixed/minimum reserve — a set amount held; and/or (c) an up-to-100% hold on specific funds where fraud or serious risk is suspected. CIQRA will tell you the type, amount/percentage, trigger and expected release conditions when a reserve is set, except where notice would undermine fraud prevention or breach law/scheme rules. [Approach: Stripe/PayPal risk-based rolling-reserve norm (≈5–10% / 90–120 days).]
5.3 Purpose & release. The reserve secures your obligations (refunds, chargebacks, reversals, fees, negative balance, indemnities). Reserved funds are released when the risk period lapses and no offsetting liability remains, subject to ongoing exposure.
5.4 No interest accrues on reserves unless required by law.
CIQRA's determination: a no-interest term on withheld Merchant funds 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 Estonian law requires interest on funds withheld from a Merchant, CIQRA pays it; the clause excludes interest only to the extent the law leaves the matter to the parties. Withholding funds without interest is an area where mandatory rules and unfair-terms control can bite.
Full mechanics are in the Refund/Chargeback/Reserve Policy.
6. Refunds and chargebacks (summary — see doc 08)
6.1 Refunds are the Merchant's responsibility. As merchant of record, you decide and issue refunds consistent with your published refund policy and mandatory consumer law (incl. the EU 14-day withdrawal right and its exceptions). Refunds are processed via Stripe against the original charge and deducted from your balance/payout. On a full refund, CIQRA returns its commission (application_fee) to you (refund_application_fee=true); on a partial refund, the commission is returned pro-rata to the refunded amount. Stripe's own processing fees are set by Stripe and may not be returned.
✅ Measured 2026-08-09: the commission return is real and is not configurable —
RefundApplicationFee = trueis hardcoded atPayments/Stripe/StripePaymentOperations.cs:43, andStripeOptions.csrecords the reason in a source comment: it is hardcoded "so Stripe and the ledger can never drift". Pro-rata on partial refunds is computed atStripePaymentEndpoints.cs:217asrefund.Amount / charge.Amount × ApplicationFeeAmount. This clause is accurate.
6.2 Chargebacks. A Customer's card issuer may reverse a charge (chargeback/dispute). The disputed amount plus any scheme/Stripe dispute fee is debited from your balance. You are responsible for chargebacks on your sales and for submitting evidence to contest them; CIQRA provides tooling but does not guarantee outcomes. Excessive chargebacks may trigger reserve, suspension, or termination.
⚠️ The debit follows from the measured topology (§1.3: charges live on your connected account, so that is where a dispute debit lands). The enforcement limb is a reserved right exercised manually — no chargeback ratio is computed by CIQRA, and no reserve mechanism exists (§5). See Refund/Chargeback/Reserve Policy B.4 and C.0.
6.3 CIQRA is not liable for your chargebacks/refunds. Except for CIQRA's own error, refund and chargeback liability for Storefront sales sits with you.
6.4 Liability for losses (direct-charge model). Because CIQRA Pay uses Stripe direct charges to your connected account, you are the party primarily liable to Stripe and the card networks for refunds, disputes/chargebacks, reversals, fines and negative balances on your transactions. Depending on the technical configuration, either (a) these amounts are debited directly from your connected-account balance by Stripe, or (b) CIQRA, as the platform, is designated to collect and bear such losses in the first instance (loss/liability "collector") and then recover them from you under §§6–7 of this Agreement. Where CIQRA is the designated collector, your repayment, set-off, reserve and negative-balance obligations to CIQRA apply in full. [Approach: Stripe Connect losses/liability controller + application liability-collector options.]
CIQRA's determination: the branch between (a) and (b) is decided by a Stripe account setting (
losses_collector/losses.payments=stripeorapplication), not by a code path — so it could not be measured from the source tree. What the source shows is that accounts are created asType = "express"with no explicit loss-configuration parameter (StripeConnectService.cs:60-72), meaning the setting inherits whatever the platform account carries. This must be read off the live Stripe account and this clause collapsed to the branch that is actually true. Leaving both branches in force is the drafting equivalent of not knowing: it tells the merchant their obligations differ depending on a fact neither party has checked. In either branch the Merchant remains ultimately liable to reimburse.
7. Negative balance and recovery
7.1 If refunds, chargebacks, reversals, fees or reserves exceed your available balance, your account balance may go negative. You must promptly repay the shortfall.
7.2 CIQRA (and Stripe) may recover a negative balance by: withholding/offsetting current or future payouts and sales; drawing on the reserve; charging your linked payment method/bank on file; and, if unrecovered, pursuing the debt (including via collections) and charging reasonable recovery costs and statutory interest.
CIQRA's determination: contractual set-off, debiting a linked external account, and recovery of collection costs and statutory interest against a business counterparty 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). Note also that the "drawing on the reserve" limb presupposes a reserve mechanism that does not exist (§5).
7.3 The management-board members and beneficial owners do not personally guarantee the Merchant's obligations unless a separate guarantee is signed.
CIQRA's determination: this is a deliberate commercial choice in the Merchant's favour and is stated so the absence of a personal guarantee is explicit rather than inferred. It does not affect Estonian company-law duties of board members, and it does not limit any guarantee Stripe separately takes under the SCAA — a Merchant may owe Stripe personally on terms CIQRA does not control and cannot waive — a merchant may owe Stripe personally on terms CIQRA does not control.
8. Ledger, statements and taxes
8.1 CIQRA provides a transaction ledger and statements (sales, fees, refunds, chargebacks, reserves, payouts). You are responsible for reconciling them and for your own bookkeeping.
8.2 Your taxes. You are solely responsible for determining, collecting, reporting and remitting all taxes on your sales (VAT/OSS, sales tax, income tax, etc.) and for issuing compliant invoices to your Customers. CIQRA's tax-calculation, invoicing and VAT/OSS tooling is provided as an aid and does not constitute tax advice; you must verify it for your facts. Where a market overlay imposes local invoicing (e.g. TR e-fatura/e-arşiv), you must comply with it — see the TR overlay, which is in force — Türkiye is a launch market (owner resolution 7, 2026-08-13). For TR e-Fatura/e-Arşiv the issuance obligation is yours as the vergi mükellefi; CIQRA's tooling for that market is an open item closing under TR-03, and you must not rely on it until it is announced as available.
CIQRA's determination: the disclaimer that CIQRA's tax tooling "is provided as an aid and does not constitute tax advice" is the right framing, but this reconciliation did not measure what the tax-calculation and invoicing tooling actually computes. A merchant relying on it is relying on an unmeasured component.
8.3 Platform tax reporting (DAC7). 🔒 CIQRA has determined that it is not a Reporting Platform Operator under DAC7 (Directive (EU) 2021/514) on the product as it exists on 2026-08-10. The determination, its factual predicate and the two events that reopen it are set out immediately below. CIQRA may still ask a Merchant for tax identifiers where another obligation requires them, and will say which obligation when it asks; this clause does not, by itself, oblige a Merchant to supply DAC7 seller due-diligence data. If the determination is reopened, CIQRA will collect that data set (name, address, TIN/VAT ID, business registration number, consideration per quarter) from that point onward as part of onboarding, and would report Merchants (not shoppers) to the Estonian Tax and Customs Board (EMTA) annually by 31 January.
🔒 CIQRA's determination (2026-08-10) — out of scope, and here is what it rests on.
DAC7 reaches a platform that allows sellers to be connected to other users in order to carry out a relevant activity. The decisive question is therefore not a reading of the Directive but a fact about the product: is there any surface on which a shopper can discover, and transact with, more than one Merchant?
Measured, 2026-08-10: there is none. Each Storefront is its own brand's closed shop; discovery belongs to the Merchant, not to CIQRA. Even the machine-readable catalogue endpoint (
/agent/catalog.json) is tenant-resolved and opt-in — it exposes one Merchant's catalogue to a caller who already knows which Merchant it is asking about, which is the opposite of a discovery surface. On that predicate the correct characterisation is software a seller uses to run its own shop, and CIQRA is out of scope.⚠️ The "we only process payments" exclusion is NOT what CIQRA relies on, and could not be: CIQRA supplies the storefront, the catalogue and the payment together. The exclusion relied on is the absence of a connecting surface, nothing else.
🔴 This determination has an expiry, and it is an EVENT, not a date. Two changes reopen it, and each reopens it in full:
- Marketplace selling lands. The product already anticipates this in writing —
Storefront/Themes/default/checkout-order-items.liquid:6records that "when marketplace selling lands it becomes per-line without a layout change." 🔑 The trigger therefore already sits in a file the change itself would touch, which is the only place a trigger reliably survives.- A discovery surface across Merchants is built — a cross-tenant search, a marketplace, a CIQRA-branded shopping app or feed. The test is the same one asked above; nothing about the wording of this clause needs to change for the answer to flip.
What the reopening costs, so it is not discovered late: seller due-diligence data is collected at onboarding and cannot be produced retrospectively. Adding a field before the first Merchant costs nothing; adding it afterwards means going to every Merchant individually. The cost of an obligation is multiplied by when you look at it.
🟢 The comparison that was missing has since been measured (2026-08-10), and it tests the determination without carrying it.
- Shopify draws the same line, in its own words, and draws it by PRODUCT. Its terms never use "platform operator" and place tax responsibility on the merchant ("You are solely responsible for determining, collecting, withholding, reporting, and remitting applicable taxes", ToS §5.8). But its help centre calls itself an online marketplace for one product and one only: "This law imposes certain obligations on online marketplaces, including the Shop app." The core store is not given that label; the discovery app is. 🔑 That is the same boundary this determination turns on — reached independently, by the largest comparable platform, about its own product.
- ⚠️ Read it for what it is. Shopify's admission is made under the US INFORM Consumers Act, not under DAC7. It therefore shows how a comparable operator separates store from marketplace; it does not show how anyone reads the Directive. The distinction is what is being tested here, not the statute.
- İkas offers no signal in either direction. Its user agreement is silent on platform-operator or reporting status, and Türkiye is outside DAC7's scope in any event. 🔑 An out-of-scope company's silence is not evidence that the obligation is light; it is not evidence at all, and is recorded as such.
And the factual predicate now rests on three measurements taken by different methods, which matters more than any of them alone: the agent endpoint reads as tenant-resolved and opt-in (source); no cross-Merchant discovery surface exists (product review); and reads that bypass the tenant filter (
IgnoreQueryFilters) occur in five files, none of them Catalogue, Storefront or Search — so a cross-tenant discovery query is not merely absent from the UI, it is not built. A referee that uses the same method as the claim it is checking is a second opinion, not a check.This is a scope determination, not tax advice, and no tax adviser has reviewed it. PA-0357.
8.3a Platform-to-business regulation (P2B) — scope DETERMINED; applicability is per-Merchant and time-limited (PA-0389).
⬛ CIQRA's determination — "there is no determination here yet" · SUPERSEDED 2026-08-11, kept because it is the finding that produced the answer
🔒 **Allocated 2026-08-11 as PA-0389. Shape: the same as §8.3 (DAC7) — the measurement is L's, the determination is the owner's. 🔴 And the measurement's direction is stated by name so the owner is not surprised by it: the likely answer is the opposite of §8.3's. DAC7 asked whether the platform knows and facilitates the consideration and the answer was no; P2B asks only whether the platform enables the offering, and on the retrieved text of Art. 2(2) the answer looks like yes.
This set already relies on Regulation (EU) 2019/1150 (P2B) in several places — Art. 3 (plain and intelligible terms; ≥15 days' notice of change), Art. 4 (statement of reasons; ≥30 days for termination) and Art. 11 (internal complaint-handling, with a small-enterprise exemption). Those obligations were retrieved and recorded (Legal Basis Register row 2.2). Its predicate — whether CIQRA is an online intermediation service at all — never was.
⚠️ 🔴 And the DAC7 determination one clause above must not be read across. §8.3 concludes that CIQRA is not a marketplace for DAC7 purposes. A reader arriving at P2B will carry that answer over. The two predicates are different, and on the text they point opposite ways. Art. 2(2) requires a service that (a) is an information society service, (b) "allow[s] business users to offer goods or services to consumers, with a view to facilitating the initiating of direct transactions between those business users and consumers", and (c) is provided under a contract with those business users. Nothing in (b) requires the offer to appear on CIQRA's own consumer-facing surface — the word intermediation is in the title, not in the test. A hosted storefront under the Merchant's own domain appears to satisfy (a), (b) and (c) on their face. 🔑 Two questions that both sound like "are we a marketplace?" are not the same question; DAC7 asks whether the platform knows and facilitates the consideration, P2B asks only whether it enables the offering.
🟢 Retrieval limit DISCHARGED 2026-08-10T18:46Z — and the mirror was missing the decisive clause
The declared limit above (mirror at
legislation.gov.uk, EUR-Lex unreachable on five attempts) is now closed: the Official Journal text was retrieved fromeur-lex.europa.euCELEX 32019R1150 (OJ L 186/57, 11.7.2019). 🔴 The two texts are not the same, and the difference goes to the question. Art. 2(2)(b) in the Official Journal reads, in full:"they allow business users to offer goods or services to consumers, with a view to facilitating the initiating of direct transactions between those business users and consumers, irrespective of where those transactions are ultimately concluded;"
The mirror's text ended at "consumers". The trailing clause is precisely the answer to the strongest argument for being out of scope — that the shopper transacts on the Merchant's own domain rather than on any CIQRA surface. The Regulation says that does not matter. 🔑 The declared limit was not a formality: the sentence the mirror omitted was the sentence the determination turned on. An abridgement reads exactly like the full text right up until the clause you needed is the missing one.
⚠️ Tool note, because "unreachable" was never true of the source.
WebFetchreturned empty five times; a plaincurlto the same URL returned 192 522 bytes on the first attempt. 🔑 A source being unreachable is a fact about the instrument you tried, not about the source — and a retrieval failure repeated five times with one tool is one measurement, not five.What follows for the set today — three things, and none of them is "drop P2B": ① The P2B citations elsewhere are more likely right than wrong, but for a reason nobody had written down; a citation whose predicate is unmeasured is a citation that cannot be defended when challenged. ② 🔴 The order matters, and it was written the wrong way round until 2026-08-11. Art. 11's small-enterprise exemption (Rec. 2003/361/EC) was described as what limits exposure today. It is not: it is the second question. If CIQRA is not an online intermediation service, Art. 11 never arises; if it is, the exemption decides only whether that one obligation applies, and Arts. 3 and 4 apply regardless of size. 🔑 An exemption inside a regime you have not established you are in is not a defence — it is a defence rehearsed for the wrong hearing. Scope first, exemption second. ⚠️ And the exemption needs only a THRESHOLD answer, not a figure: whether CIQRA is under 50 staff / EUR 10m, not what its headcount is. Recorded so nobody blocks on producing an exact number that the test never asks for. ③ 🔴 No closing criterion may rest on P2B alone. Where an obligation matters, it must also be anchored in an instrument whose application to CIQRA is measured, or in this Agreement itself — which is why the fee commitment sits at §3.1a on the contract, not on Art. 3.
🔒 Determination, 2026-08-11 — on the Official Journal text the tension is RESOLVED, and the limiter is somewhere else entirely
① Art. 2(2) is satisfied on its face. (a) CIQRA is an information society service; (b) it allows business users to offer goods to consumers irrespective of where the transaction concludes — the merchant's-own-domain argument is answered by the text itself; (c) it is provided under a contract with those business users, which is this Agreement. 🔴 The
application_feeargument does not survive either: nothing in (a)–(c) asks who takes the money or whether the platform is principal. That was a DAC7 reflex, and it is the read-across the paragraph above warns against — written by the same hand that wrote the warning.② 🔴 The real limiter is Art. 1(2), and it was never in this section. The Regulation applies to services provided to business users "that have their place of establishment or residence in the Union and that … offer goods or services to consumers located in the Union". Both limbs are cumulative, and both are about the Merchant, not about CIQRA — whose own place of establishment is expressly irrelevant. Today's Merchants (reklam5, seyante, hedefoto) are Turkish-established, so on the measured facts the Regulation does not currently apply to those relationships.
⚠️ This is the weakest kind of good news, and it is recorded as such. The limiter is per-Merchant, not per-platform, and it is temporary by design: 00-README §3 commits CIQRA to global availability, so the first EU-established Merchant selling to EU consumers brings that relationship into scope on the day they sign, with no code change, no announcement, and nothing that notices. 🔑 A scope test that today's customers happen to fail is not an exemption — it is a countdown whose clock nobody is watching.
③ The Art. 11 exemption — owner's answer, recorded as a RULING and not as a figure. 🔒 Owner decision 2026-08-11: "CIQRA is a small enterprise within the meaning of the Annex to Recommendation 2003/361/EC." That sentence is the record. The threshold behind it (fewer than 50 staff, turnover under EUR 10 million) was confirmed by the owner; 🔴 the figures appear neither in this Agreement nor in any published page, because Art. 11(5) asks whether the threshold is met, not what the numbers are. 🔑 Publishing a number invites a challenge to the number; publishing the ruling invites a challenge to the ruling, which is the thing you can actually defend.
⚠️ Two precision notes, so nobody "corrects" this later from half a memory. ⓐ Art. 11(5) says "small enterprises within the meaning of the Annex to Recommendation 2003/361/EC" — it does not cite Art. 2(2) of that Annex. The owner's formulation names Art. 2(2), which is where the small-enterprise definition actually sits: more precise than the Regulation, not different from it. ⓑ The exemption disapplies Art. 11 only. Arts. 3 and 4 apply regardless of size, so if ②'s limiter ever lapses, plain-and-intelligible terms, the 15-day change notice and the 30-day termination statement of reasons apply immediately — and those are drafting obligations this set already meets, which is why the scope answer changes the risk without changing the text.
⛔ What remains open, and it is only one thing. Whether to build Art. 11's internal complaint-handling system before the exemption lapses is a commercial call, not a legal one — see the provision drafted for it at §8.3b. Nothing else in this section is waiting on the owner.
8.3b Internal complaint-handling — TWO different systems, and CIQRA is exempt from BOTH today (② Reg. (EU) 2019/1150 Art. 11(5); Reg. (EU) 2022/2065 Art. 19(1) — Legal Basis Register rows 2.2b, 2.4).
🔒 CIQRA's determination — drafted for P2's build, and the answer is "do not build it, stop promising it"
🔴 First, they are not one system. The set uses one phrase for two obligations with different claimants, different instruments and different triggers. Conflating them produces a channel that serves neither:
P2B Art. 11 DSA Art. 20 Who complains Business users (Merchants) Recipients, incl. anyone who submitted a notice About what non-compliance, technical issues, the provider's measures decisions to remove / restrict / suspend / demonetise Exemption Art. 11(5) — small enterprises Art. 19(1) — micro and small enterprises Exempt today Yes Yes The exemption, stated once for both. 🔒 Owner determination 2026-08-11: CIQRA OU is a small enterprise within the meaning of the Annex to Recommendation 2003/361/EC (see §8.3a ③). Art. 11(5) disapplies the P2B system; Art. 19(1) disapplies DSA Section 3 entire — Arts. 20 to 28 — with one exception, below.
⚠️ What the exemption does NOT reach, and this is the part that gets missed: ⓐ DSA Art. 24(3) survives Art. 19(1) expressly. On request from the Digital Services Coordinator of establishment or the Commission, the average-monthly-active-recipients figure must be communicated without undue delay. It is a duty to answer, so its cost is zero until the day it is not. ⓑ Arts. 16 and 17 are in Section 2, not Section 3, and are NOT exempt. The notice mechanism and the statement of reasons apply at any size — which is why they are built (
POST /legal/notice;POST /tenants/{id}/trust/notices/{noticeId}/decide) and must stay built. ⓒ Art. 19(1) second subparagraph: the exemption survives loss of status for 12 months. A grace period, not a cliff.🔴 But the platform is already TELLING people the channel exists
Measured (
lane/L, 2026-08-10T18:46Z, tree3dbefdf56). Four texts promise it:email-strings-en.json:231(notice_decided_rejected),:237(notice_decided_restricted),:262(the Merchant's own statement of reasons), andNoticeAndActionService.cs:66, which puts the sentence inside the Art. 17 statement of reasons itself — "You may contest this decision through CIQRA's internal complaint-handling channel."⛔ There is no such channel. A census of
MapPostacross the API finds intake (/legal/notice) and decision (…/notices/{id}/decide, operator-only) and no route by which a complainant can contest anything. 🔑 An exemption you are entitled to is not a defence to a promise you made anyway: Art. 19 excuses you from building the channel, and excuses nothing about announcing one.⚠️ And the promise is not merely untrue — it is load-bearing. The same sentence lists the two real alternatives (a certified out-of-court body, a court), both of which run on time limits. A reader who chooses the first-named option and waits has been steered, by CIQRA, away from the two routes that work. 🔑 A false channel is worse than a missing one, because a missing one sends people to the real remedy on the first day.
Ruling — a choice of two, and both are cheap. The choice is commercial; making one is not optional. ① Build it — a route, a six-month window from notification (Art. 20(2)), a reversal duty (Art. 20(4)), a reasoned reply naming out-of-court settlement (Art. 20(5)), and a human decision-maker (Art. 20(6)). Voluntary, so the shape is CIQRA's, but once announced it should meet what it announces. ② Delete the sentence from all four sites and leave the two real remedies. ⚠️ Four sites, twenty locales — same arithmetic as PA-0402, and the same failure mode if only the English is edited.
🔴 What must NOT happen is the third option nobody chooses on purpose: the sentence stays because deleting it looks like a downgrade and building it looks like work.
⛔ What this does not close. ⓐ The expiry event is written at §8.3d. ⓑ The verdict machine
Ciqra.Modules.Trust/P2BSmallEnterprise.csstill computesUndeterminedfrom three null figures and therefore still reports the duty as owed — correctly, by its own conservative design, and now disagreeing with the owner's ruling. Reconciling it is a build item, and ⚠️ it must not be done by typing the owner's figures into a source file: the owner's rule is that the ruling is the record and the numbers are not published. What the machine needs is a way to carry "the test was applied by the owner on 2026-08-11 and returned Small" with its provenance — not the three inputs. 🔑 A mechanism that can only accept evidence in one form will make you publish the thing you decided not to publish.
8.3c Whoever reports illegal content is a data subject, and CIQRA is their controller (② GDPR Arts. 13, 5(1)(e); Reg. (EU) 2022/2065 Art. 16).
🔒 CIQRA's determination — the second half of the notice mechanism, drafted for P2
POST /legal/noticeaccepts a report, and Art. 16(2)(b) requires a notice to carry the submitter's name and email (except for certain offences). So the mechanism compels personal data as a condition of the remedy working — and the party that decides why it is held and how long is CIQRA, not the Merchant. 🔴 This is a controller role that arrives without anyone choosing it, and it is the one place in this set where the Merchant is not the controller of Storefront-adjacent data.Four things the reporter is owed, and the fourth is the one that bites: ① Art. 13 information at the point of collection — who the controller is (CIQRA OU), why (assessing the notice and evidencing the assessment), and on what basis. ⚠️ Not the Merchant's privacy notice: the form sits on the Merchant's domain, so the reader's default assumption is the wrong controller. ② The other side sees it. Art. 17's statement of reasons goes to the Merchant, and a notice's substance can identify its author even when the name is withheld. The reporter must be told that before submitting, not comforted by silence. ③ A retention period — Art. 5(1)(e). A notice register with no clock keeps reporter identities indefinitely, and its purpose ends when the decision and its challenge window do. ④ 🔴 A rights request from a reporter reaches the DSAR path in §A.0/A.0c of the Retention Policy, which is keyed to a Merchant's customer. A reporter is neither a Merchant nor a Merchant's customer. 🔑 A data subject who does not fit the shape of your erasure endpoint still has the right; the shape is your problem, not theirs.
⛔ Not measured here: whether the notice form displays any privacy information today, and whether the notice register is swept by any of the five clock-deleters. Both are build questions for P2 and both are stated as questions rather than assumed to be failures.
8.3d When the two exemptions in §8.3b end — the event, not the date.
🔒 A recorded exemption without its expiry is half a record. Recommendation 2003/361/EC Annex Art. 4(2): status changes only where the thresholds are exceeded (or fallen below) in two consecutive accounting periods — so a single strong year changes nothing, and two do. DSA Art. 19(1) then adds 12 further months before Section 3 applies.
What ends it, in the order the events actually arrive: ① A second consecutive accounting period over 50 staff or over EUR 10 M → both exemptions lapse (P2B Art. 11 immediately; DSA Section 3 after the 12-month grace). ② Designation as a very large online platform (DSA Art. 33) → Art. 19(2) removes the exemption irrespective of size. Remote, and cheap to write down once. ③ ⚠️ Neither event has an owner or a review date. The trigger is the owner's year-end accounts, which no mechanism in this repository reads. 🔑 An exemption expires on an event; if nobody owns the event, what you have recorded is not an exemption but the date you last agreed with yourself.
8.4 VAT "deemed supplier" (Art. 14a) — allocation (② Directive 2006/112/EC Art. 14a; the €150 import consignment threshold is set by law, not by CIQRA — Legal Basis Register row 5.2). For the standard case — an EU-established Merchant as merchant of record selling via Stripe direct charge, with CIQRA taking a platform fee and not acting as principal — CIQRA is outside the EU VAT "deemed supplier" rule (Art. 14a VAT Directive), and VAT on your sales is your responsibility. However, for flows involving a non-EU-established seller selling goods to EU shoppers, or imported consignments ≤ €150, the platform may be deemed the supplier for shopper-facing VAT; CIQRA may restrict such flows or require additional handling. [Approach: VAT Directive Art. 14a; Implementing Reg. 282/2011 Art. 5b.]
CIQRA's determination: the conclusion that CIQRA is outside Art. 14a in the standard case rests on the measured direct-charge topology (§1.3): CIQRA does not act as principal and never possesses the funds. That factual predicate is solid. The legal characterisation has not been confirmed by tax counsel, and the exception is the live risk: CIQRA serves global markets from launch (00-README §3), so a non-EU-established seller shipping goods to EU shoppers, or an imported consignment ≤ €150, is not a hypothetical — it is a configuration a merchant can create at signup. No mechanism was found that detects or restricts such flows. The clause reserves the right to restrict them; nothing implements it.
9. Data protection
9.1 For personal data of your Customers processed through your Storefront, you are the controller and CIQRA is the processor; the Data Processing Agreement governs that processing and is incorporated here. For payment processing, Stripe acts as an independent controller/processor per its own terms. CIQRA is a controller for Merchant account, billing, security and platform-operation data (see Privacy Policy).
9.2 You must have a lawful basis and proper notices/consents for the Customer data you collect, must honour data-subject requests for which you are responsible, and must configure marketing consent (double opt-in) correctly.
10. Compliance, prohibited use and enforcement
10.1 You must comply with the Acceptable Use Policy, the ToS, Stripe's rules, card-scheme rules, sanctions/AML law, consumer and product law, and the tax and data-protection obligations above.
10.2 Suspension/termination and fund handling. CIQRA may suspend CIQRA Pay, hold funds, impose a reserve, or terminate for risk, breach, fraud, excessive disputes, verification failure, or as required by Stripe/a bank/authority. On termination, outstanding fees, chargeback exposure and reserves are settled before any final release of funds, and a 180-day tail may be retained to cover late chargebacks/refunds before final release. [Approach: card-scheme chargeback windows (≈120–180 days) → 180-day tail.]
CIQRA's determination: suspension, fund holds and the 180-day tail are rights CIQRA reserves and would exercise manually. The reserve limb has no mechanism (§5); the tail would be operated through Stripe by hand. The 180-day figure is derived from card-scheme chargeback windows and is a reasonable ceiling, but it is not enforced or tracked by any platform timer.
11. Warranties, liability, indemnity
11.1 You warrant that your business, products and content are lawful, accurately described, and compliant, and that you will not use CIQRA Pay to facilitate prohibited or fraudulent activity or to process payments for third parties (no payment aggregation/factoring) except as expressly permitted.
CIQRA's determination: the no-aggregation / no-factoring warranty is load-bearing for the regulatory characterisation in Payment Terms §1 — a merchant processing third-party payments through its connected account would undermine CIQRA's technical-service-provider position as well as breaching Stripe's terms. No mechanism detects it. It is enforced, if at all, by Stripe's monitoring and by manual review.
11.2 Liability. The limitation-of-liability and disclaimer provisions of the Terms of Service §§10–11 apply to this Agreement, except that amounts you owe under the fee, refund, chargeback, negative-balance and reserve provisions are not subject to the liability cap and remain fully payable.
11.3 Indemnity. You indemnify CIQRA (ToS §12) for claims and losses arising from your sales, chargebacks, refunds, content, tax, or breach.
12. Term, changes, governing law
12.1 This Agreement runs while you use CIQRA/CIQRA Pay and survives (for settlement, reserve, chargeback and recovery purposes) until all obligations are discharged.
12.2 CIQRA may amend this Agreement on notice (ToS §14); material payment-term changes take effect on 30 days' notice (immediately where required by Stripe, a card scheme, a bank, law, or to address fraud/security).
12.3 Governing law & disputes: Estonian law; Harju Maakohus (Tallinn) or arbitration for B2B disputes, per ToS §15 (hybrid model).
CIQRA's determination: the choice of Estonian law and a Tallinn forum for B2B disputes follows CIQRA's establishment and is the conventional choice. It has not been reviewed for enforceability against merchants established outside the EU — relevant because CIQRA serves global markets from launch — nor has the arbitration alternative been specified (seat, rules, language, tribunal). An unspecified arbitration option is not an operable dispute mechanism; either a set of rules is named or the option should be removed.
Provision register (this document)
| Provision | Basis | Where |
|---|---|---|
| ×6 (1.2, 1.3, 1.4, 5.1, 6.2, 6.4, 10.2) | (A) measured direct-charge topology closes the factual question; residual (B) on the Stripe losses setting | 1.3, 6.4 |
| trader traceability | (B) no mechanism; Stripe-KYB-discharges-Art.30 unassessed | 2.1 |
| sanctions/AML screening | (A) measured jurisdiction gate exists; (B) screening is Stripe's, obliged-entity status undetermined | 2.4 |
| commission schedule | ⛔ withdrawn from force — never decided; 2% PlatformFeeBps is a config default, not a commercial decision | 3.0–3.1 |
| VAT allocation | (B) standard reading, unreviewed; VIES + invoice annotation unmeasured | 3.5 |
| payout timing | (B) timing is Stripe's, not CIQRA's commitment | 4.1 |
| — | ✅ (A) measured — no threshold exists; claim confirmed | 4.2 |
| FX | (A) multi-currency real; +1% surcharge not implemented — and withdrawn from force with the rest of the draft schedule (§3.1) | 4.5 |
| ×3 (5.4, 7.2) | (B) enforceability of no-interest, set-off and recovery unassessed | 5.4, 7.2 |
| refund fee return | ✅ (A) measured hardcoded, non-configurable | 6.1 |
| no personal guarantee | (B) interaction with board duties / Stripe guarantee unassessed | 7.3 |
| merchant taxes | (B) tax tooling output unmeasured | 8.2 |
| DAC7 | ① measured 2026-08-10 — no cross-Merchant discovery surface exists (/agent/catalog.json is tenant-resolved and opt-in), so CIQRA determines it is out of scope; 🔴 reopened by either marketplace selling or a cross-Merchant discovery surface | 8.3 |
| Art. 14a deemed supplier | (B) factual predicate measured; no mechanism restricts non-EU / ≤€150 flows | 8.4 |
| no aggregation warranty | (B) load-bearing for §1 characterisation; no mechanism detects breach | 11.1 |
| governing law / arbitration | (B) arbitration option unspecified, therefore inoperable | 12.3 |
Composition: 5 measured facts · 14 declared positions · 1 direct conflict between a published term and the implementation (§3.0).
Launch gate for this document: §3.0 must be closed — by building the tiered calculation or by rewriting §3.1 — before this Agreement is presented to a merchant for acceptance. Every other open item is a visible position; §3.0 is a term that would be breached on the first transaction.
End of Merchant Agreement . See also: Refund/Chargeback/Reserve Policy · Payment Terms · DPA · Acceptable Use Policy.