¿Cómo testearías una función que llama a una API de pagos de terceros?

Aísla la frontera. Pon la llamada HTTP detrás de un cliente ligero, y en los tests sustitúyelo por un doble o parchéalo donde se usa, no donde se define. Usa fixtures de pytest para la preparación y parametrize para los casos de éxito, fallo y timeout. Añade un pequeño conjunto de tests de contrato contra el sandbox real para que los mocks no se desalineen.

La testeabilidad es primero una cuestión de diseño. Si la llamada de pago está enterrada dentro de la lógica de negocio, la saco a una clase cliente con un par de métodos, y entonces la lógica recibe ese cliente como argumento. Llegado ese punto, la mayoría de los tests no necesitan librería de mocking ninguna, porque le paso un doble pequeño que devuelve respuestas preparadas, y eso se lee mejor que una pila de decoradores patch. Donde sí parcheo, parcheo el nombre en el módulo bajo test, no en el módulo de la librería, porque parchear donde se define no hace nada una vez que ya se ha importado en otro sitio. Las fixtures construyen los objetos, y parametrize cubre los casos interesantes: aprobado, rechazado, timeout y un payload mal formado, porque las ramas de fallo son las que de verdad se rompen en producción. También mantengo un puñado de tests contra el sandbox del proveedor, etiquetados para que corran de noche y no en cada commit. Eso cazó un cambio en el que el proveedor empezó a devolver un código de error que nunca habíamos mockeado.