O que uma loja precisa para receber pagamentos por aproximação num celular?
Um prestador de serviços de pagamento, e um aplicativo feito sobre o framework da plataforma destinado a isso. O celular substitui o hardware do terminal e herda tudo o que vinha com um terminal: certificação, uma autorização da plataforma, e um aparelho que tem de ser mantido atualizado.
O celular como leitor
Esta é a imagem espelhada do resto da seção. Em vez de o celular apresentar um cartão, ele está lendo um, que é o modo leitor como a página do modo leitor descreve, aplicado a um cartão de pagamento.
A Apple documenta isso como Tap to Pay on iPhone no framework ProximityReader, que permite a um iPhone funcionar como um ponto de venda sem hardware adicional, e que também lê cartões de fidelidade da carteira na mesma sessão.
O equivalente existe na outra plataforma através dos prestadores de pagamento em vez de como um framework geral, e o formato das exigências é o mesmo dos dois jeitos.
Você continua precisando de um prestador
A documentação da Apple é explícita: usar o framework exige combinar com um prestador de serviços de pagamento participante que seja certificado no nível mais alto dos testes de pagamento, e uma autorização pedida à Apple antes de o aplicativo conseguir integrá-lo.
Então o celular tira um pedaço de hardware do balcão e não tira nada da cadeia contratual. O adquirente, o prestador, as taxas e o prazo em que o dinheiro chega continuam todos lá.
A documentação também afirma que o Tap to Pay on iPhone segue a norma PCI CPoC, que é a norma de segurança escrita para aceitar pagamentos por aproximação num aparelho comum, com núcleos de pagamento certificados e uma interface definida.
O que o framework impõe
Uma leitura por vez, a partir de uma sessão obtida depois de o aparelho ter sido configurado, como a sessão de leitura expõe. Não há como procurar cartões em segundo plano nem rodar dois leitores ao mesmo tempo num aparelho.
Uma maneira de capturar um código quando a transação exige um, que é a parte que as pessoas supõem ser impossível num celular.
Um modo de guardar e enviar depois, que deixa um aparelho receber pagamentos enquanto não consegue alcançar o prestador e mandar o bloco em seguida. Essa é a funcionalidade de que uma barraca de feira ou uma rota de entrega precisa de fato, e ela é documentada em vez de improvisada.
E uma data publicada em que a versão atual do sistema operacional deixa de ser aceita para pagamento, exposta pela própria sessão. Um celular de loja que nunca é atualizado deixa de conseguir receber dinheiro, por projeto.
O que isso significa numa loja
A economia é o terminal e a manutenção dele, não a economia do pagamento. Quem compara isso com um terminal pelo preço deve comparar as taxas dos prestadores e não o hardware.
O celular vira equipamento de caixa: ele precisa de carga ao longo de uma jornada, de uma capa que aguente um balcão, e de uma política de atualização, porque o framework vai se recusar a funcionar num sistema operacional que ficou para trás.
E a experiência de quem compra é a que decide a adoção: um celular estendido sobre um balcão é menos óbvio que um terminal, então diga às pessoas onde encostar, o que a página da sinalização cobre e que vale para uma pessoa da equipe segurando um celular tanto quanto para uma tag numa parede.
Perguntas frequentes
Qualquer celular consegue receber pagamentos?
Não. Ele precisa de um aparelho compatível, de um aplicativo feito sobre o framework da plataforma, e de um prestador de serviços de pagamento certificado para isso.
Isso substitui o prestador de pagamento?
Não. Substitui o hardware do terminal. O adquirente, o prestador, as taxas e o prazo em que o dinheiro chega continuam iguais.
Dá para pedir uma senha?
O framework documenta uma maneira de capturar um código quando uma transação exige um, então um pagamento acima do limite não é recusado automaticamente.
O que acontece se o celular nunca for atualizado?
Ele deixa de conseguir receber pagamentos. A sessão expõe a data em que a versão atual do sistema operacional deixa de ser aceita.