OpenTest 项目：API 接口补齐与全业务逻辑规范

Conclusão da interface API e especificação da lógica comercial

Data de criação do documento: 2026.01.16 | WordPress Faturação e interface back-end para fins especiais

1. ⚠️ Lista de APIs back-end a aperfeiçoar

Falta o seguinte conteúdo para a atual documentação da API, que deve ser desenvolvido com o complemento:

Interface 1 Adicionar verificação de assinatura: Aumentar sinal Campos. Uma vez que o WordPress inicia notificações de lançamento de activos, a segurança deve ser verificada por assinaturas MD5.
Interface 1 Adicionar associação de ordem originalEm resposta a ACTUALIZAÇÃO é necessário passar originalOrderNoO back-end tem de localizar os activos antigos e efetuar as actualizações de SKU em conformidade. O back-end tem de localizar os activos antigos e efetuar as actualizações de SKU em conformidade.
Interface 4 Adicionar nome do dispositivo Retorno: necessidade de regressar nome da máquina. Caso contrário, os utilizadores não podem identificar diferentes computadores para operações de desagregação no Centro Pessoal.
Interface 4 Aumentar o número de resíduos offline: necessidade de regressar remainingOfflineUnbindCount. Utilizado para limitar as licenças offline a 3 pacotes por ano.

2. atualizar as principais regras de conformidade

Versão pessoal do tratamento de activos: Para garantir a coerência do código de autorização, a atualização da Personal Edition tem "Substituir atualização" Lógica.
1) Após o pagamento bem sucedido, o WP envia um pedido contendo orderType: UPGRADE até originalOrderNo.
2. o backend localiza o código de autorização associado à encomenda original e actualiza apenas o seu skuCode campos.Não é gerado nenhum código novo.
3) Uma atualização é apenas uma mudança de autoridade; o período de validade permanece, em princípio, inalterado.

3. atualizar a fórmula de conversão da faturação (implementação WP)

As actualizações só são suportadas num sentido ascendente. o plugin WordPress calcula o montante da ordem de propagação de acordo com a seguinte fórmula:

Montante da recarga = Preço do novo pacote - (Preço pago do pacote original / Total de dias do pacote original * Dias disponíveis restantes)

4. resumo da decomposição lógica da geração do código de autorização

Dimensão empresarial	Cenários de compra	Descrição das acções de execução back-end
Pacote Personal Edition	Nova compra (NEW)	Gerar um novo código de autorização e vinculá-lo automaticamente.
	Renovação (RENEW)	Não gera um novo código, actualiza o tempo de expiração (EndTime) do código original.
	ACTUALIZAÇÃO	Não é gerado qualquer código novo e o código SKU do código original é atualizado.
Pacote Team Edition	Todas as cenas	Um novo código de autorização é gerado independentemente para cada lugar.
kit opcional	Novas compras/compras de equipas	Gerar um número correspondente de novos códigos de autorização de pacotes de opções.

5) Regras de vinculação/desvinculação do código de autorização (Interface 3)

apatridiaExecução direta BIND Funcionamento.
Estado do pacote existenteO sistema precisa de ser inicializado eChamar primeiro UNBIND para desvincular o código de licença antigo.Se não houver um novo código BIND, executar um novo código BIND.
Estado do pacote opcional disponívelExecução direta é permitida BIND, realizando a sobreposição facultativa de direitos.

Iniciar a sua viagem transfronteiriçaContactar-nos agora

Desenvolvimento de sítios Web serviço ao cliente

Serviço ao cliente

Designer (realização de protótipos Figma)