Voltar para artigos
API PremifyTecnicoAtualizado em 30 de out. de 2026

Limites de chances e limites de prêmios

Os dois conjuntos de teto que a API aplica e por que um aceita a nota e o outro barra o prêmio

#api-premify#regras-de-negocio#campanha

O que e?

São dois conjuntos de travas que a campanha configura e que o atendimento precisa não confundir, porque eles respondem perguntas diferentes e contam coisas diferentes:

  • tetos de chance — quanto uma nota rende e quanto o participante acumula;
  • tetos de prêmio — quantos prêmios um participante recebe e quantos uma nota paga.

A diferença em uma frase: o teto de prêmio conta prêmio pago; o teto de chance conta chance consumida.

Como funciona?

Nos dois conjuntos, nulo ou zero quer dizer sem limite.

Tetos de chance

São dois campos da regra de geração:

  • limite de chances por nota, que corta o quanto aquela nota rende por regra, antes da soma. É por regra, e não no total da modalidade, para preservar a composição: "a cada R$ 100 ganha 1" e "levando o produto X ganha mais 1" são duas regras, e o teto de uma não deve cortar a outra;
  • limite de chances do participante, que é quanto ele acumula na campanha, por participação e por modalidade. Com mais de uma regra, vale a menor entre as que limitam — teto frouxo por composição seria a porta para o participante acumular mais do que a campanha previu.

A ordem do cálculo é a do mais restritivo: cada regra rende o mínimo entre o que ela calculou e o seu teto por nota; as regras somam; o total é cortado pelo limite de posições, quando é o caso; e por último é cortado pelo que ainda cabe no limite do participante.

No teto, a nota é aceita e gera o que couber, podendo ser zero. Isso é deliberado: recusar a nota pelo teto de uma modalidade derrubaria junto a outra, que ainda tinha espaço, e o participante perderia o registro da compra por uma regra que fala sobre quanto ele acumula, não sobre a nota ser válida.

O teto por nota corta a base e a chance extra juntas. Quem vem do sistema anterior precisa saber disso: lá o dobrador de chance extra entrava depois e passava por cima do limite, e a nota rendia mais do que o configurado. Campanha com teto por nota e chance extra passa a render menos do que rendia antes.

A chance extra vem dos vínculos de produto e de loja com a campanha. As regras dela: vários produtos com chance extra na mesma nota, vale o maior; produto e loja na mesma nota, acumulam; a multiplicação vale só sobre a base, e os fatores não se compõem; e nota sem base — que não fechou o mínimo — não ganha extra.

O que conta como chance já acumulada, e isso é a lista que resolve a maioria das dúvidas:

  • chance invalidada não conta. É a marca que o cancelamento de nota escreve, e é ela que devolve a vaga;
  • chance de nota cancelada não conta. O critério é "todas as notas vinculadas canceladas", não "alguma" — com saldo, um número pende de duas notas, e cancelar uma delas não anula o número;
  • chance sem nota conta: carga manual, integração, story, chance por cadastro, chance por comunidade e chance de convite. Sem isso, chance sem nota ficaria invisível ao teto;
  • posição reprovada na apuração continua contando. Reprovação é sobre o prêmio, não sobre a chance: a posição foi consumida do pool, e devolver o prêmio não devolve a chance;
  • posição de enchimento conta, pelo mesmo motivo: ela ocupou uma vaga do pool mesmo sem pagar nada.

Tetos de prêmio

São três configurações da campanha: o máximo de prêmios de um participante na campanha, o máximo pago por uma mesma nota, e "ganhador único" (que equivale a no máximo um prêmio por participante). Entre o máximo por participante e o ganhador único, com os dois configurados, vale o mais restritivo. Eles valem para Sorteio e Posição premiada juntos — um prêmio é um prêmio, venha de onde vier.

Eles são conferidos na apuração, não na distribuição. Conferir na distribuição exigiria decidir o prêmio antes da conferência humana, que é deliberadamente colocada depois.

O que conta como prêmio recebido: posição premiada aprovada mais ganhador de sorteio registrado. A contagem de ganhadores exclui os que vêm de posição, senão a posição aprovada e depois publicada contaria duas vezes pelo mesmo prêmio. Posição de enchimento nunca entra — o limite conta prêmio pago, não posição consumida.

O excedente é barrado, não reprovado. A mensagem diz o teto e quantos já foram recebidos, e a posição continua pendente. Devolver o prêmio ao pool segue sendo decisão do operador, pelo fluxo normal de reprovação. Reprovar por conta própria escolheria, no lugar dele, qual das posições do participante morre.

Na aprovação em lote, cada posição é uma decisão independente, com relatório — e a contagem dentro do lote é incremental, senão três posições do mesmo participante passariam juntas num teto de duas.

No sorteio, a lista de números disponíveis para registrar ganhador e a apuração pela Loteria Federal aplicam o mesmo recorte e escondem quem já bateu o teto do participante: oferecer o que o registro recusa produziria o erro depois de o operador já ter escolhido. O teto por nota não filtra a lista da Loteria Federal, porque depende da nota de cada número; se ele barrar o registro, o operador passa ao suplente.

Posição já publicada como ganhador não se reabre. Reabrir tiraria a aprovação e deixaria o ganhador de pé: o prêmio seguiria publicado e pararia de contar no teto, dando ao participante uma vaga a mais sem que nada fosse desfeito. O caminho é excluir ou ocultar o ganhador e só então reabrir.

Como explicar ao cliente?

