Changelog

A cobrança internacional já dispensava o documento, mas o @validapay/tokenize exigia customer.document e removia as letras do valor, então o comprador estrangeiro não conseguia gerar o cardToken. A partir da versão 1.4.0, o SDK aceita o país do comprador e o documento vira opcional para quem é de fora do Brasil.

O que mudou:

• tokenize() aceita customer.country, com o código ISO 3166-1 alfa-2 do país
• Com país diferente de BR, customer.document é opcional. Se for enviado, o passaporte é aceito com letras, até 30 caracteres
• Cartões de 13 a 19 dígitos são aceitos na tokenização, incluindo Amex
• Comprador brasileiro continua com CPF/CNPJ obrigatório
• O @validapay/3ds 1.2.0 autentica comprador estrangeiro: customer.address.country, telefone em E.164 e documento opcional
• O tokenize também lê o país de customer.address.country, então o mesmo customer serve para os dois SDKs

Atualize para a versão 1.4.0 e informe na tokenização o mesmo país que vai em customer.address.country na cobrança. Não envie CPF fictício: um valor fixo junta compradores diferentes no mesmo cadastro.

const { cardToken } = await tokenize({
  publicId,
  card,
  customer: { name: "John Smith", email: "john@email.com", country: "US" },
});

A mesma cobrança avulsa chegava em formatos diferentes conforme a rota. Criada por POST /v1/charges por valor, vinha com subscriptionId e dados de ciclo de uma assinatura que não existe para você. Criada pelo painel, o charge.created vinha sem os dados do cliente. Agora a avulsa nunca traz subscriptionId, e os eventos saem com os mesmos campos em todas as rotas.

O que mudou:

• POST /v1/charges cria cobranças avulsas e recorrentes, e só devolve subscriptionId na recorrente. A cobrança por valor, ou só com itens de pagamento único, não traz o campo
• GET /v1/charges e GET /v1/charges/{chargeId} trazem subscription: null na avulsa. No detalhe, price também vem null na avulsa por valor
• charge.created, payment.success, payment.failed e charge.expired da avulsa não trazem subscriptionId, interval, currentCycleNumber, nextChargeDate, startDate nem canceledAt
• O payment.success da avulsa mantém currentCycle, com paidAt, nos dois fluxos. Os outros eventos da avulsa não trazem currentCycle
• Os mesmos eventos passam a trazer customer (nome, e-mail, documento e telefone), items (nome, descrição, quantidade, valor e desconto), status, paidAt e as chaves accountNumber e accountId
• O segundo campo de ID da transação, que repetia o valor de transactionId, deixa de ser enviado nos eventos da avulsa. Use transactionId

Se a sua integração usava o subscriptionId de uma cobrança avulsa, passe a identificá-la por chargeId. Para saber se uma cobrança é avulsa, consulte saleType em GET /v1/charges/{chargeId} (ONE_TIME ou RECURRING).

Exemplo de recorte do charge.created de uma avulsa:

{
  "event": "charge.created",
  "chargeId": "cha_1791047440770_nzonv0adh",
  "type": "ONE_TIME_ITEM",
  "status": "PENDING",
  "amount": 12.34,
  "customer": {
    "customerId": "cus_1790435193764_3dixre16i",
    "name": "João da Silva",
    "email": "joao@example.com",
    "taxId": "12345678901",
    "phone": "11999990000"
  },
  "items": [
    { "name": "Consultoria", "description": "Sessão avulsa", "quantity": 1, "amount": 12.34, "discount": 0 }
  ]
}

O charge.created de Pix e boleto criados no painel podia chegar com atraso ou não chegar. Agora ele é enviado antes da resposta da criação. A descrição informada na cobrança também passou a ser gravada e aparece em items[].description no evento.

Contas com a permissão de checkout internacional passam a vender para compradores estrangeiros. O comprador é identificado pelo país do endereço: customer.address.country com um código ISO de duas letras diferente de BR. Sem país, com BR ou com um valor fora do padrão (como "Brasil"), a cobrança segue o fluxo nacional, sem nenhuma mudança.

O checkout público detecta o país do visitante, mostra a página em um de 15 idiomas e exibe o valor aproximado na moeda local, com o aviso de que a cobrança é feita em reais. No painel, "Cartão internacional" virou um método de pagamento do link. Ele é exclusivo: ao ligá-lo, os outros métodos são desmarcados.

O que mudou:

• O comprador estrangeiro paga só no cartão e à vista
• O documento não é exigido; telefone no formato internacional (E.164) e endereço completo são obrigatórios
• Links de pagamento e sessões aceitam internationalEnabled
• A cotação exibida ao comprador fica registrada na cobrança

Sem a permissão, a API responde 403 com o código INTERNATIONAL_CHECKOUT_NOT_ENABLED. Peça a liberação ao suporte. Pix, boleto ou parcelamento para comprador estrangeiro respondem 400 (INTERNATIONAL_PAYMENT_METHOD_NOT_SUPPORTED e INTERNATIONAL_INSTALLMENTS_NOT_SUPPORTED).

Exemplo de recorte do cliente estrangeiro:

POST /v1/charges
{
  "paymentMethod": "creditcard",
  "customer": {
    "name": "John Smith",
    "email": "john@email.com",
    "phone": "+14155552671",
    "address": {
      "country": "US",
      "zipCode": "94105",
      "street": "Market St",
      "number": "100",
      "city": "San Francisco",
      "state": "CA"
    }
  }
}

Os avisos por WhatsApp que levam o botão com o link da fatura, usados em boleto e cartão, falhavam em todo envio, automático ou manual. O modelo de mensagem foi corrigido, e o botão abre a fatura certa. O texto mostrado na tela do produto passa a ser o mesmo que o cliente recebe. Uma falha no envio também deixou de gerar uma cobrança nova a cada tentativa.

O sandbox só simulava o cartão no checkout. Pró-rata, cobrança avulsa e pagamento de fatura falhavam com CHARGE_ISSUE_FAILED qualquer que fosse o cartão. Agora a simulação vale em todos os fluxos, e o número do cartão escolhe o resultado.

O que mudou:

• 4111111111111111 aprova; qualquer outro número de 16 dígitos fora da lista abaixo também aprova
• 4000000000000002 recusa por card_declined, 4000000000000004 por saldo insuficiente, 4000000000000006 por cartão vencido, 4000000000000008 por CVV inválido e 4000000000000010 por suspeita de fraude
• Devolução de PIX e estorno de cartão são simulados e confirmados na hora, com o webhook correspondente
• A sessão de pagamento devolve fingerprint e 3DS como em produção

A consulta de devoluções devolvia formatos diferentes conforme o identificador usado. Agora a resposta é sempre uma lista, e a devolução PIX pode ser pedida só pelo chargeId da cobrança paga.

