Versão de 16 de setembro de 2026. As presentes regras fazem parte do Acordo da Cicora e aplicam-se às encomendas da RIZZ TRADE.
1. O que é adquirido
1.1. O Utilizador adquire acesso ao serviço de software da Cicora ou paga antecipadamente a sua utilização. Uma Subscrição paga um período definido e os limites previstos pelo plano. O Pagamento consoante a utilização da API regista separadamente as operações efetivas. As unidades pré-pagas e os bónus não são um depósito bancário, moeda, ativo de investimento nem meio de pagamento.
1.2. Uma Conta pode conter tipos distintos de contabilização: um limite de Subscrição, um Saldo da API carregado separadamente, volume adicional comprado e um bónus promocional. Não podem ser tratados como intermutáveis, salvo se uma Encomenda previr expressamente a transferência ou utilização de um produto para pagar outro. As regras de despesa e o saldo disponível são apresentados para o tipo de contabilização relevante.
1.3. Os Créditos não podem ser transferidos para outro Utilizador, vendidos como dinheiro, oferecidos fora de uma funcionalidade prevista nem usados para liquidar contas com um vendedor terceiro. A possibilidade de reembolso legal por um serviço não prestado é regulada separadamente e não constitui um «levantamento da carteira».
2. Preço e conteúdo de uma Encomenda
2.1. O catálogo de preços e da API divulga as ofertas atuais. Antes do pagamento, o Utilizador vê o produto, período, base de cálculo, moeda, impostos aplicáveis e montante final. O comprador pode analisar a Encomenda antes da confirmação e conservar os respetivos termos.
2.2. As subscrições Plus ($20), Pro ($50), 5× ($100) e 20× ($200) têm os preços mensais indicados. Os níveis 5× e 20× são comparados com o plano Plus ($20), e não com dinheiro no Saldo da Conta. O mero facto de o preço do Pro ser comparado com o de outro plano não implica qualquer multiplicador matemático.
2.3. Nas transações nacionais no Usbequistão, são usados os preços e cálculos estabelecidos para essas transações na moeda permitida por lei. Numa Encomenda internacional, a moeda de faturação e o montante do pagamento são acordados antes do pagamento. Quando exista conversão, o procedimento aplicável e o montante final são divulgados; a conversão independente pelo banco emissor rege-se pela relação do Utilizador com esse banco.
2.4. O catálogo público da API publica as tarifas, unidades e termos especiais exatos aplicáveis ao Modelo selecionado. Uma tarifa por milhão de tokens de texto não é uma unidade universal para áudio, imagens, vídeo ou reordenação. Diferentes modos, qualidade, duração, dimensão do contexto, cache, ferramenta ou fornecedor podem alterar o cálculo; a tarifa, unidade e condição aplicáveis estão disponíveis antes de um pedido.
3. Medição da utilização da API
3.1. O volume efetivamente executado é registado segundo as medidas aplicáveis: tokens de entrada e saída, tokens em cache, raciocínio interno quando faturado, imagens, duração do áudio, carateres de voz, segundos de vídeo, pedidos ou outras unidades divulgadas. Os parâmetros e unidades seguem o Modelo relevante, e não apenas o nome geral da função.
3.2. Para uma tarifa por milhão de tokens, a quantidade faturável é dividida por 1,000,000 e multiplicada pela tarifa relevante. Para outra unidade, usa-se a escala publicada. O mesmo consumo não pode ser cobrado duas vezes como componentes independentes quando o preço não previr operações separadas.
3.3. Alguns valores do catálogo descrevem um preço base, mínimo ou dependente da Rota. Um router dinâmico ou uma tarifa calculada a partir de parâmetros adicionais não se torna gratuito apenas porque um campo do serviço é zero, negativo ou inexistente. O montante final é determinado pela fórmula divulgada do modo relevante.
3.4. Antes da execução, estão disponíveis a tarifa e o método de cálculo e, quando o volume exato não seja conhecido antecipadamente, a estimativa ou o limite de despesas disponibilizado pelo produto. Após o tratamento, são registados as unidades efetivas, o montante, o Modelo, a hora e o identificador da operação. Estas informações ajudam a associar a utilização a uma Encomenda e a solicitar a análise de um erro.
3.5. O volume de utilização é medido pelos sistemas técnicos da Cicora e pelos sistemas do fornecedor participante dentro do modo aplicável. Pode surgir uma diferença entre a contagem de texto de um Utilizador e a de um tokenizador devido ao histórico, às instruções do sistema, às ferramentas, aos anexos e à codificação. Em caso de litígio, são considerados os registos relacionados com a operação; um registo técnico não constitui prova conclusiva.
3.6. O arredondamento, um volume mínimo faturável e intervalos especiais de preços são divulgados na ficha ou na interface de faturação antes da utilização. As novas regras não se aplicam retroativamente a operações concluídas. O Utilizador não deve esperar que um preço da API permaneça inalterado por tempo indeterminado para pedidos futuros.
4. Reserva, erros e pedidos repetidos
4.1. Parte do Saldo pode ser temporariamente reservada para um pedido. Uma reserva limita o saldo disponível, mas não constitui a cobrança final. Após a conclusão, é calculado o custo efetivo e a parte não utilizada é libertada; o estado e os ajustes são apresentados no histórico.
4.2. Se um pedido for rejeitado antes de começar o processamento faturável, o respetivo custo não é automaticamente considerado utilizado. Uma cobrança errónea é analisada e corrigida. A rejeição da entrada por uma salvaguarda, uma falha da plataforma, a ausência de Resultado e o cancelamento pelo Cliente têm circunstâncias técnicas diferentes; devem ser avaliados segundo o processamento efetivamente realizado e fornecido e a lei imperativa.
4.3. A perda da ligação do cliente ou o fecho de uma janela do navegador nem sempre interrompe a execução já iniciada. Em caso de transmissão ou Resultado parcial, o processamento realizado pode ser cobrado se essa regra tiver sido divulgada e for permitida por lei. O Serviço não pode considerar bem-sucedida qualquer operação não entregue apenas porque um fornecedor a faturou.
4.4. Um novo envio pelo Utilizador após um tempo limite pode constituir um pedido separado. Uma nova tentativa automática ou uma rota técnica alternativa deve respeitar as definições, o orçamento e as regras de dados acordados. A mudança para um modo substancialmente mais caro não cria autorização ilimitada para despesas adicionais.
4.5. Para uma operação contestada, forneça o e-mail da Conta, o ID do pedido ou da Encomenda, o Modelo, a hora e o tipo de erro. Não envie todo o Conteúdo pessoal se um identificador bastar para o diagnóstico. Um erro confirmado é corrigido; um reembolso monetário, quando devido, é efetuado ao abrigo das Regras de Reembolso.
5. Períodos e limites da Subscrição
5.1. Uma Subscrição mensal é ativada durante o período indicado na confirmação da Encomenda. As capacidades, Modelos e limites disponíveis são apresentados no produto. «Mais utilização» não significa um número definido de respostas arbitrárias: pedidos de complexidade diferente podem consumir um limite de modo diferente.
5.2. Os níveis superiores são comparados usando um Modelo, modo e período contabilístico comparáveis. Os limites de frequência de pedidos, de simultaneidade e de funções separadas podem aplicar-se independentemente do volume total. Os limites do período não utilizados não são saldo monetário adquirido; as regras de renovação e acumulação são determinadas pelos termos divulgados do plano.
5.3. A renovação só está disponível após consentimento separado que indique a frequência, o montante e o método de cancelamento. O cancelamento impede renovações futuras e mantém o acesso até ao fim do período pago em curso, salvo se ocorrer outra cessação legal. Os pagamentos em lojas de aplicações utilizam as definições de gestão de subscrições dessa loja.
5.4. A mudança para um plano superior ou inferior, migração imediata, atribuição de crédito e alteração da data de faturação só se aplicam num cenário divulgado e confirmado. A mera existência de um plano mais caro não autoriza a cobrança automática do respetivo preço nem o recálculo de um período passado.
6. Carregamento e carregamento automático
6.1. Antes de um carregamento, são apresentados o volume a creditar, o montante do pagamento, a moeda, as regras relevantes para a compra e qualquer prazo de utilização. O crédito é confirmado pelo servidor do fornecedor de pagamentos. Uma notificação repetida ou visitas repetidas a uma página de sucesso não devem criar vários créditos para uma só compra.
6.2. O carregamento automático constitui uma autorização distinta da Subscrição. Quando ativado, são apresentados o limite, montante ou fórmula, o instrumento de pagamento selecionado, os limites disponíveis e o método de desativação. O Utilizador pode alterar ou retirar a autorização para operações futuras. Uma operação já iniciada e legalmente autorizada é analisada separadamente.
6.3. Se o Saldo for insuficiente e o carregamento automático estiver desativado, as novas ações pagas são limitadas. Não podemos aumentar um montante autorizado nem alterar o instrumento de pagamento sem o consentimento exigido. Uma notificação de fundos insuficientes não constitui uma nova Encomenda.
7. Validade das unidades compradas e promocionais
7.1. A validade dos Créditos adquiridos separadamente é indicada antes do pagamento nos termos do carregamento ou pacote relevante. Um termo não divulgado não é introduzido retroativamente. Uma alteração das regras futuras não cancela o volume ativo anteriormente comprado em violação dos termos acordados e da lei imperativa.
7.2. O Crédito Promocional é concedido ao abrigo da campanha relevante. A sua aplicabilidade, restrições, validade e ordem de utilização são divulgadas quando é concedido. Um bónus gratuito não cria um direito separado a receber o seu valor nominal em dinheiro e não substitui um reembolso monetário devido sem o consentimento do Utilizador.
7.3. Se um bónus estiver associado a uma compra, as consequências do cancelamento dessa compra são determinadas pelos termos da campanha e pela lei. Uma parte paga que não tenha sido efetivamente prestada não pode ser considerada consumida apenas porque o bónus e o pagamento estão misturados na contabilização. O histórico deve permitir identificar as operações relativas à compra.
7.4. As tentativas de vender, trocar ou transferir Créditos sem autorização podem conduzir à restrição do acesso e a uma análise. A cessação da Conta, os reembolsos obrigatórios e a conservação legal de documentos são regidos pelo acordo; esta cláusula não cria o confisco automático de todos os saldos pagos.
8. Impostos, confirmações e faturação empresarial
8.1. Os impostos aplicáveis e os dados necessários para os determinar são considerados na Encomenda. O Cliente fornece informações exatas sobre o país, organização e situação fiscal quando necessário. Possuir um número de identificação fiscal não significa, por si só, isenção fiscal nem aplicação da autoliquidação.
8.2. Após o pagamento, é fornecida uma confirmação eletrónica que pode ser conservada. Os documentos fiscais e contabilísticos obrigatórios são emitidos segundo as regras aplicáveis. Uma mensagem de autorização bem-sucedida nem sempre equivale a um recibo fiscal; estes documentos não podem substituir-se entre si.
8.3. O pós-pagamento, um limite de crédito, uma fatura individual, uma condição especial de pagamento ou um compromisso empresarial de volume mínimo só se aplicam se forem acordados separadamente. Não decorrem desta página para uma Conta pré-paga normal. Um erro de faturação é analisado mediante pedido apoiado por documentos, sem prejuízo dos direitos legais.
8.4. Um acordo estrangeiro de aquisição de um Modelo, um desconto do fornecedor ou os seus custos não reembolsáveis não alteram automaticamente os termos da Cicora aceites pelo Utilizador. Contactos para pagamentos e contabilidade: support@cicora.ai, +998 90 051 48 40.