Cada provedor de que o seu produto depende, recriado para testes
APIs de pagamento e de identidade com as regras reais e as falhas reais delas. Os endpoints e as respostas batem com os do provedor, então você troca um endereço e nenhum código. A gente hospeda, ou você roda na sua própria rede.
Por que os sandboxes dos provedores não bastam
- Muitos provedores não têm sandbox nenhum, principalmente os de nicho e os regionais.
- Os sandboxes que existem têm limite. O da Stripe aceita 25 requisições por segundo, um quarto do que a produção permite. E nenhum falha quando você pede.
- Então os times escrevem os próprios fakes. Os fakes se afastam da API real: os testes passam, depois a produção quebra.
- Cada provedor tem as próprias regras de teste, e só umas poucas pessoas do time conhecem.
- Os times publicam mais mudanças do que nunca, muitas escritas por IA, e cada mudança precisa ser testada contra cada provedor que ela toca.
“Outra opção recomendada é criar integrações com um sistema configurável, que você pode ativar para testes de carga, que simule solicitações à API Stripe.”
Esse sistema configurável é o que a gente constrói, para cada provedor de uma área. E mantém atualizado quando as APIs deles mudam.
O que você ganha
Um endereço, sem mudança de código
Mesmos caminhos, corpos de requisição, campos de resposta e códigos de status do provedor. Sua biblioteca cliente, seu tratamento de erro e seus testes ficam como estão.
Comportamento real, não respostas prontas
Aprovações, recusas, estornos, a etapa de 3D Secure do banco, um documento que não passa na análise. O estado segue de uma chamada para a próxima, como em produção.
Falhas quando você pede
Dê ao titular do cartão ou ao solicitante o nome do resultado que você quer, e é isso que volta. Uma regra pode fazer todos os provedores recusarem de uma vez.
Um só conjunto de casos de teste para todos os provedores
Os mesmos gatilhos funcionam em todos os provedores de uma área. Somar um provedor não significa aprender um novo conjunto de valores mágicos.
Provedores sem sandbox próprio
Alguns provedores não têm sistema de teste. Outros só liberam credencial depois de uma call de vendas. Nos dois casos, a gente constrói a partir da API publicada deles.
A versão que você roda em produção
Fique na versão da API do provedor que você tem em produção, por mais que a gente publique. Você escolhe quando subir.
O que já está pronto, e a sua área depois
Pagamentos
12 provedores
Autorizações, capturas, estornos, 3D Secure, e os códigos de recusa que um sandbox de verdade não te dá.
Provedores de pagamento →Identidade (KYC e KYB)
2 provedores
Verificação de identidade e de empresas. Checagem de documento e selfie, cruzamento com listas de vigilância, fluxos hospedados para o solicitante, e os resultados que você precisa testar.
Provedores de identidade →A próxima
Sua área
Dispositivos, entregas, energia, ou a API interna de outro time. Qualquer coisa de que o seu produto dependa.
Conte o que você precisa →Hospedado por nós, ou na sua rede
Hospedado
A gente roda. Cada backend responde no próprio endereço, hospedado no mundo todo.
- Cobrado por provedor, além do plano que você já tem. O app mostra o preço antes de cobrar qualquer coisa.
- Precisa do plano Pro ou superior.
- 7 dias grátis, uma vez para pagamentos e outra para identidade.
Self-hosted
Você roda. Uma imagem Docker para cada laptop, runner de CI e cluster que você tiver.
- Guarda os dados no banco de dados que você já usa.
- Pago por ano, não precisa de conexão nenhuma conosco.
- Sem limite de instalações nem de requisições.
- 14 dias grátis, com todos os provedores.
Para que os times usam
Uma suíte que roda em cada pull request
Quando a organização inteira divide uma conta só do fornecedor, o que um time faz lá quebra o build de todo mundo. Aponte o CI para o seu próprio backend e isso acaba.
Um teste de carga antes de um grande dia
O sandbox de um provedor te limita muito abaixo da produção, e a Stripe desaconselha teste de carga lá. Aponte o teste de carga para o seu próprio backend. No self-hosted, o único limite é o seu hardware.
Um plano B para o dia em que o deles cai
Sandboxes de fornecedor caem por manutenção, por incidente, às vezes por um fim de semana inteiro, e nenhum SLA cobre isso. Seu time espera e o release atrasa. Aponte a URL base para cá e siga.
Os fluxos que normalmente precisam de uma pessoa
Alguns passos mandam o usuário para uma página no navegador e esperam ali. A gente serve essa página, então o seu teste consegue passar por ela e fechar o caso.
Somar ou trocar de provedor
Rode a sua suíte contra o fornecedor que você tem e o que está avaliando, antes de alguém assinar qualquer coisa. Os gatilhos são os mesmos nos dois, então o que você vê é a diferença entre as APIs deles.
Demos e treinamento sem conta real
Mostre o produto, treine gente nova do suporte, faça um workshop. Ele responde como o de verdade, e não consegue mover dinheiro nem encostar no documento de ninguém.
O que está disponível
14 provedores
| Provedor | Tipo | Cobertura | Métodos | Endpoints |
|---|---|---|---|---|
| Pagamentos | Global | Apple Pay, Cards, Google Pay, PayPal | 5 | |
| Pagamentos | North America | Cards | 3 | |
| Pagamentos | Global | Cards | 7 | |
| Pagamentos | North America · 1 país | Apple Pay, BNPL, Cards, Google Pay, OXXO, Pay by Bank, SPEI | 8 | |
| Pagamentos | Global · 23 países | Direct Bank Transfer, Direct Debit, Klarna, Pay Later, Pay Now, Pay Over Time | 7 | |
| Pagamentos | South America · 7 países | Account Money, Apple Pay, Boleto, Cards, Efecty, Google Pay, OXXO, Pago Fácil, Pix, PSE, Rapipago, SPEI | 11 | |
| Pagamentos | Global | Cards, PayPal | 10 | |
| Pagamentos | Global | Apple Pay, Cards, EPS, Google Pay, MyBank, Neteller, PayPal, paysafecard, Paysafecash, Rapid Transfer, Skrill, Skrill 1-Tap, Venmo | 6 | |
| Pagamentos | Europe · 1 país | Apple Pay, BLIK, Cards, Google Pay, PayPal, PayPo | 6 | |
| Pagamentos | APAC · 3 países | Cardless EMI, Cards, EMI, Netbanking, Pay Later, UPI, Wallets | 4 | |
| Pagamentos | Europe | Apple Pay, Cards, Google Pay | 1 | |
| Pagamentos | Global | Cards, PayPal | 11 | |
| KYC/KYB | Global | Document, Facial Similarity Photo, Identity Enhanced, Known Faces, Proof of Address, Watchlist AML | 31 | |
| KYC/KYB | Global | Database Verification, Document, Government ID, Phone Number, Selfie, Watchlist | 31 |
Nomes e marcas dos fornecedores pertencem aos donos deles. O Mockzilla não é afiliado, endossado nem patrocinado por nenhum deles. Estas são implementações compatíveis, construídas de forma independente a partir de APIs documentadas publicamente, não os serviços próprios dos fornecedores.
Um provedor que ainda não cobrimos
A gente constrói uma área inteira para você: cada provedor que o seu produto usa para uma tarefa, com os fluxos e as falhas que importam para você.
- 1
Mapear
Um workshop sobre quais provedores, fluxos e falhas importam.
- 2
Primeira versão
Responde desde o primeiro dia a partir das descrições de API dos provedores. Depois a gente soma comportamento, um fluxo de cada vez.
- 3
Rodar
Hospedado por nós, dentro da sua rede ou totalmente sem conexão. O motor por baixo é de código aberto, então não tem lock-in.
- 4
Manter atualizado
A gente acompanha as mudanças de API dos provedores e publica atualizações.
Um valor único para construir, e depois mensal ou anual para rodar e manter atualizado.
Traga um spec. Leve um servidor mock.
Começar não custa nada. Infraestrutura dedicada quando precisar.