O que mudou:

• GET /v1/wallet/refunds com refundId, chargeId ou endToEndId responde { "items": [...] }. Sem resultado, responde 200 com items vazio
• Sem identificador, a rota devolve o histórico paginado da conta
• No item, endToEndId substitui originalEndToEndId, e saem returnIdentification, providerChargeId e updatedAt
• POST /v1/wallet/refunds com chargeId busca o endToEndId da cobrança PIX
• Cobrança ainda não paga responde 400 CHARGE_WITHOUT_END_TO_END_ID; chargeId e endToEndId de cobranças diferentes, 400 END_TO_END_ID_MISMATCH; cobrança de outra conta, 404 CHARGE_NOT_FOUND
• No painel, depois de estornar uma cobrança de assinatura, dá para cancelar a assinatura no mesmo modal

Se a sua integração lia a devolução na raiz da resposta ou usava originalEndToEndId, passe a ler items[0] e endToEndId.

O que mudou:

• O horário de envio é escolhido entre opções de 30 em 30 minutos, das 10:30 às 23:59, na régua do produto e no agendamento
• O lembrete no dia do vencimento (D0) passa a ser aceito, o que resolve a recorrência diária, em que o aviso da véspera saía antes de a cobrança existir
• O envio manual por WhatsApp fica disponível também em cobrança de boleto
• A lista de mensagens abre ao ativar a régua no produto

A API aceitava links e sessões que o comprador não conseguiria pagar, e o erro só aparecia no checkout. As validações foram antecipadas.

O que mudou:

• Plano com trial só aceita cartão: link, sessão ou edição com PIX, boleto ou Pix Automático responde 400 TRIAL_REQUIRES_CREDIT_CARD
• Plano removido deixa de ser vendável: o pagamento responde 400 PRICE_INACTIVE, e o link vinculado é desativado
• Cartão sem telefone do cliente, quando o adquirente exige, responde 400 CUSTOMER_PHONE_REQUIRED. Se já existe cliente com o mesmo documento e telefone, esse telefone é usado
• POST /v1/checkout-sessions valida os planos de items na criação

Links já salvos com trial e outros métodos vão dar erro na próxima edição. Deixe só o cartão nesses links.

O que mudou:

• Produto criado com trial podia vender o plano sem o trial e cobrar na hora. O checkout passa a usar o plano configurado
• Gerar PIX ou boleto e recarregar a página bloqueava o comprador como se já tivesse pago. Agora a sessão só fecha quando o pagamento é concluído, e quem volta ao link vê o mesmo código
• O redirectAfterPaymentUrl da sessão passa a redirecionar o comprador, inclusive quando ele reabre o link depois de pagar

O que mudou:

• Assinaturas em dia podiam ser marcadas como inadimplentes por uma disputa entre processos. As afetadas voltaram a ativas
• Assinaturas com Pix Automático aderido pelo painel paravam de cobrar depois da adesão, e o cancelamento feito no banco do pagador não chegava
• Ciclo de Pix Automático sem instrução do banco deixou de deixar a assinatura inadimplente
• Com ciclos concorrentes, o ciclo seguinte nascia sem valor e era dado como pago sem cobrança
• O downgrade em assinatura com vários itens reemitia o boleto só pelo valor do item alterado. Agora usa o total da assinatura, não mexe em ciclo com nota emitida e não cancela o boleto anterior
• A retentativa manual cobra na hora, em vez de esperar a data original

Até então, um webhook que falhava no primeiro envio se perdia. Agora a entrega é repetida com intervalos crescentes (1, 3, 7, 15, 31 minutos e assim por diante, até 12 horas entre tentativas) por até 72 horas. Depois disso o evento fica como falho e pode ser reenviado. Se o seu endpoint falha várias vezes seguidas por erro de servidor ou tempo esgotado, as entregas para ele são pausadas por alguns minutos e retomadas sozinhas.

O que mudou:

• Todo envio traz os headers X-Webhook-Id (o mesmo em todas as tentativas), X-Webhook-Event e X-Webhook-Attempt
• Reenvio em lote dos eventos falhos: POST /v1/users/webhooks/{id}/redeliver-failed
• Busca de eventos por chargeId, subscriptionId ou CPF/CNPJ: GET /v1/users/webhooks/events?search=
• Trocar a URL, o secret ou o token do endpoint reenvia os eventos pendentes
• No painel, Webhooks virou item próprio do menu, com as abas Endpoints e Entregas e o reenvio individual ou em lote

Como o mesmo evento pode chegar mais de uma vez, use o X-Webhook-Id para descartar repetições.

POST /v1/charges com paymentMethod: "pix" aceita expirationMinutes, de 1 a 1440. O QR Code deixa de valer no banco quando o prazo acaba, e a resposta traz pix.expiresAt com o horário exato. Sem o campo, o PIX segue com vencimento em data, como antes.

O que mudou:

• expirationMinutes só vale para PIX; boleto e cartão recusam o campo
• Não pode ser enviado junto com expiration
• pix.expiresAt na resposta

Exemplo:

POST /v1/charges
{
  "paymentMethod": "pix",
  "amount": 49.90,
  "expirationMinutes": 15
}

A resposta pública do checkout devolvia o token da Conversions API do Meta de cada conta. Qualquer visitante da página conseguia ler o token e enviar eventos falsos para o pixel. Agora os eventos saem do servidor, e o navegador não recebe mais o token.

O que mudou:

• GET /v1/checkouts/info devolve só configId e pixelId do Meta
• O link do conteúdo comprado (URL e PDF) não é mais devolvido antes do pagamento
• Produto e itens saem só com os campos necessários para a página
• Número e CVV do cartão não aparecem mais em logs
• Páginas do painel com endereço parecido com o das páginas públicas passam a exigir login

Se você usava Meta Ads em links de pagamento publicados, gere um novo token de acesso no Meta e atualize a integração no painel.

A API recusava boleto com dueDate igual ao dia atual, e depois das 21h já considerava o dia seguinte. Agora hoje ou uma data futura são aceitos, pelo dia de Brasília. boletoDueDays também aceita 0. Data passada continua recusada.

Cobrar no cartão uma assinatura inadimplente, escolher quando a troca de vencimento vale e aplicar cupom numa assinatura em andamento exigiam passar pelo painel. Essas operações ganharam rotas próprias.

O que mudou:

