Refund, Chargeback & Reserve Policy
IN FORCE. See 00-README. Part of the Merchant Agreement; relevant extracts inform Customers.
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Ü.
Provider: CIQRA OÜ, registry code 16465907, Veskiposti tn 2, Tallinn 10138, Estonia · In force from: 2026-08-09 · Version: 1.0 · Adopted by: CIQRA OÜ
This Policy explains, for CIQRA Pay (Stripe Connect, direct charge): (A) refunds on Storefront sales, (B) chargebacks/disputes, (C) the risk-based reserve, and (D) CIQRA's own subscription refunds.
The premise of this Policy is measured, not assumed. Because each Merchant is the merchant of record, refund/chargeback responsibility for Storefront sales sits with the Merchant, not CIQRA. That follows from the payment topology: charges are created on the Merchant's connected account (ciqra-saas/src/Ciqra.Api/Payments/Stripe/CiqraPayStripeProvider.cs:69) with CIQRA's fee riding as an application_fee (:61), and not as a destination charge — on_behalf_of and transfer_data are absent repo-wide. The code states the same conclusion: "Chargeback liability sits with the seller in the direct model" (CiqraPayStripeProvider.cs:14). Full measurement: Payment Terms §1.2.
A. Refunds on Storefront sales (Merchant → Customer)
A.1 Merchant sets and honours the refund/return policy. Each Merchant publishes its own refund/return policy on its Storefront, which must meet mandatory consumer law, including the EU 14-day right of withdrawal for distance contracts and its exceptions (made-to-order goods; sealed goods unsealed after delivery; digital content/services where performance began with the consumer's prior express consent and acknowledgement of loss of the withdrawal right). Merchants may offer more generous terms (hybrid model).
CIQRA's determination: the withdrawal-right exceptions above are stated at EU-directive level. Estonia implements them through the Law of Obligations Act (VÕS), and the platform enforces "the statutory minimum" as a single global default rather than per-jurisdiction. 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). Mandatory local consumer law overrides these terms wherever it is stricter.
A.2 Estonia "withdraw from contract" button (from 01.09.2026) — 🔴 not built. Estonian law will require an online "withdraw from contract" button for consumer distance contracts from 01.09.2026.
🔴 CIQRA's determination: an earlier internal version stated that "CIQRA provides storefront support for this". No such mechanism was found. A search across
.cs,.liquidand.jsoninciqra-saas/srcfor a withdrawal/cancellation button or right-of-withdrawal flow returns no implementation — the onlywithdrawmatches are unrelated (consent withdrawal, withdrawn invitations, a Stripe decline code).This is a dated obligation that falls before or around launch, not a future concern. Two things follow: the claim of storefront support is withdrawn from this document, and either the button ships before 01.09.2026 or Estonian consumer distance sales on CIQRA storefronts are non-compliant from that date. Because CIQRA is Estonian-established and its Merchants sell to EU consumers, this is not confined to one market overlay. Tracked as an open build item, not a drafting item.
A.2b In which languages the withdrawal function must exist — the ones a purchase can be MADE in. The withdrawal function must be available in every language in which the Storefront lets a consumer conclude the purchase. It is not required in a language the Storefront does not sell in, and offering it only in English is not sufficient for a Storefront that sells in another language.
🔒 CIQRA's determination — the ruling PA-0392 asked for, and it sizes the work
The question (from the translation lane, against the 01.09.2026 deadline): are the withdrawal strings required in all the platform's languages, or only in the ones a given Merchant trades in?
① Measured (
lane/L@c09e8216e, 2026-08-11): the storefront ships 20 UI string files —cs da de en es fi fr it ja ko nb nl pl pt-BR pt-PT sv th tr zh-CN zh-TW(Ciqra.Api/Storefront/Data/ui-strings-*.json). 🔴 Thewithdrawal.*keys exist in exactly one of them,en.② Rule of law. The duty is the Merchant's, not CIQRA's — the Merchant is the trader concluding the distance contract. Two things fix the language: ⓐ Dir. 2011/83 Art. 6(1) requires pre-contractual information "in plain and intelligible language", and Art. 6(7) expressly leaves language requirements for contractual information to Member State law — so there is no EU list of languages to satisfy, and no EU permission to use one. ⓑ The withdrawal function's own standard is that withdrawing must be as easy as contracting was. 🔑 That fixes the answer without needing a list: the contract was concluded in some language, so withdrawal must be possible in that language. The set is the languages checkout can be completed in — not the languages the CMS happens to hold, and not one.
③ So the size of the work is a choice, and both options are legitimate:
translate enabled locales only translate all 20 volume today 8 keys × the locales tenants actually sell in 8 × 20 = 160 strings, 152 outstanding 🔴 requires an enable-time gate: a locale cannot be switched on for a Storefront while its withdrawal.*keys are missingnothing further risk if the gate is skipped a locale enabled next month has no withdrawal surface, and 01.09.2026 does not care when it was enabled none on this axis 🔑 The gate is what makes the smaller option legal, and it generalises a sentence the measurement lane wrote: a baseline excludes the work added after it — and the law does not recognise the baseline's date. A one-off translation run is a baseline. Without an enable-time gate the only safe answer is all 20; with one, the honest answer is the ones you sell in, always.
④ 🔴 And a missing translation must never hide the control. If a locale reaches a consumer without
withdrawal.*, the function is still shown, falling back to the language the consumer was already being served. A fallback in the wrong language is a defect in Art. 6(1) clarity that the consumer can still act on; a hidden button is a statutory right denied, and leaves no trace. Same asymmetry as A.2a, and it decides the same way.🔒 Owner decision 2026-08-11 — the set is
tranden, so the work is 8 strings, not 152The Storefronts in scope today, and for the nine or ten Merchants now being offered terms, sell in Turkish and English.
enalready carries thewithdrawal.*keys, so onlytris translated — eight strings. A further locale,it, is added when that brand lands. 🔑 The ruling above did not pick a number; it named the test, and the test turned 152 into 8 as soon as somebody answered which languages a purchase can actually be made in. The measurement was cheaper than the translation.🔴 The remaining 17 locales are a DECLARED EXCLUSION, not an oversight, and the declaration has a condition: they may be enabled only behind the enable-time gate — a locale must not be switchable on for a Storefront while its
withdrawal.*keys are missing. ⚠️ Without that gate this decision expires silently: the exclusion is only safe while the excluded locales are unreachable, and nothing about 01.09.2026 changes if somebody enables Polish in October.🔴 Verification 2026-08-10T18:46Z — the SCOPE landed, the STRINGS did not
Measured directly, tree
3dbefdf56, by enumeratingwithdrawal.*keys in everyCiqra.Api/Storefront/Data/ui-strings-*.json:
locale withdrawal.*keys presenten(source)8 / 8 tr🔴 0 / 8 the other 17 0 / 8 — declared exclusion, conditional on the enable-time gate 🟢 What commit
41ce39ed8did do, and it was the right thing: it taught the gate the scope. The set now carriesdiller: ["tr"], prints out-of-scope locales asYURURLUK-DISLANDIrather than dropping them, and the arithmetic closes at 8 red + 144 declared = 152. It also corrected a figure D had published — the earlierYURURLUK=152predated the owner's decision.⛔ What it did not do is translate anything. 🔑 Scoping a gate and satisfying it are different acts, and the commit that does the first reads, in a log, exactly like the commit that does the second — "PA-0392 scope is 8, not 152" is a true sentence that a reader in a hurry will file as a closure. 8 strings remain owed on
tr, and the deadline they are owed against, 01.09.2026, has not moved.⚠️ And the declared exclusion is still standing on one leg. The 17 locales are safe only because they are unreachable, and the enable-time gate that makes them unreachable does not exist yet — no mechanism prevents a Storefront switching on Polish while
withdrawal.*is missing. Until it does,YURURLUK-DISLANDIrecords a decision, not a guarantee. 🔑 A declared exclusion is a promise about what nobody can do; without the thing that stops them, it is a promise about what nobody has done yet.🔒 Who writes the eight
trstrings — L writes them, D lands them. Here they are.The one-line answer to the coordinator: 🔑 this is not a translation job, it is a drafting job in another language — every one of the eight strings states the scope, the trigger or the duration of a statutory right, so a wording choice is a legal choice, and the lane that owns the obligation should own the sentence. D lands them; L is answerable for what they say.
Authoritative
trtext forwithdrawal.*, to be copied verbatim intoCiqra.Api/Storefront/Data/ui-strings-tr.json:
key trwithdrawal.headingCayma hakkı withdrawal.explainerBu alışverişten, teslim aldığınız tarihten itibaren 14 gün içinde, hiçbir gerekçe göstermeden cayabilirsiniz. Aşağıdaki düğmeyi kullanmanız yeterlidir — onayımıza gerek yoktur ve bu talebi reddedemeyiz. withdrawal.buttonCayma hakkımı kullan withdrawal.deadline{date} tarihine kadar cayabilirsiniz. withdrawal.no_deadline_yet14 günlük süreniz, sipariş size ulaştığında başlar. withdrawal.confirm_hintSaklayabileceğiniz bir onayı e-posta ile göndereceğiz. withdrawal.declared_headingCayma kaydedildi withdrawal.declaredBu alışverişten {date} tarihinde caydınız. Onayı e-posta ile gönderdik. Three drafting decisions, recorded so they are not "corrected" by someone reading only the English: ⓐ
tris a LANGUAGE, not a jurisdiction. The governing rule is Estonian (VÕS, transposing Dir. 2011/83 and (EU) 2023/2673), not the Turkish Mesafeli Sözleşmeler Yönetmeliği. The term "cayma hakkı" is correct under both, which is lucky; ⚠️ nothing else from the Turkish regime may be imported on the strength of the language tag. ⓑbuttonis not literal, on purpose. "Withdraw from this purchase" as an imperative reads oddly in Turkish; "Cayma hakkımı kullan" is the settled Turkish control label and names the right being exercised. 🔑 A literal translation that makes a consumer hesitate over the one control the statute requires is not the faithful one. ⓒ{date}placeholders are preserved exactly, including the brace form — a translated placeholder is a missing date, and it fails at run time in the one language nobody on the build side reads.🔴 And translating them found a defect in the ENGLISH source
withdrawal.explainersays the 14 days run "of receiving it", andno_deadline_yetsays they "start when the order reaches you." That is Art. 9(2)(b) — the rule for goods. For a service contract, Art. 9(2)(a) runs the period from the conclusion of the contract, which is usually the day of purchase. So a Storefront selling services shows a consumer a start point that is wrong in their favour or against it depending on delivery, and the countdown the button relies on inherits the error.⚠️ This is a defect in
en, the source, and it therefore reaches all twenty locales including the eight strings above — which is why they are drafted to match the source rather than quietly fixed here: 🔑 a translator who silently corrects the original leaves nineteen wrong copies and one that nobody can explain. The fix belongs inenfirst and needs a product answer — whether a Storefront can sell services at all, and if so whether the string is branched or generalised. Raised as a question, not patched. 🔑 Translating a sentence is the cheapest way to find out what it assumed.⛔ What this does not decide. Which locales any given Merchant has enabled is not measured here — it is per-tenant configuration, and the sizing above turns on it. And the function itself does not exist yet (PA-0353): 🔑 translating a surface into twenty languages does not build it in one.
A.2a Mixed orders — when one line is exempt and another is not, the withdrawal control is 🔴 SHOWN. Where a single order contains at least one item for which the consumer retains a right of withdrawal, the withdrawal function must be offered for that order. The exemptions do not become an order-level property because one line carries one.
🔒 CIQRA's determination — the third question of PA-0385
⚠️ The register carries PA-0385 as
GIRDI_YOK— the number exists, the claim text does not, so this ruling is the first thing written under it. The other two questions of PA-0385 are the build lane's and are not answered here.The question (raised by the build lane, referred here because it is not a code question): a consumer's order contains one item covered by an Art. 16 exception — say a sealed item unsealed after delivery, or digital content whose performance began with prior express consent — and one ordinary item. Is the "withdraw from contract" control presented?
② Rule of law. The right of withdrawal in Directive 2011/83/EU Art. 9(1) is a right to withdraw "from a distance or off-premises contract, without giving any reason", and Art. 16 removes it for specified contracts and specified goods — it does not remove it from a basket because a basket contains one of them. Nothing extinguishes the right for the ordinary item. Withholding the control would therefore deny a right the consumer still holds, and the Estonian withdrawal function exists precisely so that exercising it is as easy as concluding the contract was — a threshold that a consumer forced to identify their own eligibility does not meet.
The ruling — four parts: ① Show the control whenever at least one line is non-exempt. The order-level test is "any eligible line", never "all lines eligible". ② The function performs a partial withdrawal, covering the eligible lines. It must not silently withdraw the exempt line, and it must not refuse the whole order because of it. ③ The exempt lines are named, with their reason, at the moment of withdrawal — not only in the Merchant's published policy. A consumer who is told afterwards which half of their order came back has been told after the decision that needed the information. ④ 🔴 A missing exemption flag means WITHDRAWABLE. The exemption class is a per-product setting the Merchant maintains. If a product carries no setting, the line is treated as eligible. A default of "unknown → hide the control" converts a Merchant's unfilled field into a consumer's extinguished right, and leaves no record that it happened.
🔑 Why the default is to show, stated as the asymmetry it is. Presenting the control on an order that turns out to be wholly exempt costs a rejection message the consumer can read and argue with. Suppressing it on a mixed order costs a statutory right, silently, with nothing written down anywhere. The two errors are not comparable, so the tie does not need breaking on elegance.
⚠️ A second effect, easy to miss: under Art. 9(2)(b)(ii) the period for "multiple goods ordered by the consumer in one order and delivered separately" runs from possession of the last good. So a mixed order does not merely raise whether the control appears — it moves when it must still appear, and a per-line clock started at each line's own delivery would close the window early on exactly these orders. Retrieved 2026-08-10 (
legislation.gov.uk/eudr/2011/83/article/9; EUR-Lex unreachable — see Legal Basis Register retrieval log).⛔ What this determination does NOT settle. Whether any given product is exempt is the Merchant's classification, made against the Merchant's own facts; CIQRA supplies the field and the default, not the answer. And this ruling assumes the withdrawal function exists at all — it does not (A.2, PA-0353). 🔑 A rule about how a control must behave is not evidence that the control is there.
A.3 How refunds are processed. Refunds are issued by the Merchant (or CIQRA on the Merchant's instruction) via Stripe against the original charge, up to the captured amount, and are debited from the Merchant's balance/next payout (measured: refunds are executed against the connected account, Payments/Stripe/StripePaymentOperations.cs:53 — RequestOptions { StripeAccount = account.StripeAccountId, IdempotencyKey = … }). Statutory refunds must be made within the legal timeframe (generally 14 days of a valid withdrawal, subject to withholding until goods are returned or evidence of return is provided where permitted).
Note: the 14-day statutory refund deadline is a legal duty on the Merchant; no platform mechanism enforces or monitors it. See Retention A.0 for the general point that a period stated in these documents is not necessarily a period the platform enforces.
A.4 Fees on refunds — measured. CIQRA returns its commission to the Merchant on a full refund — measured: RefundApplicationFee = true (Payments/Stripe/StripePaymentOperations.cs:43) — and returns it pro-rata on a partial refund — measured: the returned fee is computed as refund.Amount / charge.Amount × ApplicationFeeAmount (Payments/Stripe/StripePaymentEndpoints.cs:217). Stripe's own processing fees are set by Stripe and may not be returned.
A.5 CIQRA's role. CIQRA provides refund tooling and records but is not a party to the Customer↔Merchant contract and is not liable for a Merchant's refund obligations, except for CIQRA's own processing error.
B. Chargebacks & disputes
B.1 What a chargeback is. A Customer's card issuer may reverse a payment (a "chargeback"/"dispute"). The disputed amount plus a scheme/Stripe dispute fee is debited from the Merchant's balance when the dispute is opened — which follows from the direct-charge topology: the funds are on the Merchant's connected account, so that is where the debit lands.
B.2 Merchant responsibility. The Merchant is responsible for chargebacks on its sales and for submitting compelling evidence (proof of delivery, terms accepted, communications) within the deadline. CIQRA/Stripe provide dispute tooling but do not guarantee the outcome; card networks decide.
B.3 Fees & liability. If a dispute is lost, the Merchant bears the transaction amount and the Stripe/scheme dispute fee; if won, the amount is returned (the dispute fee may or may not be refunded per scheme rules). Fraudulent-transaction losses on the Merchant's sales are the Merchant's risk under the direct-charge model (measured, see the premise above). CIQRA does not add a separate dispute-handling surcharge beyond the Stripe/scheme dispute fee, unless stated on the pricing page.
B.4 Excessive disputes — declared threshold, no automated monitor. High or rising chargeback ratios may trigger card-scheme monitoring programs and consequences. A Merchant approaching or exceeding the then-current Visa or Mastercard dispute-monitoring thresholds, or showing disproportionate fraud or refund rates, may be placed under review and subject to a reserve (Part C), additional verification, suspension, or termination.
⛔ Withdrawn: the ~0.75% figure. Earlier versions stated a ~0.75% CIQRA-specific early-warning threshold. That number was never decided by CIQRA — it was a draft margin below the scheme thresholds — and the platform does not compute it. It is withdrawn. The card-scheme thresholds referenced above are external and remain applicable, because they are set by Visa and Mastercard rather than by CIQRA.
[Approach: Visa VDMP / Mastercard ECM ~0.9%/100-dispute + Stripe early-warning thresholds.]
CIQRA's determination — ① measured. No chargeback-ratio calculation exists in the platform, and the merchant risk workflow is manual by design: a risk flag is "context for a human, never automatic enforcement" (
Ciqra.Modules.Operator/Domain/OperatorRiskFlag.cs:20,27). In practice a threshold breach is noticed through Stripe's monitoring, not CIQRA's. Merchants should not infer that CIQRA measures their ratio.
B.5 Backstop / pre-emptive refunds. To prevent or resolve disputes, reduce chargeback exposure, comply with consumer law, or meet Stripe/scheme requirements, CIQRA (or Stripe) may, in defined circumstances, issue or require a refund on a transaction — including where the Merchant is unresponsive to a valid Customer complaint or dispute — and debit the corresponding amount from the Merchant's balance/reserve. CIQRA will act reasonably and, where practicable, consult the Merchant first. [Approach: Paddle/Lemon Squeezy MoR + Stripe platform backstop-refund pattern.]
Note on capability: CIQRA can technically execute a refund on a connected account (
StripePaymentOperations.cs:43-53), so this right is operable — unlike the reserve in Part C. The "debit from reserve" limb is not, for the reason given in C.0.
C. Risk-based reserve
C.0 🔴 The reserve is a reserved right, not an operating control
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 reports a reserve, and no reserve balance a merchant could be shown.Part C is nonetheless retained in full, for a specific reason: Stripe's Reserves mechanism requires the platform's reserve policy to be disclosed in its Terms before a reserve can be applied. Removing the disclosure would foreclose the option. But disclosure is not capability. Until F1.O-06 ships, any reserve would have to be arranged manually through Stripe, and the notice, release-schedule and transparency commitments in C.3–C.5 would have to be honoured by hand.
Merchants should read Part C as the terms that would apply if a reserve were imposed, not as a description of a live system.
C.1 Conditional, not default. CIQRA applies a reserve only where risk warrants it; low-risk Merchants have no reserve by default. Triggers include: elevated/rising chargeback, refund or fraud rates; high-risk or long-fulfilment models (pre-orders, deposits, tickets, travel, subscriptions); sudden volume spikes; verification gaps; investigations; or a requirement from Stripe/a bank/scheme/authority.
C.2 Reserve types.
- Rolling reserve (③ owner-confirmed figure; no mechanism yet, see C.0) — typically up to 10% of processed volume held for a rolling 90 days, then released (exact percentage/period set to the assessed risk and disclosed).
[Approach: Stripe/PayPal rolling-reserve norm ≈5–10% / 90–120 days.] - Fixed/minimum reserve — a set amount held.
- Up-to-100% hold — on specific funds where fraud/serious risk is suspected.
C.3 Notice & transparency. When a reserve is imposed or changed, CIQRA tells the Merchant the type, amount/percentage, trigger, and expected release conditions — except where notice would undermine fraud prevention or breach law/scheme rules.
C.4 Purpose & release. The reserve secures the Merchant's obligations (refunds, chargebacks, reversals, fees, negative balance, indemnities). Funds are released when the risk period lapses and no offsetting liability remains. No interest accrues unless legally required.
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.
C.5 Post-termination tail. After termination, CIQRA may retain a reserve/hold for up to 180 days to cover late chargebacks/refunds before final release. [Approach: card-scheme chargeback windows (≈120–180 days).]
D. Negative balance & recovery
If refunds, chargebacks, reversals, fees or reserves exceed the Merchant's available balance, the balance may go negative and the Merchant must repay promptly. CIQRA/Stripe may recover by offsetting current/future payouts and sales, drawing on the reserve, charging the linked payment method/bank, and, if unrecovered, pursuing the debt with reasonable costs and statutory interest (Merchant Agreement §7).
CIQRA's determination: contractual set-off, external-account debit and cost-recovery 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); and the split of unrecovered losses between CIQRA and Stripe depends on a Stripe account setting that has not yet been read — see Payment Terms §4.6. Merchant Agreement §6.4 and §7 must be aligned to that setting once it is known.
E. CIQRA's own subscription refunds (CIQRA → Merchant)
E.1 CIQRA subscription fees are billed in advance and are generally non-refundable; cancellation takes effect at period end with no pro-rata refund (ToS §3.5). Trial length is 14 days (measured: Ciqra.Api/Billing/PlanCatalog.cs:46 — TrialDays = 14).
E.2 Where a Merchant is itself a consumer and a mandatory statutory withdrawal right applies to the subscription purchase, that right is honoured as required by law.
CIQRA's determination: the ToS requires Merchants to be traders (18+, acting in a business capacity), which is the basis on which "non-refundable, no pro-rata" is drafted. E.2 exists because that requirement is a representation, not a verified fact, and a sole trader may still qualify as a consumer for some purposes. 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 applies and prevails.
F. Customer-facing summary (for inclusion on Storefronts)
Your purchase is a contract with the store (the Merchant), who is the seller. Refund and return requests, and consumer rights such as the 14-day right of withdrawal (where it applies), are handled by the store under its published refund policy and applicable law. Payments are processed securely via Stripe; the store — not CIQRA — is responsible for the goods/services and refunds.
Provision register (this document)
| Provision | Basis | Where |
|---|---|---|
| MoR premise | (A) measured direct charge, no on_behalf_of/transfer_data | premise |
| withdrawal right + exceptions | (B) single global default vs per-market not assessed | A.1 |
| Estonia withdraw button | 🔴 (A) measured ABSENT + (B) support claim withdrawn; dated obligation 01.09.2026 | A.2 |
| refund processing / 14-day | (A) measured connected-account refund + (B) no platform enforcement of the deadline | A.3 |
| fees on refunds | (A) measured RefundApplicationFee = true; pro-rata formula | A.4 |
| dispute fees | (A) measured via direct-charge premise | B.3 |
| backstop refunds | (A) measured refund capability real; reserve limb not | B.5 |
| no interest on reserve | (B) enforceability unassessed | C.4 |
| set-off / recovery | (B) enforceability unassessed; depends on §4.6 setting | D |
| consumer withdrawal on subscription | (B) micro-trader unfair-terms exposure unassessed | E.2 |
| chargeback threshold | ⛔ withdrawn — ~0.75% was CIQRA-invented and never decided; scheme thresholds remain | B.4 |
| (not previously flagged) | 🔴 (B) reserve is a reserved right with no mechanism (F1.O-06) | C.0 |
Composition: 6 measured facts · 7 declared positions · 1 withdrawn claim (withdrawal-button support).
End of Refund/Chargeback/Reserve Policy . See: Merchant Agreement · Payment Terms · Terms of Service.