CIQRA Pay — Payment Terms
IN FORCE. See 00-README. These Payment Terms form part of, and are incorporated into, the Merchant Agreement; on payment matters they are read together with it. Detailed fee/payout/reserve/refund mechanics are in the Merchant Agreement §§3–7 and the Refund/Chargeback/Reserve Policy.
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Ü
⚠️ Regulatory characterisation is load-bearing. The framing in §1 is what keeps CIQRA outside payment-institution licensing. It must not be diluted in marketing or product copy.
CIQRA's determination: §1 is CIQRA's own characterisation of its regulatory status. It is supported by measurement of what the code does (§1.2 below) but not by a regulatory opinion. The distinction matters: measurement can show that funds never enter a CIQRA-controlled account, which is the factual predicate; it cannot establish that the PSD2 Art. 3(j) exclusion applies as a matter of law. This is the single highest-consequence unreviewed position in the entire document set — if wrong, the remedy is licensing, not redrafting.
1. What CIQRA Pay is — and is not (regulatory characterisation)
1.1 CIQRA Pay is a technology/software service, not a payment service. CIQRA Pay is the software layer (checkout UI, orchestration, dashboards, reporting) by which a Merchant integrates Stripe — a third-party, licensed payment service provider — into its Storefront. Stripe processes, acquires, and settles all card and other payment transactions. [Approach: PSD2 Art. 3(j) technical-service-provider exclusion; Recital 10.]
1.2 CIQRA does not touch the funds — the factual predicate, measured. CIQRA does not receive, hold, control, escrow, or settle buyer funds.
Measured 2026-08-09 (lane/L @ 81807dc44), the payment path is a Stripe Connect direct charge on the connected account:
| Fact | Evidence |
|---|---|
| Connected accounts are created as Express | ciqra-saas/src/Ciqra.Api/Payments/Stripe/StripeConnectService.cs:62 — Type = "express", with CardPayments and Transfers capabilities requested |
| The charge is created on the Merchant's account, not the platform's | Payments/Stripe/CiqraPayStripeProvider.cs:69 — new RequestOptions { StripeAccount = account.StripeAccountId } |
CIQRA's fee rides the charge as the Stripe application_fee | CiqraPayStripeProvider.cs:61 — ApplicationFeeAmount = applicationFee |
| It is not a destination charge | on_behalf_of and transfer_data are absent repo-wide — a destination charge would put the platform in the funds flow |
| Saved-card charges follow the same rule | Payments/SavedCards/SavedCardStripeService.cs:62-104 — every call is scoped to account.StripeAccountId |
Funds therefore flow from the Customer, via Stripe, directly to the Merchant's Stripe balance, and are paid out by Stripe to the Merchant's bank account. The absence of on_behalf_of/transfer_data is the load-bearing measurement: it is what distinguishes "the platform never possesses the funds" from "the platform routes the funds and passes them on".
1.3 CIQRA's fee is a platform/software fee. CIQRA charges a platform/software fee (its commission/spread) for use of the CIQRA platform. Stripe collects this fee on CIQRA's behalf from the transaction (the Stripe application_fee, measured above). It is not a fee for money transmission or payment processing, and it is separate from Stripe's own processing fees.
1.4 CIQRA is NOT a bank, payment institution (PI), e-money institution (EMI), payment service provider, acquirer, money transmitter, money remitter, or escrow agent, and it does not operate a wallet, float, or client-funds account. Stripe (in the EEA, Stripe Payments Europe, Ltd., authorised by the Central Bank of Ireland) is the licensed provider of the regulated payment services.
1.5 Merchant is the merchant of record. The Merchant is the seller and merchant of record for all sales to its Customers, and owns the sales contract, pricing, taxes, fulfilment, refunds, and consumer-law obligations (Merchant Agreement §1). CIQRA does not set the terms of sale as principal and is not a party to the Customer↔Merchant contract. This follows from the direct-charge measurement in §1.2, and the code states the same conclusion in its own comment: "Chargeback liability sits with the seller in the direct model" (CiqraPayStripeProvider.cs:14).
1.6 Local acquirers do not change the characterisation. Where a Merchant uses a local acquirer (İyzico, PayTR, bank virtual-POS) instead of CIQRA Pay, those providers are integrated through the hosted/redirect path (INativePaymentProvider.cs:48 — INativePaymentProvider : IHostedPaymentProvider; bank v-POS uses a 3DS hand-off redirect, NativePaymentsServiceCollectionExtensions.cs:53). CIQRA is not in the funds flow for those either.
1.7 Regulatory change (PSD3/PSR). PSD2 is expected to be replaced by PSD3 (Directive) and the Payment Services Regulation (PSR) — provisional political agreement 27 Nov 2025; expected Official Journal publication ~mid-2026; PSR applicability ~2026, PSD3 national transposition ~2028.
CIQRA's determination: CIQRA expects the technical-service-provider framing to survive PSD3/PSR, because the exclusion rests on the factual test measured in §1.2 (no possession of funds) rather than on drafting. This expectation has not been checked against the final text, which did not exist at this date. The framing must be re-reviewed on OJ publication.
2. The Stripe relationship (mandatory flow-down)
2.1 You contract with Stripe. To use CIQRA Pay you must accept, and remain bound by, the Stripe Services Agreement (SSA) and the Stripe Connected Account Agreement (SCAA), and Stripe's Restricted Businesses list. You must accept the applicable Stripe agreement in onboarding before your connected account can process any transaction. [Approach: Stripe SCAA mandatory-acceptance flow-down.]
2.2 Roles; CIQRA is not Stripe's agent. Stripe — not CIQRA — provides the regulated payment services. CIQRA is not Stripe's agent, cannot bind Stripe, and is not liable for Stripe's acts or omissions; likewise Stripe is not responsible for CIQRA's software. On any conflict about payment mechanics, the Stripe agreements prevail.
2.3 Card-network and payment rules. You must comply with applicable card-network rules (Visa, Mastercard, etc.), Stripe's rules, and applicable law; these supersede any conflicting term to the extent required.
2.4 Stripe may act independently. Stripe may verify, restrict, hold funds for, suspend, or terminate your connected account under its own agreements; if it does, CIQRA Pay for you is affected accordingly.
2.5 Third-party beneficiary. Stripe (and, where relevant, card schemes and payment providers) are intended third-party beneficiaries of the provisions here that concern them.
3. Onboarding, verification (KYC/KYB) and sanctions
3.1 Verification is a condition of access — Stripe performs it. Access to CIQRA Pay is conditional on successful Stripe verification (KYC/KYB). Measured: CIQRA creates the Express connected account and requests capabilities (StripeConnectService.cs:60-72); Stripe collects and holds the identity and beneficial-owner documentation. CIQRA holds the account reference and status, not the underlying documents (see Retention A.2.1).
CIQRA's determination on DSA trader traceability: an earlier internal version stated that CIQRA "additionally collects/verifies trader-traceability data under the DSA". No separate trader-traceability verification mechanism was found in this reconciliation. In practice CIQRA relies on Stripe's KYB as the identity check. Art. 30 places the duty on the online platform, requires specified data points, and requires best-efforts assessment of reliability (Legal Basis Register row 2.1). CIQRA's determination is that Stripe's KYB does not by itself discharge Art. 30. Relying on a payment provider's onboarding to satisfy a platform-regulation duty is a common assumption and not obviously correct. See AUP for the related notice-and-action gap.
3.2 Sanctions & prohibited jurisdictions. You represent, on a continuing basis, that you, your owners and your Customers are not the target of, and you will not use CIQRA Pay in violation of, EU / US (OFAC) / UK / UN sanctions, AML/CTF or export-control law, and that you are not in an unsupported or embargoed jurisdiction. Measured: CIQRA Pay onboarding refuses unsupported countries at the point of account creation (StripeConnectService.cs:50-57 — StripeSupportedCountries.IsSupported, with an explicit refusal message directing the merchant to alternative methods).
3.3 Ongoing monitoring & suspension. CIQRA and Stripe may re-verify, restrict, suspend, or terminate access at any time — including for failed verification, sanctions/AML concerns, suspected fraud, elevated disputes, or a Restricted-Business breach — and may withhold funds pending review.
CIQRA's determination: CIQRA's own risk workflow is manual by design — merchant risk flags are explicitly "context for a human, never automatic enforcement" (
Ciqra.Modules.Operator/Domain/OperatorRiskFlag.cs:20,27), and a rules-based fraud scorer exists for transactions where "the merchant decides" (Ciqra.Api/Fraud/FraudScorer.cs:54-57). There is no automated monitoring that suspends a merchant. The paragraph above describes a right CIQRA reserves, exercised manually — not an automated control. Stripe's own monitoring operates independently of this.
4. Fees, payouts, reserve, refunds, chargebacks
4.1 Fees. CIQRA's commission is collected by Stripe from each transaction as the application_fee (measured, §1.2), in addition to Stripe's own processing fees. ⛔ The rate is not stated in the legal set: commission rates were never decided and the draft schedule has been withdrawn from force — see Merchant Agreement §§3.0–3.1. The applicable rate is the one published on CIQRA's pricing page or stated in your Order Form.
4.2 Payouts. Settlement runs Stripe → your connected account on Stripe's rolling schedule; CIQRA adds no separate payout minimum. Merchant Agreement §4.
4.3 Reserve — 🔴 policy declared (③ owner-confirmed), mechanism not built (PA-0355). CIQRA reserves the right to impose a risk-based reserve where risk warrants (indicatively a rolling reserve of up to 10% held for up to 90 days, or an up-to-100% hold on specific funds for suspected fraud), with a 180-day maximum post-termination hold. Triggers, amounts and release conditions are disclosed when a reserve is set. Merchant Agreement §5; Refund/Chargeback/Reserve Policy.
CIQRA's determination: no reserve mechanism exists in the platform. The only occurrence of a reserve concept in the payments code is a comment marking it as future work (
CiqraPayStripeProvider.cs:14— "reserve/risk = F1.O-06"); there is no code that sets, holds, releases or accounts for a reserve. The Stripe Reserves API requires a platform's reserve policy to be disclosed in its Terms, which is why this clause exists — but disclosing a policy is not the same as being able to operate it. Until F1.O-06 ships, CIQRA can contractually reserve the right but cannot exercise it, and any reserve would have to be arranged through Stripe manually. This clause is therefore enforceable as a right and inoperative as a control.
4.4 Refunds & chargebacks are the Merchant's — measured. You are solely liable for refunds, chargebacks, dispute/representment fees, fines, and negative balances arising from your transactions. On a full refund CIQRA returns its commission — measured: RefundApplicationFee = true (Payments/Stripe/StripePaymentOperations.cs:43) — and pro-rata on a partial refund — measured: the refunded 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.
4.5 Recovery / set-off. You authorise CIQRA and Stripe to debit your balance, connected external account, or reserve to recover amounts owed; if unrecoverable, you remain liable to reimburse CIQRA on demand. Merchant Agreement §7.
4.6 Loss allocation (Stripe configuration).
CIQRA's determination: the Stripe Connect losses/liability configuration (
losses_collector/losses.payments=stripeorapplication) determines whether an unrecovered negative balance rests with Stripe or with CIQRA as platform. This is a Stripe account setting, not a code path — it is set on the platform account in the Stripe Dashboard/API and therefore could not be measured from the source tree. What the source does show is that accounts are created asType = "express"with no explicit loss-configuration parameter (StripeConnectService.cs:60-72), meaning the setting takes whatever value the platform account carries. This must be read off the live Stripe account and recorded before launch, and Merchant Agreement §6.4 aligned to whatever it actually says. Until then, the allocation between CIQRA and Stripe is undetermined — though in either case the Merchant remains the party ultimately liable to reimburse.
5. Prohibited use
You must not use CIQRA Pay for a prohibited/restricted business (Stripe's Restricted Businesses list + CIQRA's Acceptable Use Policy), for payment aggregation/factoring or processing payments for third parties, or for unlawful, fraudulent, or sanctioned activity. Breach may lead to suspension, reserve, fund holds, and termination.
6. Alternative (BYO) gateway
If you connect your own payment gateway instead of CIQRA Pay, that provider's terms govern the payment relationship, CIQRA takes no payment spread on those transactions, and §§1–5 (CIQRA Pay-specific) do not apply to them.
7. Framing CIQRA will not use (internal guardrail — informative)
To preserve the characterisation in §1, CIQRA's product, marketing and support copy will avoid describing CIQRA as a "payment processor / PSP / acquirer / money transmitter / e-money issuer", or saying CIQRA "holds / settles / escrows / disburses your funds" or operates a "CIQRA wallet/balance", and will not route buyer funds into a CIQRA-controlled account before they reach the Merchant. [Approach: PSD2 red-flag list; EBA Q&A 2020_5355.]
Operational note: the last item in that list is currently true by construction rather than by discipline — the direct-charge measurement in §1.2 means there is no CIQRA-controlled account in the path to route funds into. Introducing
on_behalf_ofortransfer_data, or a platform-held balance, would change the regulatory characterisation and not merely the implementation. Treat those two Stripe parameters as a licensing-relevant invariant, not an engineering choice.
Provision register (this document)
| Provision | Basis | Where |
|---|---|---|
| characterisation is load-bearing | (B) highest-consequence unreviewed position; factual predicate measured, legal conclusion not | header |
| Art. 3(j) exclusion | (B) as above | §1.1 |
| no possession of funds | (A) measured direct charge; on_behalf_of/transfer_data absent | §1.2 |
| not a PI/EMI | (B) rests on §1.1 position | §1.4 |
| — | (B) expectation stated, final text did not exist | §1.7 |
| trader traceability | (B) no mechanism found; Stripe-KYB-discharges-Art.30 unassessed | §3.1 |
| losses config | (B) Stripe account setting, not measurable from code; must be read off live account | §4.6 |
| framing guardrail | (A) measured true by construction + invariant note | §7 |
| (not previously flagged) | (A) measured — RefundApplicationFee = true, pro-rata on partial | §4.4 |
| (not previously flagged) | (A) measured — unsupported-country refusal at onboarding | §3.2 |
| (not previously flagged) | 🔴 (B) reserve policy declared, no mechanism exists (F1.O-06) | §4.3 |
| (not previously flagged) | (B) merchant risk workflow is manual by design | §3.3 |
Composition: 5 measured facts · 7 declared positions. The measured facts fully close the payment-liability model; what remains open is regulatory characterisation (§1, needs payments counsel), the Stripe losses configuration (§4.6, needs a dashboard read), and the reserve mechanism (§4.3, needs F1.O-06).
End of Payment Terms . See: Merchant Agreement · Refund/Chargeback/Reserve Policy · Acceptable Use Policy · Subprocessor List.