• PUT /v1/subscriptions/{id}/payment-method troca o método. No cartão, com cardToken, cobra os ciclos vencidos do mais antigo ao mais novo e para na primeira recusa. dryRun devolve a prévia
• PUT /v1/subscriptions/{id}/due-date recebe applyFrom (CURRENT_CYCLE ou NEXT_CYCLE) e prorata
• POST /v1/subscriptions/{id}/coupons aplica cupom numa assinatura já em andamento
• POST /v1/subscriptions/{id}/discounts dá desconto pontual numa cobrança. No painel, a mesma ação fica no menu de cada fatura, com prévia do valor
• DELETE /v1/subscriptions/{id}/scheduled-cancellation desfaz o cancelamento agendado
• POST /v1/subscriptions/{id}/prorata mostra a pró-rata ou o crédito com o mesmo cálculo da troca real
• A listagem e o detalhe devolvem só os campos usados
• O split de uma assinatura ativa pode ser editado pelo painel

Também mudou o acesso. A leitura aceita subscriptions/read ou subscriptions/write, e qualquer alteração exige subscriptions/write (antes, um token de leitura conseguia alterar). POST /v1/subscriptions passou a ser só do painel: pela integração, a assinatura nasce de POST /v1/charges. Split, arquivar e desarquivar pela integração respondem 403 PANEL_ONLY_ACTION.

Se a sua credencial só tem subscriptions/read e altera assinaturas, inclua subscriptions/write. Se você cria assinaturas por POST /v1/subscriptions com credencial de integração, passe a usar POST /v1/charges.

O extrato do pagador mostrava sempre "Assinatura mensal de plataforma", qualquer que fosse o produto. E o valor da adesão fixava o valor de toda a recorrência, o que impedia cobrar pró-rata, item adicionado ou troca de plano.

O que mudou:

• O extrato mostra o nome configurado no plano (statementDescriptor, até 22 caracteres), ou o nome do produto
• POST /v1/charges/pix-automatico aceita statementDescriptor e recurrencyMinAmount
• Adesões novas feitas pelo checkout, pela sessão ou pela fatura têm valor variável, com mínimo de R$ 4,99
• Adesões já confirmadas não mudam

Trocar de tela no menu recarregava a página inteira, e várias telas consultavam o servidor a cada poucos segundos para descobrir mudanças. Agora o cabeçalho, o saldo e as notificações ficam montados entre as telas, e as mudanças chegam na hora.

O que mudou:

• A navegação pelo menu não recarrega a página
• Saldo, recebíveis, disputas, estornos, aprovação da conta e subcontas atualizam sozinhos

O PDF do boleto ganhou o logo e as cores da conta, o bloco para pagar por PIX, o recibo do pagador e a ficha de compensação, no mesmo layout da página de pagamento.

O painel só deixava trocar por um plano do mesmo produto, e a troca de recorrência cobrava a diferença do período inteiro. Agora a troca aproveita o que já foi pago.

O que mudou:

• Troca por plano de outro produto; produto, configuração fiscal, recorrência e cupom acompanham a troca
• Troca de recorrência (por exemplo, mensal para diário) vale na hora e não cobra nada. Os dias pagos e não usados viram crédito no plano novo, e a próxima cobrança cai no dia seguinte ao último coberto
• Assinatura que ainda não pagou aceita troca, e a primeira cobrança é refeita pelo valor novo
• Boleto já emitido nunca é cancelado: plano mais caro gera um segundo boleto com a diferença, plano mais barato vira crédito no ciclo seguinte
• Item cancelado de propósito não volta a ficar ativo quando uma fatura é paga

Exemplo: um plano mensal de R$ 100,00 recém-pago trocado por um diário de R$ 30,00 gera R$ 100,00 de crédito. O crédito cobre 3 dias, e a próxima cobrança cai em 3 dias, no valor de R$ 20,00.

Quem integra por webhook não recebia nada entre a falha de uma cobrança e o desfecho do ciclo, nem sabia pelo evento quando seria a próxima cobrança. Os eventos de assinatura passam a trazer essas informações.

O que mudou:

• Novo evento payment.retry, enviado a cada nova tentativa no cartão ou no Pix Automático, com o bloco retry (tentativa, total de tentativas, resultado e próxima data). O evento é opcional: marque-o na inscrição do webhook
• Todo evento com subscriptionId traz nextChargeDate, a data da próxima cobrança. Vem null nos eventos de criação e de trial, em assinatura encerrada e com cancelamento agendado
• subscription.upgraded e subscription.item_added trazem o chargeId quando houve cobrança
• O cartão aprovado em pró-rata e em cobrança avulsa dispara payment.success na hora, com type indicando a origem (PRORATA_UPGRADE, PRORATA_ADD_ITEM, ONE_TIME_ITEM ou ONE_OFF)

Exemplo de payment.retry:

{
  "event": "payment.retry",
  "subscriptionId": "sub_01abc",
  "status": "DEFAULT",
  "cycleNumber": 3,
  "chargeId": "cha_01abc",
  "amount": 99.90,
  "nextChargeDate": "2026-10-10T14:45:05.953Z",
  "retry": {
    "attempt": 2,
    "maxAttempts": 13,
    "paymentMethod": "CREDIT_CARD",
    "status": "FAILED",
    "nextRetryAt": "2026-09-21T13:00:00.000Z",
    "failureReason": "Saldo insuficiente"
  }
}

No painel, a autenticação 3DS deixou de ser uma configuração da conta. Ela é marcada na criação de cada link de pagamento, cobrança avulsa e assinatura com cartão, e as páginas de pagamento da ValidaPay seguem essa escolha. O campo threeDsRequired é gravado e devolvido pela API, desligado por padrão.

O que mudou:

• Novo campo threeDsRequired em links, cobranças avulsas e assinaturas
• O toggle de 3DS da tela Minha Conta saiu
• Links antigos e cobranças criadas pela API abrem sem 3DS no checkout da ValidaPay

Quem integra pela API e envia o resultado da autenticação na cobrança continua com o 3DS aplicado, sem mudança. Renovações automáticas de assinatura não passam por 3DS, porque não há comprador presente.

O que mudou:

• Municípios com chave digital, sem login, perdiam a credencial, a série e o número do RPS ao salvar
• Editar qualquer campo da configuração apagava a senha da prefeitura. A senha agora é mantida
• A série da DPS pode ser informada no padrão nacional, e a numeração do RPS não depende mais da credencial
• A emissão municipal em Campinas funciona
• Reenvio, cancelamento e reemissão de nota das taxas respondiam NOTA_NOT_FOUND para qualquer nota
• Nota avulsa emitida com referência livre ficava em processamento para sempre
• O município do CEP passa a ser preenchido na configuração

Na etapa da chave de Saques e de Transferências PIX, aparecem até 3 destinatários recentes. Um clique preenche a chave, sem precisar digitar de novo.

POST /v1/charges ignorava o X-Sub-Account. Boleto e cartão nasciam na conta master, o saldo era creditado nela e o payment.success saía sem subAccountId. Agora a cobrança nasce na subconta, o saldo vai para ela, e charge.created e payment.success são espelhados na master com subAccountId. POST /v1/charges/pix já funcionava.

