Resumo

  • Em janeiro de 1997, a RFC 2068 incluiu 402 Payment Required no HTTP/1.1 e o deixou com uma instrução: “reservado para uso futuro”.
  • RFC 2616, RFC 7231 e RFC 9110 repetiram a reserva. O HTTP não oferece ao 402 um preço comum, um desafio de pagamento ou regras de liquidação.

Num checkout internacional, 402 Payment Required sinaliza a barreira no momento da compra. O comprador ainda precisa de preço e moeda; a equipe que integra a loja ao serviço precisa saber qual comprovante será aceito e como confirmar a liquidação. Como o código não padroniza essas respostas, cada parceria exige suas próprias regras.

O número chegou antes da cobrança

A RFC 1945 descreveu os códigos de status como resultados legíveis por máquinas e listou os valores reconhecidos no HTTP/1.0. Na sequência de erros do cliente, 401 Unauthorized vinha antes de 403 Forbidden; o 402 não aparecia. A especificação permitia códigos de extensão, portanto um número fora da lista podia circular como extensão. O catálogo publicado é que não lhe dava semântica própria. RFC 1945 §§6.1.1–6.1.2

A especificação HTTP/1.1 de janeiro de 1997 colocou o 402 na gramática de códigos de status e lhe deu a seção 10.4.3. A regra inteira cabia numa frase: “This code is reserved for future use.” O nome anunciava uma barreira econômica; o texto normativo não dizia como pagá-la. RFC 2068 §§6.1.2, 10.4.3

Um status pode classificar a resposta do servidor. O 402 não informa valor, moeda, recebedor, comprovante aceito, confirmação, liquidação ou caminho para contestar a cobrança. A aplicação pode explicar suas condições no corpo da resposta, mas o HTTP não transforma essas condições em regras que outros clientes e servidores possam reutilizar.

O 401 trouxe um desafio; o 402, uma placa de “volte depois”

O código vizinho 401 mostra como uma interação comum pode ser definida. A RFC 9110 exige que a resposta 401 contenha WWW-Authenticate com ao menos um desafio aplicável. O cliente pode ler o mecanismo e escolher como apresentar credenciais. A seção 15.5.3 não dá ao 402 instrução comparável: apenas repete que ele está reservado. RFC 9110 §§15.5.2–15.5.3

A conta da implementação fica com a aplicação. Para colocar um recurso atrás de pagamento, o serviço precisa definir o que é devido, como o comprador prova que pagou, quem recebe o valor e como tratar uma prova recusada ou uma liquidação que falhou. O protocolo fornece o aviso; a equipe ainda precisa construir a cobrança, o recibo e o fluxo de erro.

O futuro ganhou várias prorrogações

A RFC 2616, publicada em junho de 1999, repetiu a frase na seção 10.4.3. A RFC 7231 fez o mesmo em 2014. A RFC 9110 repetiu a reserva em 2022. O número da seção mudou; o aviso ficou. Cada edição atualizou a semântica do HTTP e levou adiante a vaga de pagamento sem preencher suas regras. RFC 2616 §10.4.3 · RFC 7231 §6.5.2

As RFCs não identificam o sistema de pagamento imaginado pelos autores. Um registro de projeto da época que nomeasse esse sistema mudaria a explicação histórica. Os padrões publicados informam o nome do código e preservam a reserva; não contam a origem do espaço vazio.

Na página consultada para este artigo, atualizada em 15 de setembro de 2025, o registro da IANA ainda lista 402 como “Payment Required” e aponta para a RFC 9110, seção 15.5.3. Registro de códigos de status HTTP da IANA

O custo volta para quem integra

Aqui entra a economia da interface para desenvolvedores. Um protocolo compartilhado pode poupar cada equipe de negociar os mesmos detalhes em manuais próprios. O 402 do HTTP não oferece essa economia. Cliente e servidor precisam acordar na camada da aplicação sobre preço, prova, credenciais, novas tentativas e confirmação final. Desenvolvedores assumem integração e manutenção; cada serviço mantém o controle de suas condições.

O 402 é o nome de uma situação, não uma interface de pagamento. Ele indica que o servidor condiciona o acesso a um pagamento, sem dar ao cliente um método comum para cumprir a exigência. No HTTP, o caixa continua sendo uma regra local com número padronizado.

Fontes