[mariolucasdev]

Closes #109.

O que muda

PHPay\Support\StaticPixCode compõe o BR Code de uma chave Pix, sem rede:

use PHPay\Support\{Money, StaticPixCode};

StaticPixCode::make('fale@phpay.io', 'Sixtec LTDA', 'BRASILIA')
    ->withAmount(Money::reais('100,50'))   // opcional: sem valor, o pagador digita
    ->withTxid('PEDIDO1234')               // opcional: *** quando ausente
    ->payload();

É suporte, como o Money: não é Resource, não é capacidade e não entra na enum Capability, porque não há chamada HTTP e portanto não há gateway envolvido. Fecha a assimetria do SupportsPixKeys — Asaas e Woovi expõem endpoint para o QR estático, a Efí não — sem stub e sem sugerir que a API da Efí oferece o que não oferece.

O CRC, que é onde isso dá errado

O CRC-16 final cobre o literal 6304 que o anuncia, não para antes dele. Parar antes é o erro mais comum de quem implementa o padrão, e o resultado é um código que simplesmente não lê — o erro aparece na frente do pagador, não no log.

Então a prova não é "os testes passam", é o vetor oficial do Manual de Padrões para Iniciação do Pix, byte a byte. Conferi o vetor por conta própria antes de escrever uma linha de implementação:

com o literal 6304: 1D3D      ← o que o manual traz
sem o 6304:         4AAD      ← o erro comum

E o payload que a classe produz para esse vetor é idêntico ao do manual:

00020126580014br.gov.bcb.pix0136123e4567-e12b-12d1-a456-4266554400005204000053039865802BR5913Fulano de Tal6008BRASILIA62070503***63041D3D

Esse é o primeiro teste do arquivo. Um teste adicional lê o TLV de volta e confere campo por campo, porque um byte errado em qualquer tamanho desalinha todos os campos seguintes — é o tipo de defeito que um toContain() não pega.

Decisões que valem revisão

Só o payload, nunca a imagem. Renderizar exige codificador de QR Code, e o runtime aqui é ext-curl, ext-json, ext-openssl e o Guzzle. Dependência nova numa biblioteca de pagamentos custa mais que a conveniência.

Tamanho em bytes, não em caracteres. Quem lê o payload anda em bytes; Comércio tem 8 caracteres e 9 bytes, e declarar 8 desalinharia tudo depois. Tem teste.

O formato da chave não é validado. EVP, e-mail, telefone e CPF/CNPJ não se parecem, e uma checagem apressada reprovaria chave boa. Recusa chave vazia e acima de 77 caracteres, que é o que cabe no campo 26.

O merchantName é cosmético — o app do pagador mostra o nome que vem do DICT e ignora o campo 59. Está no PHPDoc e na documentação, para ninguém construir em cima dele.

A Efí não ganhou atalho. Dava para expor um staticQrCode() no recurso Pix dela chamando o VO por baixo, pela simetria. Não fiz: todo método de Resource faz HTTP, um que não faz quebra a expectativa, e sugeriria que a API da Efí oferece algo que ela não oferece. A nota da Efí em docs/ aponta para o VO.

Como testar

composer test: 506 testes (de 483), nenhum tocando a rede — não há o que mockar aqui. Os dois commits foram verificados um por um.

Além do vetor oficial: valor ausente e presente, Money em reais e em centavos, número cru lido como reais, txid ausente e presente, imutabilidade do with...(), acento contado em bytes, e as recusas (chave vazia, chave longa, nome e cidade vazios ou longos, txid com hífen, espaço ou longo, valor com três casas e valor negativo).

Checklist

• composer test passa (Pint, Pest e PHPStan nível 9)
• Cobri a mudança com testes, usando HTTP mockado (nenhum teste acessa a rede)
• Atualizei README, CLAUDE.md ou UPGRADE.md, se a mudança afeta quem usa a biblioteca
• Nenhuma credencial, token ou dado pessoal real foi commitado
• Li e aceito o Contributor License Agreement

Aditivo: classe nova, nada existente mudou de assinatura ou de comportamento.

Um limite que vale registrar: com isso a biblioteca passa a implementar uma especificação do BACEN, não só a API de um gateway. Se o manual mudar, isso aqui envelhece — o vetor na suíte é o que vai avisar.