# Prazos de compra do Launch e limites do SDK de contas

Esta alteração foi desenvolvida e validada apenas localmente; o Launch não foi implantado e os pacotes do SDK não foram publicados. O código-fonte atual depende do protocolo de autorização de contas do Licentivo e das atualizações correspondentes do SDK oficial; ele não pode ser combinado com o servidor antigo que só oferece suporte a chaves de licença de longa duração.

## Responsabilidades

| Capacidade | Responsável |
| --- | --- |
| Cadastro, login, segurança da conta, produtos, pedidos, pagamentos e reembolsos | Launch |
| Cotações de renovação/upgrade e cálculo dos ciclos de compra e dos horários absolutos de início e término | Launch |
| Execução do mapeamento das referências de planos para produtos/políticas de autorização e validação das políticas | Licentivo; o Launch fornece as opções de seleção e registro |
| Licenças, permissões de recursos, cotas de dispositivos, sessões de autorização e concessões offline | Licentivo e SDK oficial |
| Lista de dispositivos e desvinculação remota | Licentivo; o Launch encaminha as solicitações da conta atual e exibe os resultados |
| Armazenamento das credenciais de login, restauração da conta e opção de logout | SDK do Launch |

Os pedidos, os prazos de compra e os indicadores de conclusão da sincronização do Launch não podem liberar recursos protegidos. O cliente deve executar as operações protegidas por meio das interfaces de execução do SDK oficial, como `RunFeature`.

Cada produto do Launch mantém uma rota pública estável para um produto do Licentivo. Os planos do mesmo produto podem selecionar políticas diferentes, mas não podem mudar para outro produto remoto; o salvamento dos mapeamentos é validado em série por meio do bloqueio da linha do produto compartilhado no banco de dados. A identidade do cliente, a publicação dos planos e a configuração de integração do SDK leem o mesmo vínculo; os rascunhos não podem alterar o contexto do produto dos clientes que já compraram. Isso valida apenas a consistência da configuração de integração e não determina a autorização de recursos ou dispositivos. Quando o banco de dados antigo não tem os campos estáveis, o histórico de compras e publicações tem prioridade; se não for possível confirmar um único vínculo, será retornado `PRODUCT_MAPPING_CONFLICT`. Consulte [Correção da concorrência nos mapeamentos](/pt/launch-documents/product-mapping-fix-2026-10-24/).

## Sincronização dos prazos de compra

Reutilize as interfaces existentes, sem adicionar interfaces de fatos de pagamento, fatos de reembolso ou serviços de cotação:

- `POST /api/v1/launch/connections`, `PUT /connections/{id}`: registrar as chaves públicas de assinatura de identidade, criando conexões separadas para os ambientes de produção e teste.
- `PUT /api/v1/launch/connections/{id}/plans/{plan}`: registrar referências únicas de versões de planos do Launch, bem como o produto remoto e a versão da política.
- `POST /api/v1/launch/connections/{id}/events`: enviar um instantâneo completo e versionado da compra.
- `GET /api/v1/launch/connections/{id}/events/{event}`: confirmar o resultado do processamento.
- `POST /api/v1/launch/connections/{id}/events/{event}/retry`: conferir e repetir o evento original.

O instantâneo contém apenas o número do evento, o ambiente, o tipo de evento, a referência da compra, a referência anônima da conta, o produto do Launch, a referência da versão do plano, uma versão crescente e os valores absolutos de `valid_from` / `valid_until`; na migração, inclui o ID da licença antiga. Não são enviadas chaves de pagamento, preços, e-mails de clientes nem chaves de licença de longa duração. Para compras permanentes, `valid_until` é `null`, e o Licentivo verifica se isso corresponde à política.

O Launch confirma o pagamento, registra os intervalos imutáveis cobertos pelas compras e salva a tarefa de sincronização na mesma transação do banco de dados. O prazo final é calculado por ciclos de calendário em dias/meses/anos; a renovação mantém a data de referência da compra original, mas, se o pagamento ocorrer após o vencimento, começa no horário real do pagamento. As cotações de upgrade e os prazos continuam sendo calculados no Launch.

Cada alteração envia os valores absolutos completos; as novas tentativas usam o mesmo ID de evento e o mesmo corpo, sem enviar “adicionar mais N dias”. A tarefa persiste a solicitação, a conexão remota e o progresso do processamento; a perda de respostas, as reinicializações do processo e os processos de trabalho simultâneos não acumulam o prazo repetidamente.

HTTP 202 significa apenas que o Licentivo recebeu a solicitação. A sincronização só é marcada como concluída após receber `applied`; com `pending`, as consultas continuam, e `manual_review` e os casos de `stale` que não puderem ser confirmados permanecem aguardando conferência. Erros de rede são repetidos com espera progressiva; quando as falhas consecutivas atingem o limite, o caso passa para conferência manual.

