Como não perder dinheiro na caixa preta: métodos de teste de cobrança

A validação de serviços pagos é um dos principais problemas de engenharia no teste do Badoo. Nosso aplicativo é integrado a 70 provedores de pagamento em 250 países do mundo, e um bug em pelo menos um deles pode levar a conseqüências imprevisíveis.

Neste artigo, falarei sobre os métodos de teste que usamos no Badoo e os limites de aplicabilidade desses métodos - os estágios dos testes nos quais eles são mais eficazes.

Este artigo será útil para testadores, desenvolvedores e gerentes de produto, cujos projetos já estão integrados aos provedores de pagamento ou o processo de integração está apenas começando. Se no seu trabalho você se deparar com o problema de escolher métodos de teste para essas integrações, seja bem-vindo ao gato!




Meu nome é Vladimir Solodov, sou engenheiro de controle de qualidade no Badoo: estou envolvido na verificação de integrações de teste e processamento de pagamentos. Meu colega Viktor Koronevich me ajudou na preparação do texto: juntamente com ele, fizemos uma reportagem na conferência Heisenbug ( vídeo ). No artigo, expandimos a área de descrição para todas as integrações com provedores de pagamento usados ​​no Badoo, classificamos e descrevemos a prática de remover dependências externas com mais detalhes.

Usando estudos de caso de negócios como exemplo, explicarei por que você deve prestar mais atenção ao teste de serviços pagos e como não agravar problemas se eles surgirem. Depois, descreveremos os problemas técnicos da integração de testes e as formas de resolvê-los.

A segunda parte do artigo, na qual falamos mais sobre a automação de teste de serviços pagos em aplicativos iOS, está aqui .

Vamos lá!

Detalhes do teste de faturamento

Normalmente, o objetivo de um negócio é gerar renda. No Badoo, uma rede social de namoro, a renda é obtida por empréstimos e assinaturas premium. Empréstimos são a moeda interna do Badoo. Com a ajuda deles, por exemplo, você pode aumentar seu perfil nos resultados da pesquisa em primeiro lugar, fazer um presente para outro usuário e muito mais. A assinatura premium é válida por um certo período de tempo e oferece várias opções ao mesmo tempo: ativar o modo "invisível", ver pessoas que demonstraram interesse em você, confirmar a autenticidade da sua conta e muito mais.

Para que esses serviços pagos funcionem, usamos integrações com mais de 70 provedores de pagamento. A escolha do provedor depende da plataforma, país, dispositivo, operadora de celular e outros fatores. Portanto, a questão de testar serviços pagos é muito urgente.

Para começar, considere por que o teste de serviços pagos deve ser abordado com atenção especial. Existem duas razões.

1. Erros de cobrança são críticos para os negócios.

O primeiro problema é de reputação. O usuário que pagou pelo serviço se torna mais sensível (e menos tolerante) a erros no aplicativo. Qualquer comentário no espaço público, seja uma revisão de um aplicativo de blog ou um comentário na App Store ou no Google Play, de um usuário que encontra um bug em um serviço pago, será mais emocional - esse é um fator que leva à perda de reputação.

O segundo problema é que, assim que você começa a receber dinheiro de um usuário por um serviço, você se torna objeto de uma lei que protege o consumidor do serviço. E as perdas de reputação podem facilmente se transformar em financeiras.

As empresas perdem dinheiro de três maneiras.

A primeira maneira é restituições . Suponha que um usuário descubra que você lhe vendeu um serviço que não atende exatamente às expectativas dele. Nesse caso, ele entrará em contato com sua equipe de suporte. Seus funcionários conduzem uma investigação e descobrem que as expectativas do usuário realmente não se concretizaram devido a um bug no aplicativo. Você inicia um reembolso. Nesse caso, há um reembolso: como resultado, a empresa se depara com lucros perdidos e essa é a maneira mais inofensiva de perder dinheiro.

