O Stripe está fora do ar?

Entendendo a disponibilidade do Stripe

A disponibilidade do Stripe não é uma condição simples de sim ou não. Um problema pode afetar o processamento de pagamentos, o Checkout, o acesso ao dashboard ou as solicitações enviadas para api.stripe.com, e essas áreas podem falhar por motivos diferentes.

A página oficial de status do Stripe é a melhor primeira verificação para identificar um incidente geral de serviço reportado. Compare o horário e o componente afetado pelo incidente com seus logs, incluindo o endpoint, a região ou a operação de pagamento, quando disponíveis. Uma página de status sem incidentes não elimina a possibilidade de um problema de configuração da conta, de deployment, de conectividade local ou um erro específico da integração.

Solução de problemas do Stripe

1. Verifique se há um incidente do Stripe reportado

Abra a página oficial de status do Stripe e procure um incidente que corresponda ao componente afetado do Stripe e ao horário do problema. Se houver um incidente ativo, acompanhe as atualizações, evite mudanças amplas de configuração e preserve os detalhes das solicitações com falha para análise posterior.

Se nenhum incidente correspondente aparecer, considere que o problema pode ser localizado e continue com as verificações abaixo. Uma página de status sem incidentes não exclui um problema de conta, deployment, integração ou rede.

2. Identifique a área do Stripe que está falhando

Determine onde a falha ocorre:

• Acesso ao dashboard ou à conta: teste o dashboard em uma janela anônima e, quando apropriado, peça a outro usuário autorizado para verificar se as mesmas páginas da conta também falham.
• Checkout ou fluxo de pagamento: determine se o erro ocorre no navegador antes de o servidor entrar em contato com o Stripe, durante a solicitação à API ou depois que a aplicação recebe uma resposta.
• Solicitações à API: registre o status HTTP, o corpo da resposta, o endpoint, o timestamp e qualquer identificador de solicitação ou de erro. Confirme se a solicitação é direcionada a api.stripe.com e se o comportamento pode ser reproduzido.

Uma mensagem como “payment failed” pode representar uma recusa do cartão, uma solicitação inválida, uma configuração da conta ou um erro da aplicação, e não uma interrupção geral do Stripe.

3. Separe falhas de rede e conectividade

Se as solicitações para api.stripe.com expirarem ou não conseguirem estabelecer uma conexão, compare o comportamento a partir de uma segunda rede ou ambiente de deployment. Verifique a resolução de DNS, o acesso HTTPS de saída, as regras de firewall, as configurações de proxy e a inspeção de TLS no ambiente afetado.

Se a mesma solicitação funcionar em outro local, é mais provável que a causa seja local à rede, ao host ou ao deployment original. Para respostas HTTP 502, 503 ou 504, use os logs da aplicação e do servidor para determinar se a resposta veio do Stripe, da sua camada de hospedagem, de um reverse proxy ou de um API gateway. Ao reproduzir a solicitação, use apenas um teste seguro e autenticado.

4. Verifique causas relacionadas ao navegador, à conta e à integração

Para um problema no dashboard ou no Checkout limitado a um navegador, limpe os dados específicos do site ou teste uma janela anônima; depois, compare o comportamento com outro navegador ou dispositivo compatível. Se o problema acompanhar a conta, e não o navegador, peça a um usuário autorizado para revisar o acesso e as permissões da conta.

Quando o Stripe parece estar disponível, mas uma conta ou integração falha, revise o ambiente afetado, as credenciais da API, as permissões, o processamento de webhooks, os parâmetros da solicitação e as configurações alteradas recentemente. Compare o comportamento de teste e de produção somente quando for seguro e apropriado. Uma falha limitada a um endpoint, uma conta de comerciante, um método de pagamento ou um deployment é menos compatível com uma interrupção geral do Stripe.

Nunca exponha chaves secretas da API em relatórios do navegador, tickets ou logs. Remova informações de pagamento e credenciais antes de compartilhar qualquer saída de diagnóstico.

5. Tente novamente com cuidado e escale o problema com evidências

Para respostas transitórias de rede ou do servidor, siga o comportamento de novas tentativas definido pela sua integração e evite operações de pagamento duplicadas. Use proteção de idempotência quando sua integração oferecer suporte a ela e verifique o estado resultante do pagamento antes de tentar outra cobrança.

Se a página de status não mostrar um incidente correspondente e o problema persistir, reúna o timestamp e o fuso horário, o ambiente afetado, o endpoint, o status HTTP, a resposta sanitizada, o identificador de solicitação ou de erro e a informação sobre se o problema também pode ser reproduzido em outra rede. Essas evidências são mais úteis do que repetir tentativas às cegas.