Um reembolso remove apenas o intervalo coberto pelo pedido correspondente: o reembolso de um pedido de upgrade restaura o plano básico; o de uma renovação remove a extensão correspondente. Se ainda houver compras não reembolsadas, o resultado recalculado é sincronizado, sem revogar todas as compras. Após o reembolso de todas as compras, é enviado `entitlement.refunded`. Uma nova compra posterior usa uma nova referência de compra para evitar reativar licenças remotas já revogadas.

Um estorno decorrente de uma disputa perdida ou uma reversão de pagamento confirmados pelo canal também removem apenas a cobertura da compra do pedido correspondente; o pedido aparece como `reversed`, e as alterações reais de autorização continuam sendo tratadas pelo Licentivo após aplicar o instantâneo da compra. Disputas pendentes não alteram o registro de compra. As notificações antigas de reversão que aguardam conferência podem ser recuperadas por meio de nova verificação da assinatura e reenvio pelo canal original.

Após um reembolso desconhecido entrar em conferência manual, um administrador pode recuperar a operação original por meio de `POST /api/v1/admin/refunds/{id}/reconcile`. O comprovante deve corresponder à transação, à moeda e ao valor originais; o número da operação e o horário de aprovação originais não podem ser alterados. Após o término da janela de repetição segura, não se deve reenviar uma solicitação de movimentação de fundos sem conferir seu estado.

## Contas e clientes

1. O cliente usa `POST /api/v1/auth/login` para estabelecer uma sessão real de login no aplicativo de desktop.
2. O SDK do Launch solicita `POST /api/v1/software/products/{id}/identity`, especificando `sandbox` ou `live`.
3. O Launch emite uma asserção de identidade com validade máxima de 120 segundos, destinada a um destinatário e contexto de produto/compra específicos, que contém o `sid` do login real e o vencimento do login. A asserção não contém recursos, cotas de dispositivos nem permissões offline.
4. O SDK do Launch passa `identity_token`, `launch_connection_id` e `environment` ao SDK oficial apenas em memória; `license_key` fica vazio.
5. O SDK oficial chama `/api/v1/launch/exchange` no Licentivo; o Licentivo decide a autorização e fornece as credenciais do dispositivo e a concessão assinada.

Os registros normais de conta do Launch usam v2 e armazenam apenas a sessão da conta e informações públicas de roteamento, sem armazenar asserções, chaves de licença ou concessões de autorização. No logout explícito, o registro é convertido em uma pendência privada v3 destinada exclusivamente à revogação e não pode ser restaurado como login; ele só é excluído após a confirmação da revogação da sessão do Launch. A interface antiga `/credential` retorna HTTP 410. As chaves públicas e os IDs dos produtos podem ser distribuídos com o aplicativo, enquanto as chaves de administração permanecem somente no servidor.

## Logout, fechamento e desvinculação remota

| Ação | Comportamento |
| --- | --- |
| Close / Dispose / Drop comuns | Interrompe a execução e preserva as compras, os vínculos de dispositivos e a conta que o usuário optou por lembrar |
| Entrada de compatibilidade Logout / ReleaseDevice | Marca a conta local como desconectada e chama o logout do SDK oficial, depois revoga a sessão no Launch; logouts de conta não confirmados mantêm uma pendência segura |
| Gerenciar dispositivos no Launch quando não for possível acessar o dispositivo | Encaminha a lista de dispositivos, as solicitações de desvinculação e os resultados do processamento do Licentivo |

O logout do SDK oficial interrompe imediatamente o uso da autorização pelo processo atual, limpa suas credenciais de execução e usa um tíquete específico de logout para revogar o vínculo remoto. Em caso de falha de rede, o arquivo `.logout.json` do SDK deve ser mantido; o resultado deve indicar que a revogação remota está pendente, sem informar que a desvinculação foi concluída. O SDK do Launch não exclui, percorre para limpar nem modifica o diretório de cache do SDK oficial; os tíquetes de revogação pendentes voltam a ser processados pelo SDK oficial quando o cache correspondente é inicializado novamente.

O logout da conta do Launch também tem um estado pendente independente: em caso de falha de rede, cancelamento ou perda da resposta, os registros seguros necessários para repetir a operação não são excluídos; um novo login, uma restauração ou um logout apenas reenvia a revogação da sessão original, e a pendência não pode ser usada para restaurar o login. O registro é excluído após o sucesso ou após HTTP 401 confirmar que a sessão é inválida. A recuperação entre processos exige um Store seguro e persistente; MemoryStore só é válido no processo atual. Consulte [Correção e testes de integração das novas tentativas de logout](/pt/launch-documents/logout-retry-fix-2026-10-24/).

