Paga uma fatura de cartão de crédito, total ou parcialmente.
O pagamento é por LISTA de lançamentos: envie em installment_ids os installment_id que GET /credit-card-invoices/ devolve em entries[], e o valor é derivado deles no servidor (não há campo amount). Lista ausente ou vazia paga a fatura inteira. Os lançamentos pagos ganham data de pagamento — a movimentação vinculada de cada parcela passa a “pago”. Os lançamentos NÃO selecionados são realocados para a fatura seguinte, com o vencimento da movimentação acertado para o dela; nunca viram despesa nova e nunca alteram o DRE. include_previous_balance=false deixa o saldo anterior rolar de novo para a fatura seguinte (RN5). Envie idempotency_key para tornar retries seguros: replay da mesma chave devolve o pagamento original com 200, sem debitar a conta de novo.
Authorizations
Token da sessão no cabeçalho Authorization, no formato Bearer (mesmo esquema ApiKeyAuth do contrato).
Headers
company uuid
Path Parameters
Invoice ID
Body
Payment data
IdempotencyKey é opcional — sem ela, duplo clique registra dois pagamentos parciais legítimos e indistinguíveis (plan.md).
IncludePreviousBalance decide se o saldo anterior (o remanescente que rolou de uma fatura passada) entra neste pagamento. Ausente ⇒ true.
Ponteiro para distinguir "não enviado" de "false" — a diferença entre pagar a fatura inteira e deixar o saldo anterior rolar de novo.
InstallmentIDs é a lista de lançamentos da fatura que este pagamento
liquida — os installment_id que GET /credit-card-invoices/{id} devolve
em entries[] (plan-parcelamento.md §3.2, item 13 da lista de testes).
AUSENTE ou VAZIA ⇒ a fatura inteira. É o caso comum e o comportamento de antes desta mudança.
── Por que a lista substituiu amount ─────────────────────────────────
O valor agora é DERIVADO da seleção, no servidor: soma das parcelas escolhidas mais, se incluído, o saldo anterior. Com isso somem de vez o "valor não bate com a fatura" e a pergunta que o modelo antigo não sabia responder — QUAIS lançamentos esse dinheiro pagou. É o que permite baixar as movimentações vinculadas (item 11).
Seleção por LANÇAMENTO e não por movimentação: parcela de dívida legada
não tem transaction_id e ainda assim precisa ser pagável.
Response
replay idempotente — nenhum dinheiro se moveu nesta chamada
MovedInstallmentIDs são os lançamentos NÃO selecionados, realocados para NextInvoice com o vencimento da movimentação acertado para o dela. Vazio quando a fatura foi paga inteira.
NextInvoice é a fatura que recebeu a rolagem — nil quando o pagamento quitou a fatura sem sobra.
SettledInstallmentIDs são os lançamentos que ESTE pagamento liquidou — os mesmos ids que o cliente enviou em installment_ids, ou todos os da fatura quando a lista veio vazia. A movimentação vinculada a cada um passou a "pago".