Estimativa de uma integração de pagamentos
Como estimar uma integração de pagamentos: ambiente de teste x ambiente de produção, reembolsos, webhooks, idempotência, escopo PCI. A conversa que precisa acontecer antes que qualquer valor seja definido.
O bilhete diz “adicionar Stripe”. O texto diz “meio quarto”.
Os pagamentos têm uma interface de API pública que cabe em uma página e uma interface de decisão privada que não cabe. Escolher um provedor é um pico de trabalho de um dia. Configurar o fluxo normal de checkout leva alguns dias. Tudo o que vem depois — o fluxo de reembolso, a política de repetição de webhooks, as chaves de idempotência, o relatório de reconciliação que o departamento financeiro vai solicitar no segundo mês — é o recurso em si, e nada disso está no ticket.
A tarefa que diz “integrar o Stripe” raramente é a tarefa que está sendo estimada. A tarefa que está sendo estimada é “podemos receber pagamentos, reembolsá-los, comprovar que os recebemos e lidar com uma cobrança contestada”. Até que a equipe vote sobre esse escopo, o número é apenas uma estimativa sobre algo diferente.
O que se fala na sala
Backend: “A sandbox é simples. A biblioteca cuida da maior parte do trabalho.”
SRE: “Os webhooks precisam ser idempotentes. Qual é a nossa estratégia de repetição de tentativa caso o Stripe reenvie a solicitação?”
Finanças: “Como os reembolsos são reconciliados? E os reembolsos parciais?”
Conformidade: “Estamos acessando números de cartão ou continuamos seguindo o SAQ-A?”
PM: “O que diz o e-mail sobre o pagamento não realizado e quem o redige?”
Perguntas que vale a pena fazer antes de votar
- Primeiro apenas no ambiente de teste, ou chaves de produção já incluídas desde o primeiro dia?
- Reembolsos e reembolsos parciais — UI, API ou apenas para administradores?
- Idempotência de webhooks e gerenciamento de novas tentativas — quem é o responsável pela tabela de deduplicação?
- Âmbito do PCI: estamos cumprindo o SAQ-A ao nunca acessar o PAN?
- Reconciliação: quem elabora o relatório e com base em qual fonte de verdade?
- Experiência do usuário em situações de falha: cartão recusado, cartão vencido, desafio 3DS — tudo isso está dentro do escopo?
A abordagem correta em um caso como esse costuma ser dividi-lo. “Receber dinheiro” é um caso; “reembolsar dinheiro” é outro; “conciliar dinheiro” é um terceiro. Considerá-los como um único caso é o que leva a integração a ser entregue na terceira semana e o departamento financeiro a perguntar onde está o relatório na oitava semana.
Vote em “provar que recebemos o dinheiro e superamos a disputa”, e não em “chamar a API de checkout”.
Veja também: erros comuns no Planning Poker sobre dividir histórias tarde demais; técnicas de estimativa para trabalhos tão vagos quanto este. Confira os outros exemplos práticos de estimativa, ou participe de uma sessão gratuita de Planning Poker quando o refinamento estiver pronto.