Agora é possível informar a configuração de frequência e dia de repasse no momento da criação de uma subconta via API.

Essa melhoria permite que o marketplace defina, desde a criação da subconta, como e quando os valores deverão ser repassados, trazendo mais flexibilidade operacional, padronização do fluxo e redução de ajustes manuais posteriores.

Detalhes técnicos: • Foi adicionado o nó MerchantPaymentDate ao payload de criação de subcontas. • O nó permite definir: • A frequência de repasse (PlanFrequence.Code); • O dia do repasse (PaymentDay), conforme o tipo de frequência informada. • Quando o nó não é informado, o comportamento padrão permanece sendo repasse diário.

Exemplo de uso:

{
  "MerchantPaymentDate": {
    "PaymentDay": 20,
    "PlanFrequence": {
      "Code": 1
    }
  }
}

Observação:

• Para frequência mensal, o campo PaymentDay deve representar o dia do mês.
• Para frequência semanal, o campo PaymentDay deve representar o dia da semana, conforme os enums disponíveis na documentação.
• Essa configuração segue o mesmo padrão já utilizado em outros fluxos de repasse, garantindo consistência entre APIs.

Agora é possível informar o Vendedor (Vendor) no momento da criação de uma assinatura via API. Essa melhoria traz mais flexibilidade e controle para os merchants, permitindo identificar com precisão quem realizou a venda, além de facilitar o pagamento de comissões e a conciliação financeira.

Detalhes técnicos: • O campo vendor foi adicionado ao payload da API de criação de assinatura. • O campo segue o mesmo padrão já utilizado em transações avulsas. • Exemplo de uso:

{
 ...
  "vendor": "fulano"
}

Observação: Antes, o campo Vendor era informado apenas na criação de transações avulsas. Com essa atualização, o mesmo comportamento se estende também para assinaturas recorrentes, mantendo a consistência entre os dois fluxos.

A API de consultas de transações e callbacks agora retorna um objeto TransactionStatusHistory contendo o histórico completo de alterações de status de cada transação.

Essa melhoria permite que o Merchant saiba a data e hora de cada alteração de Status, de forma equivalente ao que é exibido no painel Admin, melhorando rastreabilidade e auditoria de transações.

Como funciona

O objeto TransactionStatusHistory é devolvido no body do response de consultas e callbacks, contendo um array de status, conforme o exemplo abaixo:

{
  "TransactionStatusHistory": [
    {
      "Code": "6",
      "Name": "Estornado",
      "ChangedDate": "2025-08-28T10:02:15.238308-03:00"
    },
    {
      "Code": "3",
      "Name": "Autorizado",
      "ChangedDate": "2025-08-26T10:22:41.735405-03:00"
    },
    {
      "Code": "1",
      "Name": "Pendente",
      "ChangedDate": "2025-08-25T20:43:13.735308-03:00"
    }
  ]
}

⚠️

O novo objeto será retornado apenas em endpoints de consulta de transações e callbacks. Nenhuma alteração é necessária no payload de criação ou atualização de transações.

A bandeira Hipercard foi descontinuada em 30/06/2025. Os cartões Hipercard migrarão para a bandeira Mastercard. Após essa data, transações com a bandeira Hipercard serão recusadas.

Os portadores da bandeira serão comunicados e orientados para a substituição para Mastercard pela própria bandeira Hipercard. Caso tenha dúvidas, contate a bandeira.

Foi corrigido um bug recorrente nos webhooks de cartão de crédito, onde o objeto Origem, contendo o identificador SingleSaleHash, não estava sendo retornado corretamente nas transações vinculadas a cobranças do tipo CARD.

O que mudou:

Agora, sempre que houver vínculo entre a transação e a cobrança, o webhook irá incluir o campo Origem com o valor correto do SingleSaleHash.

Essa informação é essencial para rastreamento, reconciliação e validação antifraude por parte dos merchants integrados.

Sistemas impactados:

• Módulo de Checkout
• Envio de webhooks de cartão de crédito

Essa correção garante mais integridade nas informações enviadas via webhook e maior segurança para a jornada de pagamento.