Please add hook for merge invoice action, this should support merge invoice from admin side allow to get all the involved invoice IDs so it's will be possible to add note, add invoice line or Everyone can do whatever they want with it. split invoice already have hook, also bulk payment and merge from client area have ClientAreaPageMassPay hook, but merge invoice not, and it's very missing.
Adding my vote and a concrete use case that highlights why this hook is critical.
We integrate WHMCS with payment gateway modules that generate pending payment charges (such as PIX QR codes and bank slips) tied to specific invoice IDs at the moment of creation. These charges are registered both locally in our database and on the payment provider's API.
When two invoices are merged, the secondary invoices are deleted directly from the database — no InvoiceCancelled, no InvoiceChangeGateway, no hook of any kind is fired for them. This leaves any pending charges associated with those invoices orphaned on the payment provider's side: still active and awaiting payment, but with no corresponding invoice in WHMCS anymore.
The consequences are real:
Customers can still pay an orphaned charge and the payment will never be reconciled We cannot automatically cancel those pending charges because we have no hook to intercept the merge The only workaround is to manually track and cancel them, which is error-prone A PreInvoiceMerge + PostInvoiceMerge hook pair — similar to what already exists for InvoiceSplit — would solve this completely. Ideally passing:
The list of all invoice IDs being merged (mergedinvoiceids) The resulting/surviving invoice ID (invoiceid) This is a gap in the hook system that affects any developer building payment integrations on top of WHMCS.
anderson.deda
commented
1 week ago
Adicionando meu voto e um caso de uso concreto que destaca a importância crucial desse recurso.
Integramos o WHMCS com módulos de gateway de pagamento que geram cobranças pendentes (como códigos QR PIX e comprovantes bancários) vinculadas a IDs de faturas específicos no momento da criação. Essas cobranças são registradas tanto localmente em nosso banco de dados quanto na API do provedor de pagamento.
Quando duas faturas são mescladas, as faturas secundárias são excluídas diretamente do banco de dados — nenhum evento InvoiceCancelled, nenhum evento InvoiceChangeGateway, nenhum hook de qualquer tipo é acionado para elas. Isso faz com que quaisquer cobranças pendentes associadas a essas faturas fiquem órfãs no lado do provedor de pagamento: ainda ativas e aguardando pagamento, mas sem nenhuma fatura correspondente no WHMCS.
As consequências são reais:
Os clientes ainda podem pagar uma cobrança órfã e o pagamento nunca será conciliado. Não podemos cancelar automaticamente essas cobranças pendentes porque não temos um mecanismo para interceptar a mesclagem. A única solução alternativa é rastreá-las e cancelá-las manualmente, o que é propenso a erros. Um par de hooks PreInvoiceMerge + PostInvoiceMerge — semelhante ao que já existe para InvoiceSplit — resolveria isso completamente. Idealmente, passando:
A lista de todos os IDs de faturas que estão sendo mescladas (mergedinvoiceids) O ID da fatura resultante/sobrevivente (invoiceid) Essa é uma lacuna no sistema de hooks que afeta qualquer desenvolvedor que crie integrações de pagamento no WHMCS.
2 Comments
Login to post a comment.
We integrate WHMCS with payment gateway modules that generate pending payment charges (such as PIX QR codes and bank slips) tied to specific invoice IDs at the moment of creation. These charges are registered both locally in our database and on the payment provider's API.
When two invoices are merged, the secondary invoices are deleted directly from the database — no InvoiceCancelled, no InvoiceChangeGateway, no hook of any kind is fired for them. This leaves any pending charges associated with those invoices orphaned on the payment provider's side: still active and awaiting payment, but with no corresponding invoice in WHMCS anymore.
The consequences are real:
Customers can still pay an orphaned charge and the payment will never be reconciled
We cannot automatically cancel those pending charges because we have no hook to intercept the merge
The only workaround is to manually track and cancel them, which is error-prone
A PreInvoiceMerge + PostInvoiceMerge hook pair — similar to what already exists for InvoiceSplit — would solve this completely. Ideally passing:
The list of all invoice IDs being merged (mergedinvoiceids)
The resulting/surviving invoice ID (invoiceid)
This is a gap in the hook system that affects any developer building payment integrations on top of WHMCS.
Integramos o WHMCS com módulos de gateway de pagamento que geram cobranças pendentes (como códigos QR PIX e comprovantes bancários) vinculadas a IDs de faturas específicos no momento da criação. Essas cobranças são registradas tanto localmente em nosso banco de dados quanto na API do provedor de pagamento.
Quando duas faturas são mescladas, as faturas secundárias são excluídas diretamente do banco de dados — nenhum evento InvoiceCancelled, nenhum evento InvoiceChangeGateway, nenhum hook de qualquer tipo é acionado para elas. Isso faz com que quaisquer cobranças pendentes associadas a essas faturas fiquem órfãs no lado do provedor de pagamento: ainda ativas e aguardando pagamento, mas sem nenhuma fatura correspondente no WHMCS.
As consequências são reais:
Os clientes ainda podem pagar uma cobrança órfã e o pagamento nunca será conciliado.
Não podemos cancelar automaticamente essas cobranças pendentes porque não temos um mecanismo para interceptar a mesclagem.
A única solução alternativa é rastreá-las e cancelá-las manualmente, o que é propenso a erros.
Um par de hooks PreInvoiceMerge + PostInvoiceMerge — semelhante ao que já existe para InvoiceSplit — resolveria isso completamente. Idealmente, passando:
A lista de todos os IDs de faturas que estão sendo mescladas (mergedinvoiceids)
O ID da fatura resultante/sobrevivente (invoiceid)
Essa é uma lacuna no sistema de hooks que afeta qualquer desenvolvedor que crie integrações de pagamento no WHMCS.