Enviar X-Sub-Account junto com items ou productId responde 400 SUBACCOUNT_WITH_CATALOG_NOT_SUPPORTED. A cobrança por valor (amount) funciona normalmente.

Quem monta o próprio checkout passa a coletar a identificação do dispositivo e autenticar o cartão no 3DS pelo navegador, com rotas públicas identificadas pelo publicId da conta. A tokenização devolve um cardToken (ctk_...) que vale por 5 minutos e é usado no lugar do paymentMethodId. Em sandbox, a sessão devolve fingerprint e 3DS como em produção, e a cobrança continua simulada.

O que mudou:

• POST /v1/payment-sessions abre a sessão de fingerprint e 3DS
• POST /v1/payment-sessions/payment-methods tokeniza o cartão
• cardToken é aceito em /v1/charges, /v1/charges/single, captura, pagamento do checkout e troca de método da assinatura e da fatura
• As cobranças aceitam deviceId e authentication com o resultado do 3DS
• Novos erros: CARD_TOKEN_NOT_FOUND (404), CARD_TOKEN_EXPIRED (400) e PAYMENT_METHOD_CONFLICT (400)

A tokenização passa a devolver o cardToken. O paymentMethodId só continua vindo para as contas que já o usavam. Nas integrações novas, envie o cardToken na cobrança em até 5 minutos.

Para o cliente informar o cartão depois, era preciso criar um link separado e mandar por fora. Agora a assinatura de cartão criada sem os dados do cartão fica pendente e devolve o link de pagamento.

O que mudou:

• A resposta traz checkoutUrl para o cliente informar o cartão
• O cliente recebe o e-mail de pagamento pendente com o link. O mesmo vale para cobrança avulsa de cartão criada sem cartão
• Novos eventos de notificação recurrence.card.pending e oneoff.card.pending, configuráveis no produto e na cobrança avulsa
• O aviso de cobrança pendente para o vendedor (seller.charge.pending) passou a ser opcional e só é enviado se estiver marcado
• O reenvio de aviso pelo painel funciona para cobranças de cartão em aberto

Cobrança avulsa com passFeesToCustomer: true era cobrada pelo valor de tabela, e a taxa saía do vendedor. Agora o repasse é aplicado. O cálculo também deixou de arredondar um centavo a mais, então o valor final cai 1 centavo em parte dos casos, e o comprador vê exatamente o que será cobrado.

Exemplo: R$ 100,00 em 6x, com taxa de 8,29% + R$ 0,12, era cobrado R$ 109,18 e passa a R$ 109,17, valor que já libera os R$ 100,00 ao vendedor.

Consultar o detalhe inteiro da cobrança só para saber se ela foi paga era caro e trazia dados que a integração não usa. As consultas ganharam formatos para cada uso.

O que mudou:

• GET /v1/charges/{chargeId}/status devolve status, valor, meio de pagamento, código PIX e datas, para acompanhar o pagamento sem carregar o detalhe
• GET /v1/charges/{chargeId} com credencial de integração devolve um contrato próprio: valores e taxa, cliente com endereço, pagador, assinatura, plano, nota fiscal e instruções de PIX e boleto
• POST /v1/charges devolve subscriptionId quando a cobrança cria uma assinatura
• A listagem e o detalhe devolvem só os campos do contrato, sem os campos internos que vinham junto

GET /v1/charges deixou de calcular o total por padrão: pagination.total e pagination.totalPages vêm null. A paginação por limit, lastKey e hasMore não muda. Se você usa o total, envie includeTotal=true.

Em Minha Conta, "Encerrar conta" mostra o que impede o encerramento: saldo, recebíveis a receber, chaves PIX, cobranças em aberto e assinaturas ativas, cada item com o caminho para resolver. Com tudo resolvido, o encerramento pede o motivo e uma confirmação. A conta encerrada tem links de pagamento, sessões e credenciais de API desativados e não recebe mais pagamentos.

O extrato lançava só o líquido do PIX recebido direto na chave, e um PIX menor que a taxa fixa sumia do extrato. Agora o valor bruto e a taxa aparecem em linhas separadas. Sem saldo para a taxa, o PIX é creditado e a taxa fica como pendência, sem deixar o saldo negativo.

As rotas de cobrança devolviam o PIX em sete formatos diferentes. Agora todo bloco pix tem emv (copia e cola) e qrCode (imagem PNG em base64), e o bloco boleto traz o PIX do boleto junto da linha digitável, com pdfUrl sempre preenchida. Vale para criação, captura, detalhe, status, GET /v1/checkouts/info/{id} e o webhook charge.created. A listagem fica de fora.

O que mudou:

• pix.emv e pix.qrCode em todas essas rotas
• boleto.emv e boleto.qrCode com o PIX do boleto
• O charge.created de boleto só é enviado quando o banco registra o boleto, já com linha digitável e código de barras, e pode chegar alguns segundos depois da criação
• Boletos que ficavam sem linha digitável na fatura e na troca de método passam a tê-la

No POST /v1/charges, o código PIX do boleto saiu de boleto.pix.emv para boleto.emv. Atualize a leitura desse campo.

Exemplo de recorte do boleto:

"boleto": {
  "digitableLine": "34197500091234567891123456789017115760000004500",
  "barCode": "34191157600000045007500012345678912345678901",
  "dueDate": "2026-09-21",
  "pdfUrl": "https://api.validapay.com.br/v1/charges/cha_01abc/boleto.pdf",
  "emv": "00020126580014br.gov.bcb.pix...",
  "qrCode": "data:image/png;base64,iVBORw0KGgo..."
}

As rotas de cobrança, incluindo as de PIX legadas, aceitam charges/read para leitura e charges/write para criação. Credenciais novas criadas no painel usam esses scopes. O pix.cob continua válido, e as credenciais existentes seguem funcionando sem mudança.

O que mudou:

• card_declined e suspeita de fraude têm mensagem própria, no lugar de "Erro no pagamento"
• O 402 de cartão recusado em POST /v1/charges volta a trazer o chargeId
• Credenciais de sandbox deixaram de receber 404 "Conta não encontrada" em POST /v1/charges/pix e nas rotas de métodos de pagamento

Quando um caso de MED era encerrado a favor do recebedor, o valor bloqueado continuava travado no saldo. Agora o encerramento libera o valor, e bloqueios que o banco já tinha desfeito deixam de aparecer como bloqueados.

O novo tipo de cupom EXTRA_PERIOD adia a próxima cobrança da assinatura em vez de descontar valor. Um cupom de 1 mês numa assinatura trimestral faz a segunda cobrança cair 4 meses depois da primeira. O adiamento se repete nos primeiros maxCycles ciclos, ou em todos se maxCycles ficar vazio, e nenhuma cobrança é gerada no período pulado.

