Como você testaria uma função que chama uma API de pagamento de terceiro?

Isole a fronteira. Ponha a chamada HTTP atrás de um cliente fino, e nos testes substitua por um fake ou aplique patch onde ele é usado, não onde é definido. Use fixtures do pytest para setup e parametrize para os casos de sucesso, falha e timeout. Adicione um conjunto pequeno de testes de contrato contra o sandbox real para os mocks não desviarem.

Testabilidade é primeiro uma questão de design. Se a chamada de pagamento está enterrada dentro da lógica de negócio, eu puxo ela para uma classe cliente com alguns métodos, e aí a lógica recebe esse cliente como argumento. Nesse ponto a maioria dos testes não precisa de biblioteca de mock nenhuma, porque eu passo um fake pequeno que devolve respostas prontas, o que é mais fácil de ler do que uma pilha de decorators de patch. Onde eu dou patch, eu dou no nome dentro do módulo sob teste, não no módulo da biblioteca, porque dar patch onde ele é definido não faz nada depois que ele foi importado em outro lugar. As fixtures montam os objetos, e o parametrize cobre os casos interessantes: aprovado, recusado, timeout e um payload malformado, já que os ramos de falha são o que realmente quebra em produção. Também mantenho um punhado de testes contra o sandbox do provedor, marcados para rodar toda noite em vez de a cada commit. Isso pegou uma mudança em que o provedor começou a devolver um código de erro que nunca tínhamos mockado.