Pedido de R$200 com split 90/10 e nada estornado. Devolução total: o DELETE tem de sair com amount 20000 e split 18000 (loja) + 2000 (comissão). É o caminho feliz — se a comissão não entrar aqui, o defeito dos 90% voltou.

Pedido de R$200 (2 × R$100), nada estornado. Devolve R$100: DELETE com amount 10000 e split 9000 + 1000 — a comissão é devolvida proporcionalmente, não só no total.

O DEFEITO do estorno que não acontecia. Os payables já refletem o primeiro estorno de R$100, então a primeira aprovação é no-op legítimo (nada a estornar). A segunda devolução de R$100 tem de sair: DELETE com amount 10000 (9000 + 1000). Antes do fix o alvo era o valor de UM Refund, o cálculo achava que os R$100 já cobriam tudo e o segundo estorno era descartado como 'já estornado no gateway' — devolução registrada no HAASS e valor capturado na Pagar.me.

O DEFEITO dos 90%. O split da charge tem loja + comissão, mas os payables trazem só a loja — nem a heurística nem a inferência classificam o recipient de comissão. Antes do fix saía DELETE com os 90% da loja e os 10% ficavam capturados, em silêncio. Agora o builder falha: ZERO DELETE, e o pedido vai para EstornoFalhou pelo fault consumer (a transição não é observável aqui — o assert é a ausência do estorno com as leituras presentes).

Payables mostram o pedido inteiro já estornado (capacidade zero nos dois recipients). O cálculo devolve distribuição vazia e o handler faz early-return: ZERO DELETE. É a idempotência por capacidade — protege o reprocesso do consumer (retry 5×) de estornar duas vezes. Aqui o 0× é o resultado CORRETO, e é o que distingue este cenário do 'sem comissão': lá o dinheiro estava lá e não sabíamos de quem cobrar.

Operador marca AlreadyRefundedInAcquirer (já estornou no painel da adquirente). O fluxo tem de pular o gateway INTEIRO — nem DELETE nem as leituras de order/payables — e gravar RefundSource = Manual. Exige que o operador do harness tenha perfil AdminMaster; sem isso o ConfirmRefundRequest devolve 401 e o passo fica vermelho.