Períodos de teste: Contabilidade e integração

Especifica registros, chamadas de provedores, webhooks, idempotência, reconciliação, impostos e evidências de auditoria para períodos de teste. Esta referência define o limite de adoção, comportamento em caso de falha e evidências observáveis, deixando os limites específicos do ambiente configuráveis.

Status do pacote: contexto de referência pronto para revisão humana. O contrato e os cenários de teste estão completos, mas não há garantia de que uma implementação adotante os tenha aprovado.

Decisão

Para períodos de teste, adote um livro razão interno durável reconciliado com eventos autenticados do provedor. Implemente o comportamento por meio de um caminho de gravação autoritativo, interfaces tipadas, estado explícito e tratamento idempotente de efeitos colaterais. Este bloco de implementação foca especificamente em contabilidade e integração. Este pacote é um contrato de referência: a equipe adotante deve escolher limites numéricos, provedores, jurisdições e responsáveis operacionais com base em evidências do seu próprio ambiente.

Escopo

• Os atores, entradas, saídas, estados, versões de política ou esquema e resultados visíveis externamente necessários para o foco de contabilidade e integração deste bloco de implementação.
• Interfaces primárias e alternativas, trabalhos em segundo plano, caches, integrações, caminhos de suporte e evidências que podem exercer o mesmo limite.
• Configuração específica de adoção, implantação, recuperação e responsabilidades de verificação necessárias para aplicar a referência com segurança.

Fora deste bloco

• Escolher um fornecedor universal, framework, jurisdição, limite numérico, período de retenção ou objetivo de nível de serviço para todos os adotantes.
• Alegar que os cenários empacotados foram executados contra uma implementação a jusante ou que esta referência concede certificação legal, de segurança ou acessibilidade.

Contrato

• Represente dinheiro com uma moeda explícita e valor decimal exato ou unidade menor; nunca use ponto flutuante binário para aritmética de livro razão.
• Dê a cada intenção financeira visível externamente uma chave de unicidade durável mantida pelo tempo relevante do livro razão e auditoria.
• Autentique callbacks do provedor, persista a referência do evento bruto e aplique transições de estado idempotentemente após validação do estado atual.
• Separe estados de cliente, provedor, direito, fatura, liquidação, reembolso e reconciliação em vez de tratar um único status como autoritativo para todos.
• Valide entradas uma vez na fronteira e preserve a representação normalizada usada pela lógica a jusante.
• Persista a transição de negócio antes ou atomicamente com um registro de outbox; consumidores deduplicam por identidade durável da operação.
• Armazene elegibilidade para teste, escopo do produto, instantes exatos de início e fim, apresentação de fuso horário, termos de conversão, política de lembrete, cancelamento e histórico de testes anteriores como estado autoritativo.
• Torne início e conversão idempotentes, divulgue preço e renovação antes do compromisso e reconcilie falha de pagamento, mudança de plano, extensão, reembolso e expiração de direito.
• Para a variante de contabilidade e integração, aplique este limite declarado: especifica registros, chamadas de provedores, webhooks, idempotência, reconciliação, impostos e evidências de auditoria para períodos de teste.

Orientações de implementação

• Implemente primeiro mudanças aditivas de armazenamento e interface, preencha retroativamente de forma observável e depois retire caminhos antigos após evidência de compatibilidade.
• Modele entradas, saídas, atores, estados, invariantes, efeitos colaterais e evidências dos períodos de teste antes de selecionar detalhes de framework ou fornecedor.
• Armazene a versão aplicável do contrato ou política de períodos de teste com o estado material para que migrações, reprodução e decisões de suporte permaneçam atribuíveis.
• Introduza o caminho por trás de implantação controlada, compare resultados esperados e observados e mantenha uma rota de recuperação testada até que a evidência de adoção esteja completa.

Tratamento de falhas e salvaguardas

• Um resultado ambíguo do provedor permanece pendente de reconciliação; o sistema não concede valor duplicado nem descarta silenciosamente uma obrigação financeira.
• Estado inválido ou contraditório de períodos de teste é rejeitado ou colocado em quarentena; a implementação nunca supõe um valor que amplie autoridade ou duplique um efeito.
• Retentativas são limitadas e usam identidade durável; após esgotamento, o trabalho alcança um estado terminal inspecionável com um responsável contabilizável.

Verificação e operações

• Injete falha de dependência antes e depois da persistência e prove que a retentativa converge para um resultado visível externamente.
• Monitore sucesso, negação, falha de validação, falha de dependência, esgotamento de retentativas e recuperação dos períodos de teste por versão de contrato sem dimensões sensíveis de payload.
• Reexecute fixtures positivos e negativos emparelhados após mudanças de política, esquema, dependência, migração ou limite e preserve a evidência resultante.

Suposições de adoção

• Nomes e valores no exemplo são um fixture concreto, não padrões universais; adotantes os substituem por meio de evidências documentadas e propriedade.
• O sistema adotante pode fornecer identidade autenticada, versões duráveis de operação ou registro, telemetria limitada e um caminho controlado para mudanças.

Os exemplos com aparência executável neste pacote são fixtures e contratos de aceitação. Execute o validador da coleção para verificar estrutura e metadados, depois traduza e execute os cenários no repositório alvo antes de registrar evidências de implementação.

Referências

• PCI Security Standards Council, PCI DSS (aplica-se a partir de 2026-09-08)