As solicitações de desvinculação remota incluem `activation_id` e `expected_generation` retornados na lista original; as novas tentativas reutilizam `operation_id`. O Launch não calcula a quantidade de desvinculações, não aprova nem executa por conta própria a fila de desvinculação e não atualiza a geração para repetir automaticamente uma operação antiga. A quantidade restante, a permissão de liberação, a análise e o resultado final vêm do Licentivo.

A restauração da conta com `Restore` exige conexão para confirmar a conta e obter uma nova asserção de identidade; o Launch não decide liberar o acesso offline por conta própria quando o serviço de contas falha. Os aplicativos que precisam iniciar offline devem seguir o contrato de restauração do SDK oficial; as verificações de assinatura, prazo offline e relógio continuam a cargo do SDK oficial.

## Revogação de identidade no servidor

Integre as interfaces existentes do Licentivo V39, sem necessidade de interfaces de fatos comerciais ou de cotação:

- `POST /api/v1/launch/connections/{id}/session-revocations`: revoga o login antigo do `sid` ou da conta especificada e retorna um comprovante da confirmação síncrona.
- `GET /api/v1/launch/connections/{id}/session-revocations/{event_id}`: recupera o resultado já confirmado do evento original para recuperar solicitações cuja resposta foi perdida.

O logout normal no aplicativo de desktop e o logout forçado de uma sessão específica usam `scope=session`; a invalidação de todas as sessões devido a alteração ou redefinição de senha, mudança de e-mail, desativação de conta ou alteração de funções dos membros do site usa `scope=account`. O logout normal de uma sessão do site não afeta o software do cliente. O Launch apenas informa que a identidade foi invalidada; as sessões remotas de autorização, as credenciais de execução e a liberação de dispositivos são tratadas pelo Licentivo, sem alterar os prazos de compra nem consumir a cota de desvinculação mantida pelo Launch.

A invalidação da sessão local e a inclusão da notificação na fila ocorrem na mesma transação. A fila fixa as conexões e os ambientes existentes naquele momento e repete a solicitação original com o mesmo ID de evento e identificador anônimo de conta; as conexões criadas posteriormente não recebem revogações históricas da conta. O comprovante original é consultado primeiro, e a solicitação só é reenviada após confirmar que ele não existe. Os resultados são persistidos separadamente para cada ambiente, e a conclusão só é exibida após receber todos os comprovantes de sucesso correspondentes. Falhas de rede geram novas tentativas automáticas; conflitos de credenciais ou contrato passam para conferência manual. O administrador pode consultar as notificações e repetir as operações na página de tarefas de sincronização; uma nova tentativa não gera um novo evento de revogação.

A revogação no escopo da conta usa como limite o `revoked_before` recebido pela primeira vez pelo Licentivo. Enquanto as notificações estiverem pendentes, os novos logins no aplicativo de desktop e as novas asserções de identidade são suspensos; após a conclusão, o `auth_time` do login real deve ser estritamente posterior ao segundo limite de todos os comprovantes dos ambientes. Um login ocorrido no mesmo segundo pode ser autenticado novamente mais tarde; atualizar `iat` ou a asserção de identidade não permite continuar usando o login antigo. O login no site continua disponível para operações de recuperação. Mesmo após reativar a conta, é necessário fazer login novamente; as sessões antigas não são restauradas.

## Migração de dados antigos

As compras com vínculo confirmado a uma licença antiga usam `entitlement.migrated` e enviam apenas o ID da licença antiga, sem ler nem fornecer as chaves antigas. Após o Licentivo confirmar a migração, é enviado um instantâneo separado com uma nova versão para sincronizar os prazos e o estado comercial atuais. Resultados antigos de emissão que nunca foram confirmados e autorizações incompatíveis exigem conferência manual; os comandos antigos de administração não são repetidos automaticamente.

O logout normal do SDK, a desvinculação remota de dispositivos e a revogação de identidade no servidor usam as interfaces existentes. A desativação remota continua sujeita ao prazo das concessões offline já emitidas pelo SDK oficial; o Launch não promete que dispositivos offline receberão uma revogação imediata.

<!-- account-store-ownership-2026-10-24 -->

O logout da conta usa uma pendência segura independente, um resumo local dos logouts de sessão e coordenação entre processos; as instâncias antigas tratam apenas seus próprios logins. Após uma falha de armazenamento, a recuperação primeiro reenvia a revogação da conta, sem obter uma identidade nem iniciar a autorização; os recursos, as concessões offline, as gerações dos dispositivos e as cotas de desvinculação continuam sendo decididos pelo Licentivo. Consulte [Registro da correção e dos testes de integração entre as duas partes](/pt/launch-documents/account-store-fix-2026-10-24/).