O que mudou:

• discountType: "EXTRA_PERIOD", com a quantidade em discountValue e a unidade em extraPeriodUnit (DAYS ou MONTHS)
• Vale só para recorrência
• O código do cupom passa a ser único por conta, e o mesmo código em contas diferentes não se mistura

Exemplo:

POST /v1/coupons
{
  "code": "1MESGRATIS",
  "discountType": "EXTRA_PERIOD",
  "discountValue": 1,
  "extraPeriodUnit": "MONTHS",
  "appliesTo": "RECURRING",
  "maxCycles": 1
}

O repasse de taxa (passFeesToCustomer) valia só para a primeira cobrança parcelada do checkout. Agora ele é gravado na assinatura e aplicado em todas as renovações, em qualquer intervalo, inclusive à vista.

O que mudou:

• O repasse acompanha a assinatura em todos os ciclos
• O checkout oferece o repasse também no pagamento à vista, com a simulação do valor final
• O repasse pode ser ligado e desligado depois, nas configurações da assinatura
• O cálculo usa a tabela e a taxa fixa da própria conta

Quando a emissão automática falhava ou a configuração fiscal era feita depois, a única saída era a nota avulsa, que sai sem vínculo com a assinatura nem com o cliente. Agora a nota pode ser emitida pelo painel em cada ciclo ou cobrança, já vinculada.

O que mudou:

• Só cobranças pendentes ou pagas podem ter a nota emitida
• A nota mensal das taxas da ValidaPay chega por e-mail, com PDF e XML

Logo depois da entrada da expiração, boletos e PIX com vencimento emitidos com antecedência expiravam 24 horas após a criação, dias antes de vencer. Agora o prazo conta a partir do vencimento.

Cobranças de PIX e boleto ficavam abertas para sempre. Agora cada uma nasce com a data de expiração (expiresAt), a mesma enviada ao banco, e passa a EXPIRED quando o prazo acaba. A fatura pública mostra "Pague até" e, depois do prazo, a tela de cobrança expirada no lugar da opção de pagar.

O que mudou:

• PIX com vencimento e boleto expiram no fim do dia do prazo após o vencimento (expirationAfterDueDate, ou 30 dias se não houver)
• PIX imediato e adesão de Pix Automático expiram em 24 horas
• Cartão não expira
• Novos eventos charge.expired e subscription.expired
• Sessão de checkout não paga expira em 30 dias

Itens adicionados a uma assinatura (upgrade, adicional ou avulso) cuja cobrança expira sem pagamento passam a ser cancelados. Se a sua operação depende desses itens, acompanhe o charge.expired.

Um mesmo dia pode misturar recebíveis de prazos diferentes. O calendário passa a mostrar quanto de cada dia vem de cada prazo.

O que mudou:

• No painel, cada dia mostra os selos D+1 e D+30
• Recebíveis anteriores à mudança vêm com os campos zerados ou null

Ao criar uma cobrança avulsa de PIX, boleto ou cartão, o pagador recebe o e-mail com o link de pagamento se tiver contato cadastrado, no mesmo padrão das assinaturas. Antes era preciso montar um link de checkout e mandar por fora.

O que mudou:

• A criação de cobrança avulsa envia e-mail quando o cliente tem e-mail
• Cópias (CC) já configuradas na conta também valem nesse fluxo

Exemplo de criação de PIX avulso com cliente:

POST /v1/charges/pix
{
  "amount": 49.90,
  "customer": { "name": "Ana Silva", "email": "ana@email.com", "document": "12345678909" }
}

O prazo de cartão (D+N) é contado em dias corridos. Se a data cair no sábado ou no domingo, o item continua nesse dia no calendário e não é mais empurrado para a segunda, como acontecia antes. O que muda é o reconhecimento. Enquanto for fim de semana o valor fica como a receber, e o recebimento é dado como concluído no próximo dia útil. Feriados não entram nessa regra.

O que mudou:

• A data prevista aceita sábado e domingo
• No fim de semana o recebível fica pendente e o crédito é reconhecido na segunda
• Feriados não alteram a data nem o reconhecimento

A data do calendário não é mais adiada para o dia útil seguinte. Quem conciliava esperando só dias úteis precisa considerar sábado e domingo.

Assinaturas com o ciclo já quitado apareciam como atrasadas, o que disparava cobrança e aviso indevidos. A marcação de inadimplência confere o pagamento do ciclo antes.

A recorrência era aberta no dia em que a cobrança foi criada, e não no vencimento combinado, então o pagador via a data errada. A cobrança segue o vencimento do ciclo da assinatura.

O cliente não é apagado de vez. Ele fica oculto nas telas e nas listagens, e o documento e o e-mail dele podem ser cadastrados de novo. O histórico de cobranças continua no lugar. Se ainda houver assinatura em aberto, a exclusão é recusada, para o cliente não sumir com uma recorrência viva.

O que mudou:

• A exclusão oculta o cliente das listagens
• Assinatura em aberto bloqueia a operação

Se ainda existir assinatura ativa, a API responde 400. Cancele as assinaturas antes de excluir.

Exemplo de erro com assinatura aberta:

{
  "message": "Cliente possui 1 assinatura(s) em aberto. Cancele antes de excluir.",
  "code": "CUSTOMER_HAS_ACTIVE_SUBSCRIPTIONS"
}

A automação de cobrança por WhatsApp ganhou duas proteções. O vendedor consegue disparar um aviso na hora, sem esperar o próximo horário programado. A régua também deixou de mandar boleto de valor abaixo do mínimo aceito pela instituição, mensagem que chegava ao cliente com um boleto impossível de pagar.

O que mudou:

• É possível avisar uma cobrança pendente na hora
• Mensagem de boleto não sai abaixo do valor mínimo da instituição

Em alguns fluxos a taxa de saída de PIX (R$ 0,47 por padrão) deixava de ser cobrada, e a conta recebia o valor cheio. A taxa voltou a ser deduzida assim que o saque ou a transferência é confirmado, com o desconto no extrato junto da operação.

O que mudou:

• A taxa configurada na conta é cobrada no saque e na transferência
• O lançamento entra no extrato após a confirmação

O pagador que tinha o cartão recusado ainda no checkout conseguia trocar de cartão e concluir a compra, mas ficava uma cobrança automática agendada para o dia seguinte, e o cliente era cobrado duas vezes. A recusa dentro do checkout não gera mais essa retentativa.

Em alguns fluxos a resposta vinha sem o código do QR Code, e o pagador ficava sem como pagar. Toda cobrança PIX agora devolve o código para escanear ou colar no aplicativo do banco. Na mesma correção, o PIX Automático em conta de testes deixou de tocar em dinheiro de verdade.