A segunda maneira são os estornos . Suponha que a mesma situação ocorreu, apenas o usuário não entrou em contato com o serviço de suporte, mas o banco que emitiu o cartão ou o provedor de pagamento. O banco / provedor inicia um reembolso. Nesse caso, estamos lidando com um estorno. O perigo para os negócios aqui não está apenas nos lucros perdidos. Após um certo número de estornos, a empresa recebe uma multa e sua classificação de risco diminui. O rebaixamento, por sua vez, leva a um aumento no custo dos serviços dos provedores de pagamento.

A terceira via - ações judiciais (reivindicações) . Nos casos mais negligenciados, ações judiciais (inclusive coletivas) podem ocorrer, levando às conseqüências mais graves. Portanto, em 2015, após uma ação judicial do regulador da Ofgem, a British Gas foi forçada a pagar uma compensação multimilionária aos usuários que cobravam uma taxa mais alta devido a um erro no sistema de cobrança. Leia mais sobre isso aqui .

2. Para testar integrações, são necessários conhecimento e experiência.

As equipes que estão iniciando o processo de integração com os provedores de pagamento geralmente enfrentam esse problema. Sem conhecer todos os casos de cobrança possíveis, eles perdem nuances importantes quando percebem a reação do sistema às notificações dos provedores de pagamento.

Isso pode levar a consequências imprevisíveis - de lucros perdidos a usuários insatisfeitos.

Vamos examinar o esquema que lista os tipos de serviços pagos e considerar o problema com mais cuidado.


Figura 1. Possíveis casos de cobrança

Existem três casos principais: um erro, um pagamento bem-sucedido e um reembolso ao usuário. Mas cada caso tem detalhes, cada caso que seu sistema precisa lidar de maneira diferente.

Os erros podem ser críticos e não críticos. O erro de notificação pode ser atribuído ao bloqueio não crítico - quando o provedor de pagamento informa sobre a falta de fundos na conta do usuário e o bloqueio crítico do método de pagamento do usuário. E se, no primeiro caso, você pode tentar pagar mais tarde, no segundo - seria bom descobrir por que o método está bloqueado. Talvez o usuário tenha sido notado em fraude e você deva ter mais cuidado com as transações dele.

Reembolsos . Você já sabe que existem dois tipos de devoluções: reembolsos e estornos. Seu sistema deve responder de maneira diferente a eles. Por exemplo, após um estorno, faz sentido pensar em bloquear algumas funções do seu aplicativo para o usuário, porque o estorno é um dos métodos de fraude mais populares.

Um pagamento bem-sucedido pode ser um pagamento único ou uma assinatura.

Os pagamentos únicos podem ser consumíveis e não consumíveis. Um exemplo de pagamento gasto que examinamos no início do artigo - esses são empréstimos no Badoo. Um exemplo de pagamento não dispensável pode ser dado em jogos. Suponha que você tenha um personagem que interpreta. Você quer comprar para ele superpotências que já existem há algum tempo. Nesse caso, a compra pertence à classe de pagamentos não dispensáveis.

Assinaturas Aqui está a maior variedade de casos. Além da compra inicial de uma assinatura, você pode ter:

• renovação de uma assinatura (renovar);
  
• fechar assinatura (cancelar assinatura);
  
• assinatura de avaliação (avaliação);
  
• assinatura do período de carência: quando não podemos renovar a assinatura e tentar pagar novamente por um período chamado período de carência. Para o usuário, o período de cortesia é assim. Suponha que você comprou uma assinatura mensal de jornal. A empresa que envia jornais está tentando cancelar o pagamento para o próximo mês de assinatura após o final do primeiro mês, mas não pode fazer isso (devido a um bloqueio do cartão, falta de fundos na conta etc.). Se o período de validade do período de carência for de dez dias, durante esse período, a empresa tentará cancelar o pagamento, enquanto a assinatura permanecerá válida. Se a empresa não puder amortizar o dinheiro, a assinatura será cancelada. Se for, a assinatura é renovada a partir da data do último pagamento;
  