São duas famílias de limite, e elas se comportam de forma oposta de propósito.

No limite de chances, a compra é sempre aceita e rende o que couber — pode render zero. O participante não perde o registro da compra; ele só não recebe chance além do teto.

No limite de prêmio, a posição do participante que já atingiu o teto fica parada, pendente, e a aprovação é barrada com a mensagem dizendo o teto e quantos prêmios ele já recebeu. O sistema não reprova sozinho: quem decide qual das posições dele será reprovada, devolvendo o prêmio ao pool, é a operação.

Dois pontos que surpreendem: a posição reprovada continua ocupando vaga no limite de chances do participante (a posição foi consumida do pool, e a reprovação é sobre o prêmio); e a posição de enchimento também ocupa, mas não conta como prêmio recebido.

E, para quem vem do sistema anterior: o teto por nota agora corta a chance extra junto com a base. A mesma campanha pode render menos do que rendia antes.

Possiveis falhas, causas e solucoes

  • Falha: a nota do participante foi aceita e não rendeu nada.
  • Possivel causa: o participante atingiu o limite de chances dele naquela modalidade. A nota entra e gera o que couber, que pode ser zero.
  • Como orientar: confira o limite de chances do participante nas regras da modalidade e quantas chances ele já tem, inclusive as que não vieram de nota. Vale a menor entre as regras que limitam.
  • Quando escalar: se os limites estiverem em branco e a nota não render, abrir issue no Jira (projeto DEV) com as evidências.
  • Falha: a campanha passou a render menos chances por nota do que rendia no sistema anterior.
  • Possivel causa: o limite de chances por nota passou a cortar a base e a chance extra juntas. Antes a chance extra passava por cima do limite.
  • Como orientar: explique que o limite agora vale para o total da nota naquela regra, que é o que a tela promete. Se o cliente quiser o comportamento antigo, o caminho é elevar o limite.
  • Quando escalar: não é falha. Só escalar se a conta não bater nem com a base nem com a base somada ao extra.
  • Falha: a aprovação de uma posição premiada foi barrada com mensagem de teto de prêmios.
  • Possivel causa: o participante já recebeu o máximo de prêmios configurado na campanha, ou aquela nota já pagou o máximo.
  • Como orientar: a mensagem diz o teto e quantos prêmios ele já recebeu. A posição fica pendente. Se o cliente quiser liberar outra posição dele, é preciso reprovar uma das aprovadas, o que devolve aquele prêmio ao pool.
  • Quando escalar: não é falha. Só escalar se a contagem da mensagem não corresponder aos prêmios que o participante tem.
  • Falha: o participante teve a posição reprovada e não recebeu chance de volta.
  • Possivel causa: a reprovação é sobre o prêmio, não sobre a chance. A posição foi consumida do pool e continua contando no limite de chances dele.
  • Como orientar: explique a separação. O prêmio volta ao pool para outra pessoa, mas a vaga de chance dele foi consumida.
  • Quando escalar: não é falha.
  • Falha: o operador não consegue reabrir uma posição.
  • Possivel causa: ela já foi publicada como ganhador. Reabrir deixaria o ganhador publicado e parando de contar no teto.
  • Como orientar: exclua ou oculte o ganhador primeiro e só então reabra a posição.
  • Quando escalar: não é falha. Só escalar se a recusa aparecer em posição que nunca foi publicada.
  • Falha: na aprovação em lote algumas posições passaram e outras foram barradas.
  • Possivel causa: o lote é parcial de propósito, e a contagem dentro dele é incremental — as primeiras do mesmo participante consomem o teto e as seguintes são barradas.
  • Como orientar: leia o relatório do lote, que diz o motivo de cada recusa. As barradas continuam pendentes.
  • Quando escalar: não é falha. Só escalar se o relatório apontar recusa sem motivo.

Exemplo de resposta pronta

Olá! Existem dois tipos de limite na promoção, e eles se comportam de formas diferentes. O limite de chances não recusa a sua compra: ela é sempre registrada e gera o que couber dentro do limite, podendo não gerar nada quando você já atingiu o máximo da promoção. O limite de prêmios é outra coisa: se você já recebeu o número máximo de prêmios previsto no regulamento, uma nova posição premiada sua fica parada, aguardando, e a mensagem informa o limite e quantos prêmios você já recebeu. Vale lembrar que uma posição reprovada continua contando como chance utilizada — a reprovação é sobre o prêmio daquela posição, não sobre a sua participação.

Quando escalar?

Acione o time de desenvolvimento urgentemente e abra issue no Jira (projeto DEV) com as evidências quando notas não renderem com todos os limites em branco, quando a contagem de prêmios da mensagem de barramento não corresponder ao que o participante tem, quando o total de chances de um participante passar do teto configurado, quando uma recusa de reabertura aparecer em posição nunca publicada, ou quando o relatório de um lote de aprovação apontar recusa sem motivo. Anexe o nome da campanha, o CPF ou CNPJ do participante, a modalidade, a regra e a mensagem exibida.

Artigos relacionados

API PremifyIntermediario
Limite de notas por participante

Por que a nota excedente é recusada e como o limite por dia conta pelo horário de Brasília

#api-premify#regras-de-negocio#campanha
Atualizado em 30 de out. de 2026
API PremifyIntermediario
Como a API decide o que uma nota gera

As modalidades da campanha e as regras de geração que transformam nota cadastro story ou comunidade em chance

#api-premify#regras-de-negocio#campanha
Atualizado em 30 de out. de 2026