O que mudou:

• A resposta da cobrança PIX traz o código copia e cola
• No ambiente de testes, taxa e divisão de valores ficam só no extrato local

Exemplo de recorte da resposta:

{
  "chargeId": "cha_01abc",
  "pix": { "qrCode": "00020126...BR.GOV.BCB.PIX..." }
}

Emitir, consultar, cancelar e reemitir nota seguem o mesmo caminho, e não mais um caminho por operação. A prefeitura é escolhida pela cidade da configuração da conta, e o relatório mostra número, série e situação de todas as notas na mesma lista.

O que mudou:

• Listar e emitir nota
• Consultar, cancelar e reemitir
• Relatório com número, série e status

Quando o pagamento do upgrade era recusado, a retentativa cobrava o valor do plano antigo e a assinatura ficava no plano errado mesmo depois de pagar.

Quem tivesse o código de uma cobrança de outra conta conseguia saber que ela existia pela resposta da API. A resposta virou idêntica à de um código inexistente, tanto na consulta quanto no cancelamento, no reenvio de aviso e no boleto. Nada muda para quem acessa as próprias cobranças.

Rotas de detalhe, cancelamento, aviso e boleto da cobrança.

A resposta é 404, igual a uma cobrança que não existe.

{
  "message": "Cobranca nao encontrada",
  "code": "CHARGE_NOT_FOUND"
}

Um item cobrado à parte dentro da assinatura fazia a recorrência achar que o ciclo tinha virado, antecipando a próxima fatura. Também foram corrigidos o arredondamento em duas casas e o vencimento do ajuste proporcional avulso, que caía no ciclo seguinte.

Contas PJ criam a assinatura já com a adesão ao PIX Automático, sem passar por um cadastro separado. O pagador autoriza a recorrência uma vez, pelo QR Code que fica na cobrança de adesão, e as cobranças seguintes são debitadas sozinhas. O valor mínimo de adesão é R$ 4,99 (contas internas são isentas), e o cancelamento encerra a recorrência no fim do período já pago.

O que mudou:

• Criação de assinatura aceita PIX Automático
• Valor mínimo de adesão de R$ 4,99
• O QR Code de autorização fica na cobrança de adesão
• O cancelamento vale a partir do fim do período atual

Exemplo:

POST /v1/subscriptions
{
  "customerId": "cus_01abc",
  "priceId": "price_01xyz",
  "paymentType": "pix_automatico"
}

Cobranças de ajuste proporcional, avulsas dentro da assinatura e de cartão na fatura às vezes nasciam sem a taxa registrada. O vendedor via um valor a receber maior do que o real e o extrato não fechava. Todos esses fluxos gravam o valor bruto, a taxa e o valor líquido.

O que mudou:

• A cobrança passa a trazer valor bruto, taxa e valor líquido

O pagador que estava no cartão ou no boleto muda para PIX Automático sem cancelar e recriar a assinatura, inclusive quando ela está atrasada, o que ajuda a recuperar a recorrência. A troca para PIX Automático inicia a adesão, e o detalhe da assinatura guarda o histórico de trocas. O vendedor também consegue limitar quais meios o pagador enxerga na fatura.

O que mudou:

• Troca de meio com a assinatura ativa ou inadimplente
• Destino PIX Automático inicia a adesão
• Histórico de trocas no detalhe da assinatura
• Meios permitidos na fatura são configuráveis

Até então o desconto de quem pagava adiantado era um só, herdado da configuração de boleto, e quem quisesse premiar o PIX acabava mexendo no boleto junto. Cada meio tem o seu desconto. Juros e multa continuam existindo só no boleto.

O que mudou:

• PIX tem desconto próprio
• Boleto mantém juros, multa e o desconto dele

Quem abre subcontas não precisa mais configurar as taxas uma a uma. PIX, boleto, cartão, nota fiscal e taxa de saque vêm da conta principal no momento da abertura. Se a principal não tiver alguma dessas taxas definida, vale o padrão da plataforma (PIX R$ 0,67).

O que mudou:

• Taxas herdadas da conta principal
• Taxa de abertura de subconta de R$ 15 por padrão

O ciclo com fatura vencida gerava uma segunda fatura, e o pagador ficava com duas cobranças do mesmo período em aberto.

Quem tinha em mãos o código de uma cobrança ou de uma assinatura precisava procurar pelo nome do cliente. O mesmo campo de busca aceita os dois códigos, o que resolve conciliação e atendimento. Os filtros de produto, preço, status, período e meio de pagamento continuam funcionando junto.

O que mudou:

• A busca também acha cobrança e assinatura pelo código
• Filtros de produto, preço, status e período seguem disponíveis

Exemplo:

GET /v1/charges?search=cha_01abc&limit=15

GET /v1/charges?search=sub_01xyz&limit=15

Quem tem uma chave PIX em outra instituição consegue pedir a portabilidade para a ValidaPay. Quem já tem a chave aqui aprova ou recusa o pedido de saída, e o andamento fica visível enquanto o pedido corre.

O que mudou:

• Solicitar portabilidade
• Listar e consultar o pedido
• Confirmar (somente quem é o dono atual da chave) ou cancelar

Só o dono atual da chave confirma a portabilidade. Qualquer outra conta tem a confirmação recusada.

Exemplo de solicitação:

POST /v1/wallet/pix-claims
{
  "pixKey": "ana@email.com",
  "pixKeyType": "EMAIL"
}

A atualização de cliente aceitava trocar o documento, o que transformava o cadastro em outra pessoa e bagunçava o histórico de cobranças. Só nome, e-mail, telefone e endereço podem mudar. Os demais campos são ignorados, e um documento diferente do cadastrado é recusado.

O que mudou:

• Campos permitidos de nome, e-mail, telefone e endereço
• CPF/CNPJ permanece o do cadastro

Ajustes que antes exigiam cancelar e criar de novo são feitos na própria assinatura. Mudar o dia de vencimento gera o ajuste proporcional do período e fica registrado no histórico. O cancelamento agendado aparece na listagem até a data chegar.

O que mudou:

• Novo dia de vencimento com ajuste proporcional
• E-mails em cópia nas notificações
• Cancelamento para o fim do período, com aviso por webhook

A cobrança antecipada fecha o ciclo antes do vencimento, e clicar duas vezes não gera duas cobranças. A cobrança diária, para quem trabalha com recorrência de curto prazo, depende de liberação na conta. O ciclo também mostra a taxa e o valor líquido previstos, então o vendedor sabe quanto vai receber antes do pagamento.

O que mudou:

• Cobrança antecipada com um clique e uma cobrança
• Cobrança diária exige permissão na conta
• Ciclo passa a mostrar taxa e valor líquido previstos