• pagamento parcial (faturamento parcial). Por exemplo, o PayPal permite que você faça pagamentos parciais se a conta do usuário não tiver fundos suficientes (pagamento parcial) ou quebre o pagamento em partes (fatura parcial).
  

Você também precisa levar em consideração duas características totalmente dependentes do provedor de pagamento: a assinatura pode ser controlada pelo seu aplicativo ou gerenciada externamente.

• Uma assinatura gerenciada internamente é, por exemplo, uma assinatura usando cartões de crédito ou PayPal, quando, após o primeiro pagamento, você recebe um token com o qual se aplica novamente ao provedor, sem os detalhes de pagamento do usuário.
  
• Uma assinatura gerenciada externamente é quando o agregador de pagamento assume o controle total de suas assinaturas e simplesmente envia notificações sobre seus status atuais.
  

Na figura, as áreas mais óbvias, cuja reação geralmente é realizada em primeiro lugar, são destacadas em roxo. Todos os outros começam a ser levados em consideração muito mais tarde, como o acúmulo de conhecimentos. Isso é amplamente facilitado pela aplicação incorreta de metodologias de desenvolvimento iterativas no campo do faturamento.


Figura 2. Casos de cobrança que são implementados principalmente em sistemas

Essa implementação em fases pode levar a consequências imprevisíveis. Por exemplo, em um dos projetos em que trabalhei antes do Badoo, a possibilidade de fazer um reembolso não foi levada em consideração. Como resultado, todos os retornos foram feitos não através de reembolsos, mas através de estornos, que afetaram negativamente a classificação de risco da empresa e levaram a falhas na coleta de estatísticas de renda. A ignorância de toda a variedade de casos de cobrança pode levar à perda de lucros ou à vulnerabilidade da empresa aos usuários que se sentem enganados.

Portanto, por um lado, erros no processamento de pagamentos devem ser encontrados antes do lançamento, pois podem levar às consequências mais negativas. Se não foi possível fazer isso, é importante perceber rapidamente que o bug entrou na versão de lançamento do aplicativo, corrigi-lo e, o mais importante, o que muitas pessoas esquecem, "tranquilizar" os usuários que encontrarem esse bug.

Por outro lado, a situação é complicada pelo fato de a integração com os provedores de pagamento sempre interagir com a caixa preta, o que adiciona muitas variáveis ​​ao processo de teste.

Problemas técnicos durante o teste de cobrança

Vamos considerá-los no exemplo de integração do Badoo com a App Store.

As assinaturas na App Store pertencem à classe de gerenciadas externamente, ou seja, são totalmente gerenciadas pelo lado do provedor, e nosso sistema pode solicitar apenas o status atual ou receber uma notificação de sua alteração.

Escolhemos especificamente essa integração, pois é a mais complexa e contém toda a variedade de casos que podem ser encontrados no processo de integração do serviço com outros provedores de pagamento.

Para começar, passamos a uma compra descartável única.


Figura 3. O processo de efetuar um pagamento descartável único

Na etapa 1, o usuário solicita a compra do serviço. O aplicativo decide que o pagamento deve ser feito e, na etapa 2, o controle é transferido para o provedor de pagamento (App Store). Etapa 3: o usuário recebe um formulário para efetuar um pagamento. Etapa 4: o usuário fornece dados para pagamento. Etapa 5: o provedor conclui a transação e reporta o resultado ao aplicativo, retornando um recibo contendo informações completas sobre a compra (data, serviço, status etc.). Etapa 6: a verificação, complementada com os dados do usuário, é enviada ao servidor para processamento. O servidor processa os dados de verificação e gera uma notificação por push para o aplicativo na sétima etapa. Na oitava etapa, a notificação é mostrada ao usuário.

O problema é que as etapas 3, 4 e 5 são executadas no lado do provedor de pagamento, praticamente não são controladas por nós e podem ter várias variações. Portanto, o processo não possui uma estrutura linear, como mostra a Figura 2, mas uma ramificação (veja a Figura 4), e cada ramificação deve ser tratada de maneira diferente pelo aplicativo.


