A pergunta certa não é "API ou UI", é "o que cada camada cobre que a outra não cobre":

Teste de API é mais barato e mais estável para conferir a regra de negócio em si: o cancelamento muda o status certo, o valor do reembolso está correto, casos de borda (cancelar duas vezes, cancelar um pedido já entregue) respondem com o erro esperado. Como não depende de navegador nem de seletor, cobre mais variações de dado com menos custo de manutenção.
Teste de UI é necessário para confirmar o que a pessoa realmente vê: o botão de cancelar aparece no momento certo, a mensagem de confirmação é clara, o valor do reembolso aparece formatado certo na tela. Isso só existe no navegador, nenhum teste de API cobre.
Na prática, o caminho mais comum é: várias combinações e casos de borda cobertos por teste de API (rápido, barato, fácil de rodar em CI), e um ou dois testes de UI de ponta a ponta confirmando que o caminho feliz (e talvez um erro visível) aparece certo pra quem usa o produto.

A armadilha a evitar é duplicar o mesmo caso nas duas camadas sem motivo: se o teste de API já garante que o reembolso está correto, o teste de UI não precisa reconferir todas as variações de valor, só precisa confirmar que a tela mostra o que a API devolveu.

Prova do Módulo 5