O rateio por percentual arredondava errado e podia deixar sobra ou falta de centavos. Os destinatários também deixaram de ser identificados pelo número interno da conta e passaram a usar o código público. Por fim, a divisão saiu do limite da cobrança avulsa, e cada cobrança de assinatura é rateada do mesmo jeito.

O que mudou:

• Destinatário identificado pelo código público da conta
• Divisão também nas cobranças de assinatura

Quando havia mais de um ciclo em aberto, a retentativa podia quitar o período errado, e o mês pago continuava aparecendo em atraso.

Quando um PIX recebido é bloqueado por suspeita de fraude, o valor deixa de entrar no saldo disponível e aparece como saldo retido, com uma linha própria no extrato. Antes o dinheiro simplesmente não aparecia e o vendedor não sabia o motivo. Quando o bloqueio cai, o crédito liberado, ou a devolução ao pagador, entra como um lançamento à parte, e o registro do bloqueio continua no histórico.

• Saldo retido enquanto o bloqueio estiver ativo
• O extrato mostra a retenção e, depois, a liberação

Quem migra de outro sistema sobe a base por planilha, sem cadastrar um a um. A planilha de clientes aceita endereço completo e valida o CEP mesmo quando o logradouro não vem preenchido. As assinaturas importadas entram já com o dia de vencimento certo e com o ajuste proporcional calculado.

• Clientes com nome, documento, e-mail, endereço e CEP
• Assinaturas com vencimento e pró-rata corretos na carga

O vendedor encerra uma disputa, corrige a defesa enviada e acompanha quanto tempo falta para o prazo acabar, com alerta quando ele está perto do fim. As evidências mostram quem é o cliente e quem contestou, o que evita defender a transação errada.

Testes com rateio e cobrança de taxa chegavam a movimentar a conta real. Tudo fica registrado só no extrato do ambiente de testes.

Quem integra pelo webhook distingue o cancelamento agendado do cancelamento imediato e reage na hora, mantendo o acesso do cliente até a data, por exemplo. O evento chega no mesmo formato dos demais avisos de assinatura.

A assinatura que passa do vencimento sem pagamento aparece como inadimplente, e não mais como simplesmente ativa. O vendedor encerra na hora quando nada foi pago ou a vigência acabou, ou agenda o encerramento para o fim do período já pago. Nesse segundo caso o integrador recebe um aviso por webhook. Cada pagamento também registra a data em que o ciclo foi quitado.

• Status de inadimplência na assinatura
• Aviso de cancelamento agendado
• Data do último pagamento do ciclo

Atende o caso em que o cliente perdeu a mensagem ou pediu o link de novo. O reenvio sai na hora, sem esperar o próximo horário da régua.

Quem estava integrando não conseguia testar o checkout com as credenciais da aplicação, porque a chamada era recusada mesmo com as credenciais certas. O token precisa ir no cabeçalho de autorização e ter o escopo da rota.

Recursos que não valem para todo cliente dependem de liberação na conta. Transferência PIX, automação de cobrança por WhatsApp e cobrança diária só aparecem para quem tem a permissão ativa.

Toda saída de dinheiro por PIX tem uma taxa fixa, de R$ 0,47 por padrão e ajustável por conta. Ela é descontada depois que a operação é confirmada e aparece no extrato junto com ela. A conta também nasce com um limite diário de transferência, de R$ 3.000 por padrão.

• Taxa padrão de saída de R$ 0,47
• Limite diário de transferência de R$ 3.000

A troca para um plano mais barato no boleto não era aplicada e o cliente seguia sendo cobrado pelo plano antigo. Na mesma correção, o item cobrado à parte voltou a ser listado na fatura da assinatura.

Contas com mais de uma adquirente de cartão viam sempre a que está marcada como padrão, ainda que o pagamento tivesse passado por outra. Isso atrapalhava a conciliação e a análise de recusas. A cobrança registra a adquirente que de fato processou.

A régua deixou de mandar tudo no mesmo horário. O aviso antes do vencimento, o do dia e o da cobrança em atraso saem em momentos diferentes. O pagador também recebe a confirmação do pagamento pelo próprio WhatsApp, sem precisar procurar o comprovante.

Procurar por "ana silva" não achava o cliente cadastrado como "Ana Silva".

Assinaturas antigas ou encerradas saem da lista do dia a dia sem serem apagadas. Ciclos, cobranças e avisos já emitidos continuam disponíveis para consulta e conciliação.

Os relatórios eram gerados como texto separado por ponto e vírgula, mas com nome de arquivo de Excel. Abrir dava aviso de arquivo corrompido e as colunas saíam embaralhadas. O arquivo agora é uma planilha real.

Útil para quem já tem o CNPJ do cliente no próprio cadastro e não guardou o número da conta na ValidaPay.

• GET /v1/accounts/cnpj/{cnpj}

Se a resposta se perde ou o cliente clica duas vezes, repetir a chamada com a mesma chave de idempotência devolve a cobrança já criada, em vez de gerar outra e cobrar o cliente em dobro.

• Cabeçalho Idempotency-Key

A emissão deixou de ser exclusiva das assinaturas. A nota sai assim que o pagamento é confirmado ou em um horário programado.

O fluxo inteiro pode ser percorrido antes de colocar a integração no ar, da criação da cobrança à simulação do pagamento e à conferência do saldo, sem dinheiro de verdade envolvido.

Sem esses dados, quem integra precisava fazer uma segunda consulta só para montar comprovante e conciliação.

A cobrança de ajuste proporcional nascia sem a taxa registrada, e o valor a receber ficava maior do que o real.

Atende casos em que quem paga não é quem recebe o serviço, como o financeiro da empresa em cópia. O e-mail informado no checkout tem prioridade sobre os demais.

Quando o cliente troca de plano no meio do período, a diferença é somada à próxima fatura, sem virar uma cobrança extra imediata. Evita mandar duas cobranças no mesmo mês.

O cliente digita o cartão uma vez e as próximas compras e renovações usam o cartão guardado, sem os dados passarem de novo pelo lojista. Junto veio uma melhora no atendimento. Quando o pagamento é recusado, a API devolve o motivo informado pela adquirente, e não uma mensagem genérica.

Quem tem a própria tela de pagamento não precisa mandar o cliente para o checkout da ValidaPay. A cobrança feita assim tem o mesmo tratamento, com taxa igual, análise de fraude e o mesmo nome na fatura do cartão.

Algumas rotas exigiam um usuário logado, o que travava integrações que rodam sem ninguém na frente da tela.

Uma padronização anterior deixou algumas rotas fora do ar e integrações pararam de funcionar. Elas foram restauradas. Na mesma revisão, a criação de sessão de checkout passou a exigir autenticação, que antes ficava aberta.

