Resumo

  • O RFC 3538 associava 20, 40, 60, 80 e 100 à criação ou ao processamento de mensagens SET sucessivas na ponte IOTP. A escala media etapas da interface, não a parcela concluída do resultado comercial.
  • Em 100, PRes podia registrar autorização aprovada ou captura bem-sucedida. CompletedOK ainda podia virar Failed após cancelamento; liquidação e entrega permaneciam fora da prova.

Uma tela operacional exibe a barra cheia. O que o operador realmente sabe? Houve autorização, captura, liquidação entre instituições, liberação do pacote ou impossibilidade de cancelar? Interfaces costumam comprimir essas perguntas em “concluído”. Publicado em junho de 2003 como Informational, o RFC 3538 deu uma resposta mais precisa: a ponte entre SET e IOTP processou a última mensagem de seu mapa.

O IOTP buscava uma estrutura comum para comércio eletrônico sem exigir um único meio de pagamento. O suplemento descrevia como mensagens Secure Electronic Transaction passariam pela Payment API do IOTP 1.0. As fontes congeladas não mostram adoção mensurada, transação identificada nem incidente real. A relevância histórica está em não transformar uma observação local em autoridade sobre todo o negócio.

A seção 8.12 define cinco marcos. Depois da criação ou do processamento da primeira SET Initiation Response, PercentComplete vale 20. PinitReq leva a 40, PinitRes a 60, PReq a 80 e PRes a 100. Consumer e Payment Handler observam criação e processamento de lados opostos. A iniciação pode ter quantidade variável de mensagens, mas a primeira resposta recebe 20. Portanto, a escala não mede trabalho homogêneo nem tempo restante; ela nomeia pontos convencionais da interface.

O ponto final guarda mais de um significado. Um PRes aceito pode trazer authorizationPerformed com AuthCode aprovado, ou capturePerformed com CapCode de sucesso. Autorizar permite prosseguir; capturar pertence a outro momento comercial. Usar o mesmo envelope e chegar ao mesmo 100 não torna os fatos equivalentes. Sem o código, a barra não diz qual deles ocorreu.

A máquina de estados também limita a aparência de final. No Payment Handler, uma transação pode passar de em andamento para CompletedOK. Porém, se o pagamento for cancelado, ChangeProcessState ou CancelPayment permite CompletedOK -> Failed. O estado é a visão de um componente em certo instante. Apagar a transição cria uma irrevogabilidade inexistente.

O recibo oferece um aviso ainda mais direto. CheckPayReceipt não verifica especialmente Payment Receipt Information; responde de forma geral se a requisição for válida. Isso pode ser a divisão correta de tarefas da API. Torna-se incorreto quando “estrutura válida” aparece para o leitor como “fato comercial verificado”. Envelope válido, recibo reconhecido e alegação corroborada são evidências diferentes.

A entrega continua fora da ponte. Para bens físicos, o documento recomenda omitir IOTP Delivery Exchanges. Uma localização de consulta pode ser informada, e a verificação de autorização entre gestores pode ocorrer fora do IOTP. Para bens digitais, recomenda autorização em tempo real. Concluir mensagens de pagamento não move mercadoria e não prova que conteúdo chegou.

Consulta e erro preservam a mesma separação. SET Inquiry Initiation é omitido e as mensagens de consulta são encapsuladas em dados IOTP. Erro técnico da ponte usa HardError; falha comercial percorre outra rota. Sem a origem, uma recusa corretamente transportada parece falha técnica, ou uma ponte saudável parece venda bem-sucedida.

O artigo sobre RFC 3354 já possui os requisitos do IOTP v2 e a fronteira entre composição e autorização. O artigo sobre RFC 3504 possui correções, identidade, consulta e a separação geral entre pagamento, liquidação e entrega. O território do RFC 3538 é o painel específico: cinco valores, dois sentidos de PRes, checagem limitada de recibo e cancelamento depois de “concluir”.

A regra duradoura é nomear o denominador de todo progresso. Devem permanecer a mensagem exata, quem a criou ou processou, o completion code e cada transição posterior. Assim, 100 é evidência útil. Sem proveniência, é um símbolo que toma certeza emprestada de eventos que nunca mediu.

Fontes