type=CREDIT e subtype=CREDIT_CARD. Os limites,
o status e as datas de fechamento/vencimento vivem em creditData; as faturas vivem no recurso
Bill; e as compras (inclusive parcelamentos) chegam como transações com creditCardMetadata.
Todos os endpoints exigem o header
X-API-KEY e respondem em https://api.malvo.io. As
transações de cartão são normalizadas: a convenção de sinal de amount é diferente da de
contas bancárias — veja Convenção de sinal.A conta de cartão (type=CREDIT)
Liste as contas do Item e filtre por type=CREDIT para encontrar os cartões.
creditData:
Account (type=CREDIT)
creditData:
Cartão que a instituição deixou de compartilhar
No Open Finance, cada cartão é um recurso do consentimento. A instituição pode tirar um cartão já sincronizado do consentimento ou suspendê-lo por um tempo. Quando isso acontece, a Malvo para de buscar o cartão, mantém a conta, as faturas e as transações já recebidas, e não avança oupdatedAt dele. O Item termina UPDATED com executionStatus=PARTIAL_SUCCESS, e
statusDetail.creditCards traz isUpdated: false com um destes avisos:
message traz os quatro últimos dígitos do number quando ele existe. Quando o cartão volta a
ser compartilhado, o aviso some e a coleta continua de onde parou, sem reimportar os 12 meses de
histórico. Nenhum webhook novo é emitido: o aviso chega no item/updated da sincronização.
Cartão novo que a instituição já anunciou no consentimento, mas ainda não serve, aparece como
RESOURCE_NOT_PUBLISHED. Nesse caso não é preciso reconectar.
Faturas (GET /bills)
Liste as faturas de um cartão passando o accountId (obrigatório, e precisa ser uma conta
CREDIT_CARD):
Bill
No
additionalInfo dos encargos: o campo é livre, mas obrigatório quando type = OTHER.
Em GET /bills/{id} (retrieve), o objeto também traz accountId e cada encargo carrega o
creditCardBillId da fatura-pai.Conferindo o fechamento (settlement check)
Uma faturaN está quitada quando os encargos e pagamentos da fatura seguinte (N+1)
fecham a conta:
Disponibilidade
Em produção (Open Finance), faturas estão disponíveis para todas as instituições reguladas.Fatura fechada sem transações
Algumas instituições publicam a fatura fechada antes das compras dela. Nesses cartões, a fatura pode aparecer emGET /bills alguns dias antes de GET /transactions?accountId={accountId}&billId={billId}
trazer qualquer resultado.
Quando surge um billId novo sem transações, a Malvo relê o histórico do cartão sem esperar a
cadência semanal, dentro do teto de 4 leituras de histórico por mês. Se as compras ainda não vierem,
há uma nova tentativa cerca de 24 h depois. Depois disso, o Item traz o aviso CC_001 em
statusDetail.creditCards.warnings:
transactions/created. Detalhes
em Limites do Open Finance Brasil.
Parcelamentos via creditCardMetadata
O Open Finance não fornece um id único agrupando todas as parcelas de uma mesma compra.
Cada parcela aparece como uma transação com o objeto creditCardMetadata, que carrega o número
da parcela, o total de parcelas, o valor cheio e — quando a fatura fecha — o billId.
Transação parcelada
Ciclo de vida da parcela
1
PENDING — sem billId
A compra aparece nas transações correntes (últimos 7 dias) com
status=PENDING e sem
creditCardMetadata.billId — a fatura ainda está aberta.2
POSTED — billId definido
Quando o extrato fecha, a transação vira
status=POSTED e creditCardMetadata.billId é
preenchido. Essa transição dispara o webhook transactions/updated.3
Leitura por fatura
As transações de uma fatura fechada específica são lidas pelo filtro legado
GET /transactions?accountId={accountId}&billId={billId}.Convenção de sinal do amount no cartão
Em contas de cartão (type=CREDIT) o sinal de amount é invertido em relação a contas
bancárias, mas o campo type continua normalizado para a perspectiva do titular:
Em contas bancárias (
type=BANK) é o oposto: débitos são negativos e créditos positivos,
e o sinal sempre concorda com type. Trate cada tipo de conta separadamente ao somar gastos.Valores em reais
amount, creditCardMetadata.totalAmount e Bill.totalAmount são números decimais em reais,
com até duas casas. R$ 173,90 (17.390 centavos) chega no JSON como 173.90, e não como o inteiro
17390. A unidade é a mesma em produção e no sandbox. Um valor que a instituição
envia como "184.2700" chega como 184.27.
Gotchas por instituição
Algumas instituições expõem parcelamentos de formas diferentes. Trate estes casos explicitamente ao consolidar gastos:BTG (connectorId 614) — parcelas futuras como PENDING
BTG (connectorId 614) — parcelas futuras como PENDING
O BTG traz todas as parcelas futuras já como transações
PENDING. Se você somar tudo
sem filtrar por status, vai contar gastos que ainda não ocorreram. Para o gasto do mês,
use apenas as parcelas POSTED (ou o installmentNumber corrente).Realize — billClosingDate igual ao dueDate
Realize — billClosingDate igual ao dueDate
A Realize devolve
billClosingDate igual ao dueDate e publica as compras da fatura fechada
só no histórico do cartão. A Malvo não usa a data de fechamento como gatilho: a releitura parte
do billId novo na lista de faturas. Veja
Fatura fechada sem transações.XP (connectorId 602) — valor total da compra
XP (connectorId 602) — valor total da compra
A XP traz o valor total da compra (não o valor da parcela individual). Antes de somar,
cheque
creditCardMetadata.totalInstallments/installmentNumber e divida pelo total de
parcelas para não inflar o gasto.Como testar no sandbox
Nos conectores mockados locais (0–99), o cartão fecha no dia 8 e vence no dia 15, no fuso
America/Sao_Paulo. As compras do ciclo aberto chegam como PENDING, sem billId, e a fatura
desse ciclo não aparece em /bills. Para ver a transição PENDING → POSTED sem esperar o
fechamento, chame POST /items/{id}/sandbox/close-bill
com uma aplicação SANDBOX: o ciclo aberto fecha, as mesmas transações recebem o billId e você
recebe transactions/updated. Os valores continuam em reais (173.90), como em produção. No
sandbox, todo o ciclo aberto aparece como PENDING, e não só a janela de 7 dias de produção.
Detalhes, códigos de erro e limites do mock estão na página Sandbox.
Próximos passos
Sincronizar transações
Paginação por cursor e atualização incremental com
createdAtFrom.Reconciliação
Webhooks + job noturno para nunca perder uma transição PENDING→POSTED.