Boletos saíam com vencimento e valor diferentes dos enviados na criação da cobrança.

Quando o pagador corrigia algum dado na tela, o desconto aplicado sumia e ele pagava o valor cheio.

O valor estornado aparece no calendário e é descontado do que o vendedor tem a receber, então a previsão de recebimento fica correta. O estorno passa pela mesma adquirente que processou a cobrança original.

Chegou a alternativa ao cartão para recorrência. O pagador autoriza uma vez, pelo QR Code, e as parcelas seguintes são debitadas na conta dele sem nova ação. As cobranças respeitam a data de início combinada e, se uma falhar, o sistema tenta de novo dentro do intervalo permitido antes de dar o ciclo por perdido.

• QR Code de autorização
• Cobranças no vencimento combinado
• Novas tentativas automáticas

O vendedor vê as contestações abertas contra ele e responde com documentos e comprovantes pelo próprio produto, sem depender do suporte. Reembolsos também geram aviso para quem integra por webhook.

O número do pedido ou do contrato viaja junto da cobrança e volta no extrato, o que permite bater o recebimento com o registro interno sem depender de valor e data.

O extrato mostrava movimentações que não aconteceram, e o saldo exibido não batia com o real.

O aviso de cobrança começou a sair pelo WhatsApp, canal com mais leitura que o e-mail. O boleto enviado vence no próprio dia e continua pagável por até 30 dias.

Antes cada meio tinha o seu caminho e o seu formato. A criação virou uma só, mudando apenas o meio de pagamento, o que simplifica a integração de quem oferece as três opções.

Facilita acompanhar o desempenho de um produto específico ou de uma faixa de preço sem exportar tudo.

O cartão pode ser direcionado para a adquirente com a melhor condição, e a subconta tem a opção de simplesmente seguir a escolha da conta principal.

Pagamentos do fim do dia apareciam no dia seguinte e o fechamento diário não fechava.

Recusas chegavam como códigos sem explicação, que o vendedor não sabia repassar ao cliente.

Sem taxa configurada, a criação de cobrança no ambiente de testes falhava e travava a integração logo no começo.

O vendedor vê o que ainda vai cair na conta e o que já entrou, separado por cobrança avulsa e assinatura, sem depender só do saldo do dia.

O checkout carrega informações do sistema do vendedor junto da compra, oferece um item adicional no momento do pagamento e mantém logo e cores configurados no produto para todos os preços, sem repetir a configuração em cada um.

Antes a assinatura dependia de alguém logado no produto, o que impedia automatizar a venda pelo sistema do próprio cliente.

A conta envia PIX para uma chave informada. Consultar a chave antes só mostra os dados do destinatário para conferência, sem mandar centavos de teste como acontecia.

O vendedor define a penalidade por atraso e o desconto para quem paga adiantado, e o boleto já sai com essas regras. Na época o PIX ainda seguia a mesma configuração. Em agosto ele ganhou um desconto próprio.

Cobrança enviada por engano ou pedido desistido deixavam o cliente com um boleto válido em mãos. Com o cancelamento, o pagamento não é mais aceito.

O extrato trazia lançamentos fora do período e de tipos não selecionados.

Cupons com valor ou percentual de desconto podem ser criados, acompanhados pelo uso e aplicados tanto no checkout quanto em uma cobrança criada pela integração.

O pagador escolhe pagar por PIX ou por boleto no mesmo documento, e quem integra recebe o arquivo pronto para exibir ou enviar.

Pedidos de devolução falhavam porque o recebimento correspondente não era localizado.

Cada período da assinatura ganhou uma fatura, com os itens do plano e a diferença proporcional de mudanças feitas no meio do caminho.

Corrigir e-mail, telefone ou endereço exigia criar outro cadastro, o que duplicava o cliente e dividia o histórico.

Um produto complementar aparece na tela de pagamento e, se o cliente aceitar, entra na mesma cobrança.

Quem já usa o ValidaPix vê os recebimentos da ValidaPay lá, sem exportar e importar arquivo.

Recebimentos feitos fora de uma cobrança, direto na chave PIX da conta, não tinham taxa, o que deixava o custo inconsistente entre os fluxos. Se a conta tiver crédito de isenção, a taxa continua não sendo cobrada até o volume acabar.

O recebimento entrava sem o desconto da taxa, e o valor creditado ficava acima do combinado.

O vendedor define por quantos dias o PIX continua pagável depois do vencimento. Os dados de quem pagou e de quem recebeu ficam registrados na cobrança, o que ajuda na conciliação e em disputas.

O pedido é feito pelo próprio produto e fica registrado para análise, sem depender de contato com o suporte.

Informações como número do pedido ou identificador do carrinho podem ser anexadas à cobrança e voltam na consulta e no aviso de pagamento.

Atende campanhas e negociações comerciais. As cobranças não pagam taxa enquanto o crédito não acaba, e depois voltam à taxa normal.

Primeira entrega do canal. O aviso de cobrança começou a sair pelo WhatsApp além do e-mail.

Ao salvar, só parte das taxas era gravada, e as demais voltavam ao valor anterior sem aviso.

O endereço que recebe os avisos pode exigir credencial, para que só a ValidaPay consiga enviar eventos para ele.

Os filtros eram ignorados e as páginas repetiam registros, o que impedia varrer a lista inteira.

Sem esse evento, o sistema do vendedor não ficava sabendo da devolução e mantinha o pedido como pago.

Permite vender sem ter um plano ou uma cobrança montada antes. Basta enviar o link e definir o valor na hora.

Primeira entrega da emissão e do acompanhamento de notas dentro da ValidaPay.

Quando o valor foi rateado, a devolução também recolhe a parte de cada destinatário, em vez de sair só da conta principal.

Cada lançamento diz quanto foi de taxa e quem estava do outro lado da operação, e a lista pode ser exportada para conferência e contabilidade.

Padronização dos campos de cobrança, que estavam diferentes entre a listagem e o detalhe.

Contas com muitos clientes tinham lentidão e falha ao abrir a lista. Ela agora vem por páginas.

Quem opera com subcontas vê o saldo de cada uma sem trocar de acesso, e o webhook avisa a abertura de uma nova subconta.

Esses valores ficavam fora do rateio, então a conta principal absorvia o custo e os destinatários recebiam a mais.

Vendas avulsas também aceitam parcelamento, e não apenas as recorrentes.

O pagamento confirmava no banco, mas o saldo na ValidaPay não acompanhava, e o dinheiro parecia não ter entrado.

A página de changelog é alimentada por este arquivo e mostra, para cada mudança, a data, o tipo (novidade, melhoria, correção ou segurança) e o que foi afetado.