Skip to content

Pedidos

Um Pedido é um registro de compra. No MIDDAG Account, o WooCommerce cuida do comércio — produtos, checkout, pagamentos e assinaturas — enquanto o MIDDAG Account cuida do que acontece após a compra: criar entitlements, rastrear ciclo de vida e conectar tudo à organização do cliente.

Os clientes nunca veem o WooCommerce. O portal do cliente usa sua própria terminologia ("pedidos" e "faturas", não "pedidos WooCommerce") e sua própria interface. O WooCommerce é o motor de backoffice, visível apenas para o time admin.

Como pedidos criam entitlements

Este é o pipeline principal. Quando um cliente conclui uma compra, o MIDDAG Account cria automaticamente os entitlements que dão acesso ao que foi comprado:

Passo a passo:

  1. O pagamento é confirmado — via webhook do Stripe (cartão de crédito), webhook do Banco Inter (Pix ou boleto) ou confirmação manual do admin.
  2. O status do pedido WooCommerce muda para completed — isso dispara o hook padrão do WooCommerce.
  3. O serviço de provisionamento do MIDDAG Account analisa o pedido — lê cada item e verifica o metadado _middag_entitlement_class do produto para determinar qual classe de entitlement criar.
  4. Um entitlement é criado para cada item — com código único, status active e vinculado ao pedido e à organização.
  5. Os recursos derivados são provisionados — uma Licença para itens PLG, um Ambiente para itens ENV, um Serviço e Contrato para itens SVC, e assim por diante.

O pipeline inteiro roda automaticamente. Após o cliente pagar, ele tem seus entitlements e acesso em segundos — sem necessidade de intervenção do admin.

Idempotência

Se um webhook de pagamento dispara duas vezes (o que acontece na prática), o sistema não cria entitlements duplicados. Ele verifica se já existe um entitlement para a mesma combinação de pedido + item + classe e pula a criação se encontrar um.

Ciclo de vida do pedido e ciclo de vida do entitlement

O status do pedido no WooCommerce se mapeia para o comportamento do entitlement:

Status do pedido WooCommerceEfeito no entitlement
CompletedEntitlement criado com status active
ProcessingNenhum entitlement ainda — o pagamento ainda está sendo confirmado
On holdNenhum entitlement ainda — aguardando pagamento manual (boleto)
RefundedEntitlement cancelado (reembolso total) ou permanece ativo (parcial, conforme política)
CancelledEntitlement cancelado
FailedNenhum entitlement criado

Para assinaturas (gerenciadas pelo WooCommerce Subscriptions):

Evento da assinaturaEfeito no entitlement
Renovação pagaEntitlement permanece ativo, data de expiração estendida
Renovação falhouPayment Recovery Policy consultada — pode suspender o entitlement
CanceladaEntitlement move para expirado ou cancelado (conforme política)
UpgradeMesmo entitlement, atributo de plano muda
DowngradeMesmo entitlement, atributo de plano muda (pode requerer aprovação)

O WooCommerce Subscriptions cuida de toda a complexidade da cobrança recorrente: pro-rata, cálculos de upgrade/downgrade e tentativas de pagamento. O adaptador de assinaturas do MIDDAG Account traduz esses eventos em transições de ciclo de vida do entitlement.

Impacto de reembolso e cancelamento

Quando um pedido é reembolsado ou cancelado, o impacto no entitlement depende do tipo:

  • Reembolso total — O entitlement vinculado é cancelado. Os recursos derivados (licenças, ambientes, serviços) são desativados. A Refund Policy controla se isso acontece automaticamente ou requer aprovação do admin.
  • Reembolso parcial — O entitlement permanece ativo por padrão. O admin pode ajustar manualmente o entitlement se o reembolso parcial justificar acesso reduzido.
  • Cancelamento do pedido — O entitlement é cancelado. Se o entitlement já foi provisionado, os recursos derivados são desativados.

A Refund Policy (configurável através da Policy Engine) controla:

  • Quantos dias após a compra um reembolso é permitido
  • Se reembolsos abaixo de um limite são processados automaticamente
  • Se créditos são perdidos, mantidos ou ajustados proporcionalmente
  • Se o entitlement é automaticamente cancelado após um reembolso total

De onde vêm os pedidos

Pedidos no MIDDAG Account podem ser originados de vários caminhos:

OrigemComo funciona
Proposta aceitaCliente aceita uma proposta no portal, pedido WooCommerce é criado automaticamente, link de pagamento é enviado
Compra diretaAdmin cria um pedido no WooCommerce manualmente
Renovação de assinaturaWooCommerce Subscriptions cria um pedido de renovação automaticamente
Negócio do HubSpotUm negócio no HubSpot sincroniza com uma proposta, que converte em pedido

Independente da origem, o pipeline de criação de entitlements funciona da mesma forma.

Roteamento dual-entidade

Todo pedido é roteado para a entidade legal MIDDAG correta — MIDDAG BR (Brasil) ou MIDDAG GLOBAL (LLC nos EUA) — com base na identificação fiscal da organização, configuração de entidade de cobrança, configuração do produto ou moeda. Isso determina qual conta Stripe processa o pagamento e quais regras fiscais se aplicam.

O roteamento é automático, mas pode ser sobrescrito por um admin por transação.

O que os admins veem

No WordPress admin, a visão de pedidos mostra:

  • Número do pedido e data
  • Nome da organização
  • Valor e moeda
  • Status do pagamento
  • Entidade de cobrança (BR ou GLOBAL)
  • Códigos de entitlements vinculados

Admins também têm um dashboard financeiro que agrega dados de ambas as entidades:

  • Receita total por período (mensal, trimestral, anual)
  • Receita por entidade (BR vs GLOBAL)
  • Pagamentos pendentes (boletos não pagos, faturas em aberto)
  • Faturas em atraso
  • Assinaturas ativas vs canceladas

O dashboard financeiro é exclusivo para admins — clientes não têm acesso. Os clientes veem seu próprio histórico de pedidos pelo portal, com a terminologia do MIDDAG Account (nunca rótulos do WooCommerce).

Páginas relacionadas