Visão geral dos backends resilientes

Atualizado em 2 de out. de 2026·6 min de leitura

Um backend resiliente é a sua própria cópia da API de um provedor. Ele responde nos mesmos caminhos que a dele, devolve os mesmos formatos de resposta e os mesmos códigos de status, e se comporta do jeito que o provedor se comporta. A sua integração troca a URL base e mais nada.

A palavra resiliente é sobre propriedade. O backend é só seu, ele fica de pé quando o sandbox do provedor cai, e ele produz as falhas que o dele não dá.

Duas formas de rodar um

Um backend roda de uma de duas formas:

Hospedado: a gente roda o backend para você, e ele responde num endereço próprio. Os seus backends hospedados aparecem em Simulações.
Self-hosted: você baixa o backend como imagem e roda ele na sua própria rede. Os seus backends self-hosted aparecem em Self-hosted.

No fundo os dois são o mesmo backend, então os tipos e os gatilhos mais abaixo funcionam igual nos dois. Você compra provedores na Loja de backends, na barra lateral, e o seletor no canto de cima à direita define para qual tipo de backend você está comprando. Cada tipo de backend é comprado separado: um provedor que você tem para backends hospedados não cobre um self-hosted, e vice-versa.

Veja Visão geral dos backends self-hosted.

Por que os times rodam um

O sandbox de um provedor fica fora do SLA de produção. Quando ele cai, o seu release espera, e não tem para quem ligar.
A sua empresa inteira costuma dividir uma conta só do provedor. O que outro time faz lá dentro aparece no seu build.
Alguns provedores só entregam credencial de sandbox depois de uma conversa comercial, e uns poucos nunca entregam para a API que você precisa.
Os casos que valem teste são justamente os que o sandbox de um provedor não produz quando você pede: um cartão roubado, um acerto em lista de sanções, um emissor que estoura o tempo.
Fluxos que mandam uma pessoa para uma página e ficam esperando ali não dá para automatizar contra o original.

Tipos

Um tipo é uma família de provedores com um motor atrás. Estes estão disponíveis hoje.

Pagamentos. Provedores de cartão e de carteira. Autorizar, capturar, capturar em parte, estornar, cancelar, ajustar uma autorização, mais 3D Secure e chaves de idempotência.

Veja Visão geral do backend de pagamentos.

Identidade. Verificação de pessoas e de empresas, KYC e KYB juntos, porque os provedores tratam os dois como uma coisa só. Checagem de documento e de selfie, cruzamento com listas de vigilância, registro e titularidade de empresa, e os fluxos hospedados que normalmente precisam de uma pessoa.

Veja Visão geral do backend de identidade.

Você decide o que volta

Dê ao sujeito de uma requisição o nome do resultado que você quer e é isso que você recebe. Chame o portador do cartão de insufficient_funds e o pagamento é recusado por esse motivo. Chame o solicitante de sanctions_match e a checagem volta com o acerto no relatório que teria encontrado ele.

Os gatilhos são as mesmas palavras em todo provedor, e cada um responde no formato dele. Você escreve o teste uma vez, e adicionar um segundo fornecedor não quer dizer aprender outro conjunto de valores mágicos. Cada provedor também mantém os dados de teste publicados dele, então os números de cartão e os nomes reservados da documentação dele funcionam aqui também.

Quando os gatilhos que vêm junto não cobrem um caso, escreva o seu. Um cenário diz como uma requisição se parece e o que deve voltar, e ele fica em cima do que a gente entrega em vez de substituir.

Veja Escreva os seus próprios cenários.

Como um backend hospedado se encaixa

Os provedores pertencem à sua organização. Você adiciona as marcas que quiser uma vez, e todo backend hospedado que você rodar pode servir elas.

Veja Adicionar provedores.

Um backend hospedado é uma simulação com endereço próprio, e você escolhe quais dos provedores da sua organização ele serve. Dá para rodar mais de um, e cada um guarda os próprios registros. Aponte o CI para um e guarde outro para testar na mão.

Veja Criar um backend hospedado.

Cada backend hospedado responde no seu próprio host:

https://<hostname>.pay.mockz.io    # pagamentos
https://<hostname>.kyx.mockz.io    # identidade

Nesse host, cada versão de um provedor responde sob um caminho com o nome dela:

https://shop-payments.pay.mockz.io/adyen/checkout/v71/payments
https://kyc-checks.kyx.mockz.io/onfido/v3.6/applicants

Tudo depois desse caminho é a rota do próprio provedor. Se o SDK de um provedor só aceita um endereço raiz, a versão dele pode responder na raiz.

Como é uma simulação, o resto do app funciona nele como sempre: histórico de requisições, replays, controle de acesso e links de compartilhamento. Em cima disso ele guarda um registro do que já fez, como os pagamentos recebidos, ou os casos, os sujeitos e os documentos enviados.

Veja Atividade do backend.

A gente publica builds novos de cada tipo, que adicionam provedores e corrigem comportamento. Um backend hospedado segue o build mais recente a não ser que você fixe ele em um, e um backend fixado fica lá até você mesmo mover.

Veja Fixar uma versão de build.

O que você precisa

Um backend hospedado roda num plano que inclui backends, e precisa de uma certa quantidade de memória só para subir. A Loja de backends te diz onde você está antes de comprar qualquer coisa, e aponta os planos se o seu não conseguir hospedar um. Backends self-hosted não dependem do seu plano.

Os provedores são cobrados separado do seu plano:

Hospedado: uma assinatura por tipo, paga por mês ou por ano com o cartão do seu plano. O seu primeiro pedido de cada tipo roda de graça por um período de teste. Nada é cobrado pelo teste, e para manter os provedores depois você faz o pedido de novo.
Self-hosted: pago por mês no cartão ou por ano com fatura.

Só os owners da organização compram provedores, e cancelam eles em Faturamento, em Assinaturas. Todo o resto pode usar o que a organização tem.

Veja Assinaturas.