Checkout
Carrinho, dados, entrega e pagamento sem encomenda real.
diário ou cada 6 horas
Menos surpresas. Resposta rápida. Relatório escrito.
A loja deve vender mesmo quando ninguém está no painel WordPress.
O Store Reliability Plan substitui atualizações aleatórias por um ritmo controlado de operação.
Enviar dados da loja por emailRecomendação escrita em um dia útil.
Reliability Commerce
1.490 EUR / mês
Loja ativa com campanhas
P1: 4 horas úteis
até 6 h de alterações
Quatro controlos que protegem vendas
Uptime não basta quando carrinho ou pagamento falha.
Atualizações
Snapshot, staging e testes antes de produção.
mensal ou quinzenal
Backup e restauro
Integridade e teste periódico de restauro.
mensal ou trimestral
Core Web Vitals
URLs fixos expõem regressões após alterações.
mensal ou semanal
Três níveis
Todos incluem relatório e limite claro de pequenas alterações.
Reliability Essential
690 EUR / mês
Loja estável com poucas alterações
- uptime a cada 5 minutos
- checkout mensal
- atualizações mensais em staging
- backup e CWV
P1: 1 dia útil
até 2 h de alterações
Reliability Commerce
1.490 EUR / mês
Loja ativa com campanhas
- uptime e checkout diário
- atualizações quinzenais
- restauro mensal
- CWV semanal
P1: 4 horas úteis
até 6 h de alterações
Reliability Critical
2.890 EUR / mês
Alto custo de indisponibilidade
- checkout cada 6 horas
- janela semanal
- restauro trimestral
- regressão pós-release
P1: 2 horas úteis
até 12 h de alterações
P1 é produção, checkout ou pagamento indisponível. A resposta funciona em dias úteis CET e não garante resolução nesse prazo.
Relatório mensal sem enchimento
Mostra operação, alterações e riscos crescentes.
- 01disponibilidade e incidentes
- 02testes de checkout
- 03atualizações e rollback
- 04backup e restauro
- 05Core Web Vitals
- 06riscos e recomendações
Limites de responsabilidade
Baseline primeiro
Falhas existentes não ficam automaticamente incluídas.
Janelas controladas
Atualizações têm snapshot, staging e rollback.
Limite de alterações
Funcionalidades maiores são estimadas à parte.
Terceiros
Alojamento, pagamento e APIs externas não podem ser garantidos.
Porque falha o primeiro pagamento no WooCommerce?
Um caso anonimizado da Áustria. Uma editora vende assinaturas através do WooCommerce, e o primeiro pagamento abre a assinatura. O apoio ao cliente sinalizou 19 encomendas presas no pagamento. Analisei 90 dias: cerca de 35 casos reais, depois de retiradas as contas de teste.
| Método de pagamento | Primeiros pagamentos interrompidos | Causa típica |
|---|---|---|
| Cartão (Stripe) | cerca de 10% | Cartões recusados e um grupo próprio de falhas de autenticação SCA/3DS |
| Klarna | cerca de 16% | O comprador fecha a janela da Klarna antes de terminar (Customer aborted purchase) |
| PayPal | cerca de 4% | O motivo da recusa não ficou registado em lado nenhum |
| Pagamento por fatura | cerca de 6% | O comprador não foi aprovado para compra por fatura |
Valores aproximados, 90 dias, uma loja.
Como foi medido
Consultas só de leitura às encomendas principais em quatro estados: pendente, falhada, cancelada e lixo. Também as notas das encomendas, porque o texto fixo do apoio ao cliente sobre o reenvio do link de pagamento é detetável de forma automática.
Porque um retrato do momento conta a menos
O estado pendente dura poucos dias. Depois a encomenda passa a falhada, a cancelada e vai para o lixo, que se esvazia ao fim de cerca de 30 dias. Dos 19 exemplos reportados, 8 já não existiam. Um comprador tentou o cartão, ficou retido no 3DS e desistiu da Klarna duas vezes, tudo no mesmo dia.
O que mudou
Uma exportação mensal substituiu a leitura manual dos pedidos de apoio. O problema técnico (3DS) ficou separado do comportamento dos compradores (Klarna) e da falta de dados (PayPal). Ficaram preparadas perguntas à Stripe sobre os códigos de recusa no grupo 3DS e à Klarna sobre os pontos de abandono.
Um primeiro pagamento falhado não se mede à posteriori, porque a loja apaga as próprias provas. Só a medição contínua funciona.
O relatório do sprint fica como ponto de partida
O relatório do Rescue Sprint torna-se baseline do primeiro mês.
Perguntas frequentes
As correções são ilimitadas?
Não, cada nível tem limite de horas.
A monitorização cria encomendas reais?
Normalmente o teste para antes do pagamento.
As atualizações são automáticas?
As críticas passam por snapshot e staging.
Existe suporte 24/7?
Não, a resposta segue o horário CET.
Posso começar sem Rescue Sprint?
Sim, após baseline audit pago.
Envie loja, frequência de releases e custo da falha.
Receberá nível recomendado e âmbito inicial.
Enviar dados da loja por email