Fallback e Prioridade
O Rise Bots suporta até 3 gateways em ordem de prioridade (primário, secundário e terciário). Se o primário falhar (timeout, erro de API, credenciais inválidas), o secundário assume automaticamente. Se ambos falharem, o terciário entra — tudo sem interrupção para o cliente.
Como funciona o failover
Primário primeiro
Todo checkout tenta gerar a cobrança pelo gateway primário antes de qualquer outro
Fallback automático
Se o primário falhar, o sistema tenta o secundário instantaneamente — sem delay
Sem interrupção
O cliente nem percebe a troca — recebe a cobrança normalmente, independente de qual gateway gerou
3 níveis de prioridade
Primário, secundário e terciário — o gateway da plataforma (Risebots) fica automaticamente como último fallback
Níveis de prioridade
| Nível | Badge | Descrição |
|---|---|---|
| Primário | Azul + borda | Usado primeiro em todo checkout |
| Secundário | Muted | Entra automaticamente se o primário falhar |
| Terciário | Sutil | Ultimo recurso — entra se primário e secundário falharem |
| Ativo (sem prioridade) | Sem badge | Disponível mas não participa do failover |
| Inativo | Opacidade 60% | Desligado — não processa pagamentos |
Configurando o failover
Configure seus gateways
Risebots já vem como primário
Ao criar sua conta, o gateway da plataforma (Risebots) já está ativo como primário. Quando você adiciona um gateway próprio, ele assume como primário e o Risebots desce automaticamente. Um segundo gateway próprio fica como secundário e o Risebots vira terciário.
Reorganize a ordem
Use os botões de seta no card do gateway para alterar a prioridade:
- ↑ Promover a primário — move o gateway para o topo da fila
- ↓ Definir como secundário — coloca como backup do primário
- ↓ Remover prioridade — tira da fila, mas mantém ativo
Conector visual
Quando gateways estão priorizados, uma linha tracejada conecta cada nível ao próximo com o badge "Backup em caso de falha" — confirmando visualmente que o failover está ativo. Com 3 gateways, aparecem dois conectores.
O que acontece quando o primário falha?
Cliente inicia checkout
O sistema tenta gerar a cobrança pelo gateway primário.
Primário retorna erro
Timeout, API fora do ar ou credenciais inválidas — qualquer falha aciona o fallback.
Secundário assume
O sistema tenta automaticamente pelo gateway secundário, sem delay adicional.
Terciário como último recurso
Se o secundário também falhar, o sistema tenta o terciário (normalmente o gateway da plataforma Risebots).
Cobrança gerada normalmente
O cliente recebe o QR Code (PIX) ou é redirecionado ao checkout de cartão (Stripe) normalmente — sem perceber que houve troca de gateway.
Se todos falharem
Caso primário, secundário e terciário falhem, o cliente recebe uma mensagem de erro genérica.
ℹ️ PIX + Cartao no failover
O failover funciona entre gateways de métodos diferentes. Por exemplo, se o Stripe (cartão) falhar, o sistema pode tentar um gateway PIX como secundário — e vice-versa. O cliente recebe o método de pagamento disponível.
ℹ️ Promoção automática
Quando o gateway primário é desativado (switch off), o secundário é automaticamente promovido a primário. Você não precisa reorganizar manualmente.
Dicas
💡 Diversifique provedores
Use provedores diferentes no primário e secundário (ex: SyncPay + PushInPay, ou Stripe + SyncPay). Se um provedor tiver instabilidade, o outro cobre — máxima disponibilidade para seus clientes.
ℹ️ Risebots sempre como último fallback
Quando você adiciona gateways próprios, o Risebots é automaticamente reorganizado para a última posição na cascata. Isso garante que, se todos os seus gateways próprios falharem, o gateway da plataforma ainda processe o pagamento. Você pode promovê-lo manualmente se preferir.