Figura 4. Ramificando um diagrama de estado de pagamento único

A compra de assinaturas começa da mesma maneira que um pagamento único, mas é difícil controlar mais o processo.


Figura 5. Estados de assinatura gerenciados externamente

Deixe-me lembrá-lo de que a assinatura da Apple, que consideramos como exemplo, é gerenciada externamente. Isso significa que o usuário após a compra pode gerenciá-lo de forma assíncrona: feche, altere a data de validade, solicite um reembolso. Vemos isso na etapa 9. Como a ação ocorre fora do nosso sistema, na figura eu a marquei com uma linha pontilhada.

Na etapa 10, a App Store pode alterar o status da assinatura: renove, feche, digite o período de carência na janela.

Para descobrir em que estado está a assinatura, há a etapa 11, que é específica para agregadores, como a App Store e a Google Wallet. Nesta etapa, o sistema envia um token, que é usado como um recibo recebido no início da compra de uma assinatura ou após sua renovação anterior.

Etapa 12 é a resposta do provedor. Recebemos um cheque com o status atual da assinatura. O resultado nesta etapa depende das etapas assíncronas 9 e 10.

No outono de 2018, a Apple para todos implementou um mecanismo de notificações de servidor para servidor , que permite notificar sobre as mudanças que ocorreram com uma assinatura. O recebimento dessa notificação é mostrado na etapa 13. Para a maioria dos outros provedores, o mecanismo de notificação de servidor para servidor é o único, portanto, pode-se argumentar que o exemplo da Apple abrange toda a variedade de casos. No caso de outros provedores, a etapa 13 permite excluir as etapas 11 e 12 do esquema.

Na etapa 14, o servidor gera uma resposta para o aplicativo alterar o status da assinatura.

Assim, obtivemos um gráfico completo dos estados que devem ser passados ​​para verificar os serviços pagos.


Figura 6. O processo completo de alteração dos estados de pagamento (usando uma assinatura gerenciada externamente como exemplo)

As partes que não controlamos em nosso sistema são coloridas em laranja e são caixas pretas para nós.

Métodos de teste de cobrança

Portanto, o principal problema técnico ao testar serviços pagos é a presença de “caixas pretas”, cujos estados temos muito pouco controle. Isso define um conjunto de métodos que podem cobrir toda a variedade de casos.

Não existem muitos desses métodos, e os dividimos em três categorias: pagamentos reais, caixas de proteção e eliminação de dependências externas das "caixas pretas".

Pagamentos reais

Os pagamentos reais como método de teste são bons, pois fornecem uma idéia clara do estado da integração. Um erro ao efetuar um pagamento real é uma evidência incondicional de um bug.

Caso contrário, os pagamentos reais são ruins. Em primeiro lugar, é caro: é óbvio que, para fazer um pagamento real, você precisa gastar dinheiro real. Você se engana se pensa que, no final, todo o valor será devolvido à empresa: primeiro, os provedores cobram uma taxa por cada transação, cujo tamanho, conforme descrito acima, depende da classificação de risco da organização e pode chegar a 40% (e até mais) ; em segundo lugar, você pode perder dinheiro ao testar pagamentos em outros países devido ao spread da moeda - a diferença entre as taxas de compra e venda da moeda (você fará a compra à taxa de venda do banco em moeda estrangeira e o retorno ocorrerá à taxa de compra).

Além disso, esse método pode levar um longo tempo, pois é necessário aguardar o final do período de renovação da assinatura, a conclusão dos períodos de carência e esses podem ser meses.

Sandboxes

Caixas de areia são lindas. Essa é, de fato, a mesma funcionalidade que um provedor de pagamentos nos fornece no caso de um pagamento real, mas sem gastar dinheiro real. É totalmente suportado pelo provedor, o que significa que a integração com a sandbox é barata.

O problema da duração dos testes ao longo do tempo é resolvido, em regra, usando vários truques. Por exemplo, a caixa de proteção da App Store usa a seguinte conversão de expiração de assinatura.

