Skip to main content
O ImperiumPay Gateway oferece duas formas de receber notificações sobre mudanças de status das transações:
  1. Webhook Permanente: Configurado no painel do usuário, recebe notificações de todas as transações
  2. Postback por Transação: URL específica configurada no campo postbackUrl ao criar uma venda

Diferenças entre Webhook e Postback

Webhook Permanente

  • Configurado no painel do usuário
  • Recebe notificações de todas as transações
  • Inclui campos adicionais: fee, transactionId, type
  • Sem assinatura HMAC

Postback por Transação

  • Configurado no campo postbackUrl da venda
  • Recebe notificação apenas da transação específica
  • Inclui externalTransactionId
  • Com assinatura HMAC no header X-Signature

Webhook Permanente

Webhooks permanentes são configurados no painel do usuário e recebem notificações de todas as transações do usuário.

Configuração

Configure seu webhook permanente no painel administrativo do ImperiumPay Gateway. O webhook será chamado sempre que uma transação mudar de status.

Formato da Notificação

O webhook permanente envia um payload com os seguintes campos:

Campos do Webhook Permanente

integer
required
ID da transação (Sale ID)
integer
required
ID do usuário (vendedor)
string
required
Valor da transação em centavos (formato string)
string
required
Data de criação da transação (ISO 8601)
string
required
Status atual da transação. Valores possíveis: PENDENTE, EM_PROCESSAMENTO, PAGO, CANCELADO, RECUSADO, ESTORNADO, FALHA, CHARGEBACK, MED
string
required
Método de pagamento. Valores possíveis: PIX, CREDIT_CARD, DEBIT_CARD, BOLETO
string
Documento do cliente (CPF ou CNPJ)
string
Email do cliente
string
Nome completo do cliente
string
Telefone do cliente (apenas dígitos)
string
Chave PIX gerada (apenas para pagamentos PIX)
string
Código do boleto (apenas para pagamentos via boleto)
string
Informações de entrega em formato JSON string (apenas para produtos físicos). null para produtos digitais.
number
required
Taxa cobrada na transação em centavos. Apenas no webhook permanente.
array
required
Lista de itens da transação
integer
required
ID do item
integer
required
ID da venda (mesmo que id)
string
required
Título do produto
string
required
Preço unitário em centavos (formato string)
integer
required
Quantidade do item
boolean
required
Se o item é físico (true) ou digital (false)
integer
required
ID da transação (mesmo que id). Apenas no webhook permanente.
string
required
Tipo da notificação. Sempre "TRANSACTION" para webhooks de transações. Apenas no webhook permanente.

Postback por Transação

Postbacks são URLs específicas configuradas no campo postbackUrl ao criar uma venda. Recebem notificações apenas daquela transação específica.

Configuração

Configure o postback incluindo o campo postbackUrl ao criar a transação:

Segurança

Postbacks incluem assinatura HMAC-SHA256 no header X-Signature para validação de segurança. A assinatura é gerada usando a chave secreta POSTBACK_SECRET_KEY configurada no ambiente do ImperiumPay Gateway.
Importante: Sempre valide a assinatura HMAC antes de processar a notificação. Isso garante que a requisição realmente veio do ImperiumPay Gateway e não foi alterada durante a transmissão.
Como funciona a assinatura:
  1. O ImperiumPay Gateway gera uma assinatura HMAC-SHA256 do payload JSON usando a chave secreta POSTBACK_SECRET_KEY
  2. A assinatura é enviada no header HTTP X-Signature
  3. Você deve validar a assinatura comparando com a assinatura esperada gerada localmente
Exemplo de requisição com assinatura:
Validação da Assinatura em Node.js:
Validação da Assinatura em Python:
Sobre a chave secreta: A chave POSTBACK_SECRET_KEY é configurada no ambiente do ImperiumPay Gateway. Esta é a mesma chave que você deve usar para validar as assinaturas dos postbacks. Entre em contato com o suporte técnico para obter ou configurar sua chave secreta de postback.Nota importante: O JSON do payload é stringificado sem ordenação de chaves (JSON.stringify padrão). Não use sort_keys=True no Python ou qualquer ordenação de chaves, pois isso resultará em assinaturas diferentes e a validação falhará.

Formato da Notificação

O postback por transação envia um payload com os seguintes campos:

Campos do Postback por Transação

integer
required
ID da transação (Sale ID)
integer
required
ID do usuário (vendedor)
string
required
Valor da transação em centavos (formato string)
string
required
Data de criação da transação (ISO 8601)
string
required
Status atual da transação. Valores possíveis: PENDENTE, EM_PROCESSAMENTO, PAGO, CANCELADO, RECUSADO, ESTORNADO, FALHA, CHARGEBACK, MED
string
required
Método de pagamento. Valores possíveis: PIX, CREDIT_CARD, DEBIT_CARD, BOLETO
string
Documento do cliente (CPF ou CNPJ)
string
Email do cliente
string
Nome completo do cliente
string
Telefone do cliente (apenas dígitos)
string
Chave PIX gerada (apenas para pagamentos PIX)
string
Código do boleto (apenas para pagamentos via boleto)
string
Informações de entrega em formato JSON string (apenas para produtos físicos). null para produtos digitais.
array
required
Lista de itens da transação
string
required
ID da transação no gateway de pagamento externo (adquirente). Apenas no postback por transação.

Comparação dos Formatos

Quando as Notificações São Enviadas

As notificações são enviadas quando a transação muda para um status final:
  • PAGO - Pagamento confirmado
  • CANCELADO - Transação cancelada
  • RECUSADO - Pagamento recusado
  • ESTORNADO - Valor estornado
  • FALHA - Falha no processamento
  • CHARGEBACK - Chargeback identificado (cartão)
  • MED - Mediação PIX iniciada
Nota: Status intermediários como PENDENTE e EM_PROCESSAMENTO não geram notificações.

Exemplo de Implementação

Node.js/Express

Python/Flask

Boas Práticas

Importante:
  • Sempre retorne HTTP 200 para indicar que a notificação foi recebida com sucesso
  • Implemente idempotência para evitar processamento duplicado
  • Sempre valide a assinatura HMAC em postbacks por transação antes de processar
  • Use comparação timing-safe para validar assinaturas (evita timing attacks)
  • Use HTTPS para proteger os dados em trânsito
  • Implemente retry logic no seu servidor caso a notificação falhe
  • Mantenha a chave POSTBACK_SECRET_KEY segura e nunca a exponha em código frontend
Dica: Para testar webhooks localmente, use ferramentas como ngrok ou localtunnel para expor seu servidor local.