Versjon datert 16. september 2026. Disse reglene utgjør en del av Cicora-avtalen og gjelder for RIZZ TRADE-bestillinger.
1. Hva som kjøpes
1.1. Brukeren kjøper tilgang til Cicora-programvaretjenesten eller forhåndsbetaler for bruken av den. Et Abonnement betaler for en fastsatt periode og grensene som planen gir. API med betaling etter bruk registrerer faktiske operasjoner separat. Forhåndsbetalte enheter og bonuser er ikke bankinnskudd, valuta, investeringsaktiva eller betalingsmidler.
1.2. En konto kan inneholde ulike regnskapstyper: en abonnementsgrense, en separat påfylt API-saldo, kjøpt tilleggsvolum og en kampanjebonus. De må ikke behandles som utskiftbare med mindre en bestilling uttrykkelig åpner for overføring eller bruk av ett produkt til å betale for et annet. Forbruksregler og tilgjengelig saldo vises for den aktuelle regnskapstypen.
1.3. Kreditter kan ikke overføres til en annen bruker, selges som penger, gis bort utenfor en tilgjengelig funksjon eller brukes til oppgjør med en tredjepartsselger. Muligheten for en lovlig refusjon for en tjeneste som ikke er levert, reguleres separat og er ikke et «uttak fra lommebok».
2. Pris og innhold i en bestilling
2.1. Pris- og API-katalogen opplyser om gjeldende tilbud. Før betaling ser Brukeren produktet, perioden, beregningsgrunnlaget, valutaen, gjeldende avgifter og sluttbeløpet. Kjøperen kan gjennomgå Bestillingen før bekreftelse og beholde vilkårene.
2.2. Abonnementene Plus ($20), Pro ($50), 5× ($100) og 20× ($200) har de oppgitte månedsprisene. Nivåene 5× og 20× sammenlignes med abonnementet Plus ($20), ikke med penger i en Kontosaldo. Det følger ingen matematisk multiplikator for Pro bare av prisen sammenlignet med et annet abonnement.
2.3. For innenlandske transaksjoner i Usbekistan brukes prisene og beregningene som er fastsatt for dem, i den valutaen loven tillater. For en internasjonal bestilling avtales faktureringsvaluta og betalingsbeløp før betaling. Når omregning skjer, opplyses gjeldende fremgangsmåte og sluttbeløp; uavhengig omregning av den kortutstedende banken reguleres av brukerens forhold til banken.
2.4. Den offentlige API-katalogen publiserer nøyaktige gjeldende satser, enheter og særvilkår for den valgte Modellen. En sats per million teksttoken er ikke en universell enhet for lyd, bilder, video eller omrangering. Ulike moduser, kvalitet, varighet, kontekststørrelse, hurtigbuffer, verktøy eller leverandør kan endre beregningen; gjeldende sats, enhet og vilkår er tilgjengelig før en forespørsel.
3. Måling av API-bruk
3.1. Faktisk utført volum registreres med de aktuelle målene: inndata- og utdatatokener, mellomlagrede tokener, intern resonnering når den faktureres, bilder, lydvarighet, taletegn, videosekunder, forespørsler eller andre opplyste enheter. Parametere og enheter følger den aktuelle modellen, ikke bare det generelle funksjonsnavnet.
3.2. For en pris per million tokener deles den fakturerbare mengden på 1,000,000 og multipliseres med den aktuelle prisen. For en annen enhet brukes den publiserte skalaen. Det samme forbruket må ikke belastes to ganger som uavhengige komponenter når prisen ikke fastsetter separate operasjoner.
3.3. Enkelte katalogverdier beskriver en grunnpris, minstepris eller Ruteavhengig pris. En dynamisk ruter eller en sats beregnet ut fra flere parametere blir ikke gratis bare fordi et tjenestefelt er null, negativt eller mangler. Sluttbeløpet fastsettes etter den opplyste formelen for den aktuelle modusen.
3.4. Før utførelse er satsen og beregningsmetoden tilgjengelig, og når det nøyaktige volumet ikke er kjent på forhånd, også anslaget eller forbruksgrensen som produktet oppgir. Etter behandling registreres de faktiske enhetene, beløpet, Modellen, tidspunktet og operasjonsidentifikatoren. Disse opplysningene bidrar til å knytte bruken til en Bestilling og be om gjennomgang av en feil.
3.5. Bruksvolum måles av Cicoras tekniske systemer og de deltakende leverandørenes systemer innenfor gjeldende modus. En forskjell mellom Brukerens teksttelling og en tokeniserer kan skyldes historikk, systeminstrukser, verktøy, vedlegg og koding. Ved tvist vurderes opplysninger knyttet til operasjonen; en teknisk logg er ikke avgjørende bevis.
3.6. Avrunding, minste fakturerbare volum og særlige prisintervaller opplyses i kortet eller faktureringsgrensesnittet før bruk. Nye regler gjelder ikke med tilbakevirkende kraft for fullførte operasjoner. Brukeren kan ikke forvente at en API-pris forblir uendret på ubestemt tid for fremtidige forespørsler.
4. Reservasjon, feil og gjentatte forespørsler
4.1. En del av saldoen kan reserveres midlertidig for en forespørsel. En reservasjon begrenser tilgjengelig saldo, men er ikke den endelige belastningen. Etter fullføring beregnes faktisk kostnad og ubrukt del frigis; status og justeringer vises i historikken.
4.2. Hvis en forespørsel avvises før fakturerbar behandling begynner, behandles ikke kostnaden automatisk som brukt. En feilaktig belastning gjennomgås og korrigeres. Avvisning av inndata av et sikkerhetstiltak, plattformfeil, fravær av et resultat og kundens avbestilling har ulike tekniske omstendigheter; de må vurderes ut fra behandlingen som faktisk ble utført og levert, og etter ufravikelig rett.
4.3. Tap av klientforbindelsen eller lukking av et nettleservindu stanser ikke alltid en kjøring som allerede er påbegynt. Ved strømming eller et delvis resultat kan utført behandling belastes dersom denne regelen er opplyst og tillatt etter loven. Tjenesten kan ikke anse enhver ikke-levert operasjon som vellykket bare fordi en leverandør har fakturert den.
4.4. En ny innsending fra brukeren etter et tidsavbrudd kan være en separat forespørsel. Et automatisk nytt forsøk eller teknisk reservehåndtering må holde seg innenfor avtalte innstillinger, budsjett og dataregler. Bytte til en vesentlig dyrere modus gir ikke ubegrenset autorisasjon til ytterligere forbruk.
4.5. For en omtvistet operasjon oppgir du kontoens e-postadresse, forespørsels- eller bestillings-ID, modell, tidspunkt og feiltype. Ikke send alt personlig innhold dersom en identifikator er tilstrekkelig for diagnostisering. En bekreftet feil rettes; en økonomisk refusjon som skal betales, gjennomføres etter refusjonsreglene.
5. Abonnementsperioder og grenser
5.1. Et månedsabonnement aktiveres for perioden som er angitt i bestillingsbekreftelsen. Tilgjengelige funksjoner, modeller og grenser vises i produktet. «Mer bruk» betyr ikke et bestemt antall vilkårlige svar: Forespørsler med ulik kompleksitet kan forbruke en grense forskjellig.
5.2. Økte nivåer sammenlignes med en tilsvarende modell, modus og regnskapsperiode. Grenser for forespørselsfrekvens, samtidighet og separate funksjoner kan gjelde uavhengig av samlet volum. Ubrukte periodegrenser er ikke en kjøpt kontantsaldo; reglene for fornyelse og overføring bestemmes av de opplyste abonnementsvilkårene.
5.3. Fornyelse er bare tilgjengelig etter separat samtykke som angir hyppighet, beløp og oppsigelsesmetode. Oppsigelse stopper fremtidige fornyelser og bevarer tilgang til slutten av inneværende betalte periode, med mindre en annen lovlig avslutning skjer. Betalinger gjennom appbutikker bruker butikkens innstillinger for abonnementsadministrasjon.
5.4. Oppgradering eller nedgradering, umiddelbar migrering, godskriving og endring av faktureringsdato gjelder bare i et opplyst og bekreftet tilfelle. Det at det finnes en dyrere plan, gir ikke adgang til automatisk å belaste prisen eller beregne en tidligere periode på nytt.
6. Påfylling og automatisk påfylling
6.1. Før påfylling vises volumet som krediteres, betalingsbeløpet, valutaen, reglene som er relevante for kjøpet, og eventuell brukstid. Kreditering bekreftes av betalingsleverandørens server. Et gjentatt varsel eller gjentatt besøk på en suksesside må ikke opprette flere krediteringer for ett kjøp.
6.2. Automatisk påfylling er en egen fullmakt, atskilt fra et Abonnement. Når den er aktivert, vises terskelen, beløpet eller formelen, valgt betalingsinstrument, tilgjengelige grenser og hvordan den deaktiveres. Brukeren kan endre eller trekke tilbake fullmakten for fremtidige operasjoner. En allerede igangsatt og lovlig godkjent operasjon vurderes separat.
6.3. Hvis Saldoen er utilstrekkelig og automatisk påfylling er deaktivert, begrenses nye betalte handlinger. Vi kan ikke øke et godkjent beløp eller endre betalingsinstrumentet uten nødvendig samtykke. Et varsel om utilstrekkelige midler er ikke en ny Bestilling.
7. Gyldighetstid for kjøpte enheter og kampanjeenheter
7.1. Gyldighetstiden for kreditter som er kjøpt separat, angis i vilkårene for den aktuelle påfyllingen eller pakken før betaling. Et vilkår som ikke er opplyst, innføres ikke med tilbakevirkende kraft. En endring i fremtidige regler opphever ikke tidligere kjøpt aktivt volum i strid med avtalte vilkår og ufravikelig rett.
7.2. Kampanjekreditter gis etter den aktuelle kampanjen. Anvendelighet, begrensninger, levetid og bruksrekkefølge opplyses når de gis. En gratis bonus gir ikke et separat krav på å få den nominelle verdien utbetalt i penger og erstatter ikke, uten Brukerens samtykke, en pengerefusjon som skal betales.
7.3. Hvis en bonus er knyttet til et kjøp, bestemmes følgene av å annullere kjøpet av kampanjevilkårene og loven. En betalt del som faktisk ikke ble levert, må ikke anses som brukt bare fordi bonus og betaling er blandet i regnskapet. Historikken må gjøre det mulig å identifisere operasjoner knyttet til kjøpet.
7.4. Forsøk på å selge, bytte eller overføre kreditter uten autorisasjon kan føre til tilgangsbegrensning og gjennomgang. Avslutning av konto, obligatoriske refusjoner og lovlig oppbevaring av dokumenter reguleres av avtalen; denne klausulen skaper ikke automatisk inndragning av enhver betalt saldo.
8. Skatt, bekreftelser og bedriftsfakturering
8.1. Gjeldende avgifter og data som trengs for å fastsette dem, tas med i Bestillingen. Kunden gir korrekte opplysninger om land, organisasjon og skattestatus der det er nødvendig. Det å ha et TIN innebærer ikke i seg selv skattefritak eller anvendelse av omvendt avgiftsplikt.
8.2. Etter betaling gis en elektronisk bekreftelse som kan oppbevares. Obligatoriske skatte- og regnskapsdokumenter utstedes i henhold til gjeldende regler. En e-post om vellykket autorisasjon er ikke alltid det samme som en skattemessig kvittering; disse dokumentene må ikke erstatte hverandre.
8.3. Etterskuddsbetaling, en kredittgrense, en individuell faktura, et særskilt betalingsvilkår eller en bedriftsforpliktelse til et minstevolum gjelder bare dersom dette er avtalt separat. Slike vilkår oppstår ikke for en vanlig forhåndsbetalt konto etter denne siden. En fakturafeil vurderes på grunnlag av en dokumentert forespørsel, samtidig som lovfestede rettigheter bevares.
8.4. En utenlandsk innkjøpsavtale for en modell, en leverandørrabatt eller leverandørens ikke-refunderbare kostnader endrer ikke automatisk Cicora-vilkårene som brukeren har godtatt. Kontaktopplysninger for betaling og regnskap: support@cicora.ai, +998 90 051 48 40.