Tabela 1. A proporção do período de validade de uma assinatura real e uma assinatura na sandbox da Apple

As assinaturas padrão da sandbox da Google Wallet estão listadas na tabela 2 e podem ser configuradas no console do vendedor.

Tabela 2. Configurando a duração de uma assinatura na sandbox do Google

Ao contrário da sandbox da Apple, você também pode verificar a avaliação, período de cortesia etc. na sandbox do Google, usando a proporção da Tabela 3.

Tabela 3. Validade de recursos adicionais de assinatura na sandbox do Google

O fechamento de uma assinatura também pode ser implementado de diferentes maneiras: na caixa de proteção da App Store, o fechamento é feito após a quinta renovação e, na Google Wallet, no console do vendedor ou no dispositivo da Play Store.

O problema das sandboxes é que os fornecedores têm uma atitude diferente em relação à sua qualidade. Nossa experiência mostra que dos mais de 70 provedores de pagamento integrados ao Badoo, apenas duas caixas de proteção possuem funcionalidade completa e operação estável. Essas são as caixas de areia do Adyen e do PayPal. Outros provedores são estáveis, mas truncados em termos de caixas de proteção de funcionalidade (como Google Wallet) ou instáveis ​​e extremamente truncados em funcionalidade (como App Store e Fortumo). E existem provedores que não possuem e nem terão uma caixa de areia.


Figura 7. Classificação de sandboxes por estabilidade e funcionalidade

Removendo dependências externas

Se convencemos você de que o teste usando pagamentos reais é caro e ineficiente, e os provedores de pagamento não fornecem caixas de proteção com qualidade adequada, resta ainda recorrer a várias maneiras de eliminar dependências externas. Existem apenas três deles: moki, falsificações e tocos.

Moki no faturamento é a formação das reações do seu sistema a solicitações com parâmetros pré-determinados, sem uma chamada real para o provedor de pagamento (veja a Fig. 8). Por exemplo, uma solicitação para um provedor de pagamento SMS para o número + 7111-111-11-11 é interceptada no estágio de envio de uma solicitação ao provedor e gera uma resposta do sistema na forma de um pagamento bem-sucedido. A solicitação para o número + 7111-111-11-12 também é interceptada, mas leva a uma reação a um erro com o código "Não há dinheiro suficiente para concluir a transação".


Figura 8. Diagrama de simulação

Falhas na cobrança são falsas nas notificações (como se fossem de um provedor real) (veja a Fig. 9). A integração com cada provedor implica um conjunto limitado de reações do sistema a um conjunto limitado de tipos de notificações ou redefinições. ( ), .


9.

— (. . 10), .


10.

, , . (, , ) . , , , , .

. 3, 4, 5 : , . - : , — , — . « ».


11. ( App Store)

, (, ). — , . . , , , . , . , .

. , ? :

• — ?
  
• end-to-end — : - ?
  
• — : , .
  

.


4.

. . . , . : , .

. , , Apple Google, . ( ). end-to-end : . , , .

, , — . . . : .

, , .

, . .

: . , , — .

, : — , , ; — : .


12.

, , , , .

, 12, Badoo.

. . QA- . , . , - , , . , .

: .

, , — . , Apple . . , . : - .

— , . -, . -, , -, , .

— : , Apple . 1 — , .

. , . , - .

, ( ).

Conclusões

1. , .
   
2. ( ) . , .
   
3. « » , . - — . , : , — , — .
   
4. Ao usar falsificações, mokas e stubs, é importante lembrar que esses são modelos de pagamento real e, como qualquer modelo, eles têm um grau de aproximação à realidade e aos riscos. Esses riscos devem ser avaliados e cobertos por pagamentos reais ou por verificações adicionais.
   

Sobre como conseguimos obter uma automação estável e barata de testar serviços pagos em um aplicativo iOS, falaremos no próximo artigo .

Obrigado pela atenção! Todos os grandes lucros e menos bugs!