Quão difícil é criar seu próprio aplicativo Tap to Pay? (Nós tentamos)

Mais difícil do que os folhetos de SDK sugerem, e a dificuldade na maior parte não é o código. Lançamos o Tap to Pay no aplicativo Final POS, então esta resposta vem da prática, não da leitura de documentação. Se você deseja criar seu próprio aplicativo tap to pay, planeje um projeto de software curto envolvido em um projeto de permissões muito mais longo: uma parceria com processador de pagamentos, uma autorização manual da Apple ou uma avaliação de laboratório no Android, e uma revisão do aplicativo, tudo antes do seu primeiro pagamento real por aproximação.

Uma rápida ressalva: as regras das plataformas e do setor de cartões mudam com frequência. Tudo o que está abaixo é preciso até a data de publicação, portanto, trate os detalhes como um instantâneo.

O que um aplicativo tap to pay realmente faz?

O tap to pay transforma o próprio telefone em um leitor de cartões. Sem terminal, sem dongle: o cliente aproxima um cartão sem contato ou uma carteira digital como Apple Pay ou Google Pay diretamente no dispositivo do comerciante, e o pagamento é processado através do chip NFC do telefone (o rádio de curto alcance usado para pagamentos por aproximação). Se a terminologia parecer confusa, explicamos a diferença entre pagamentos móveis por aproximação e Tap to Pay no celular.

Haki está a armadilha. Ler uma tag NFC é realmente um projeto de fim de semana; entusiastas fazem isso constantemente. Ler um cartão de pagamento é outro esporte. Os cartões usam EMV (o protocolo de chip do setor de cartões), os dados do cartão devem permanecer criptografados de ponta a ponta e apenas softwares certificados têm permissão para tocá-los.

Por que você não pode simplesmente ler o cartão por conta própria?

Porque cada camada da pilha requer permissão antes que seu código possa ser executado publicamente.

• A Apple não concede aos aplicativos acesso direto ao NFC de pagamento. Você deve usar a estrutura ProximityReader, que fica atrás de uma autorização de Tap to Pay no iPhone (uma permissão especial que a Apple concede caso a caso). A Apple também exige que você faça a integração com um provedor de serviços de pagamento (PSP) compatível (a empresa que realmente move o dinheiro). O PSP fornece as configurações certificadas do leitor carregadas no dispositivo do comerciante e assume a responsabilidade pela certificação.

• O Android oferece aos desenvolvedores um acesso NFC mais aberto, mas um aplicativo de aceitação de pagamento ainda precisa ser avaliado por um laboratório independente reconhecido pelo PCI em relação ao padrão PCI MPoC (as regras de segurança do setor de cartões para telefones que atuam como terminais de pagamento).

• Por trás de ambas as plataformas, você precisa de uma relação de credenciamento: um processador disposto a liquidar o dinheiro para seus comerciantes, seguindo as regras das bandeiras de cartões.

Nada disso pode ser resolvido na força bruta escrevendo um código melhor. Trata-se de papelada, contratos e filas de revisão.

Como é o caminho de aprovação no iPhone?

De acordo com os requisitos publicados pela Apple, o caminho funciona assim: ter uma conta Apple Developer de nível organizacional (o titular da conta faz a solicitação pessoalmente), fazer parceria com um PSP compatível para suas regiões, solicitar a autorização, integrar a API ProximityReader ou o SDK do seu PSP, seguir as diretrizes de design da Apple para a tela de pagamento e enviar o aplicativo para revisão. A documentação da Apple também observa que o recurso funciona apenas em países e regiões com suporte, de modo que a própria disponibilidade é decidida para você, mercado por mercado.

Leia essa lista novamente como fundador ou comerciante, e não como desenvolvedor. Nenhum passo dela é "escrever o recurso". O recurso é a parte fácil; a autorização é a barreira de entrada.

Para onde vai o trabalho depois que a aproximação funciona?

Uma aproximação aprovada gera um pagamento, não um ponto de venda. No momento em que o dinheiro se move, tudo ao redor do pagamento precisa estar correto: o carrinho contra o qual ele é liquidado, os impostos no recibo, o fluxo de reembolso e os relatórios conciliados (cada centavo correspondendo a uma venda, todos os dias). Encontramos essa mesma lacuna quando analisamos se é possível criar um POS com Lovable ou Replit: gerar uma interface é rápido, mas a camada de comércio por baixo é o que consome o cronograma.

O tap to pay também traz suas próprias peculiaridades operacionais. Em nossa implementação, la venda deve ser registrada no mesmo dispositivo que recebe a aproximação, e funciona apenas no aplicativo nativo, nunca em um navegador. Limitações como essa não aparecem em nenhum folheto. Você as descobre, desenvolve soluções alternativas e depois escreve o artigo de ajuda. E quando um telefone no balcão deixa de ser suficiente, você acaba entrando em decisões reais de hardware de qualquer maneira.

Então, quão difícil é criar seu próprio aplicativo tap to pay?

Difícil de uma maneira específica: a codificação é a menor parte, enquanto a parceria com o processador, a autorização da Apple, a certificação de laboratório no Android e a revisão do aplicativo representam a maior parte, e nada disso responde ao esforço de engenharia. Para nós valeu a pena, porque uma plataforma de POS distribui esse custo por todos os comerciantes que a utilizam. O tap to pay agora é um botão de checkout que nossos comerciantes ativam, e receber um pagamento com Tap to Pay é uma rotina de balcão de cinco etapas. Se os pagamentos são o seu produto, esse desafio é o preço de entrada. Se os pagamentos são apenas a forma como você recebe, criar seu próprio aplicativo tap to pay não faz sentido financeiro; a versão finalizada já existe dentro de aplicativos de POS, e as taxas são onde reside a verdadeira comparação.

Regra geral: se um recurso precisa da permissão de outra pessoa para existir, nenhuma quantidade de código inteligente o encurtará.