# Como Aceitar Pagamentos com Cartão numa Aplicação POS Personalizada

> Published: 2026-10-27
> Updated: 2026-10-27
> Author: Mathias Nielsen
> Category: Pay
> Canonical: https://finalpos.com/pt/blog/como-aceitar-pagamentos-com-cartao-numa-aplicacao-pos-personalizada

Um formulário de cartão não é um terminal de pagamento. Aqui estão as quatro formas reais de aceitar pagamentos com cartão numa aplicação POS personalizada ou criada com IA, o que a Apple, a Google e o seu fornecedor exigem para cada uma, e quanto tempo demora.

Para aceitar pagamentos com cartão numa aplicação POS personalizada, passa por um fornecedor de serviços de pagamento (PSP) e por um de quatro caminhos: um leitor de cartões certificado, Tap to Pay no iPhone, Tap to Pay no Android, ou um terminal inteligente ligado à nuvem. A sua aplicação nunca lê o número do cartão. Ela envia um valor para o hardware ou software certificado e recebe uma resposta de aprovado ou recusado. Cada caminho tem os seus próprios requisitos da Apple, Google ou do seu fornecedor, e essa burocracia, e não o código, é o que consome tempo.

Este guia apresenta cada caminho passo a passo, com os requisitos reais e sem exageros. Nós processamos pagamentos para o nosso próprio POS, o Final, pelo que já passámos por cada uma destas etapas.

![Aceitar pagamentos com cartão numa aplicação POS personalizada: cartão sem contacto a ser lido no telemóvel de um comerciante no balcão de um café](https://storage.googleapis.com/final-os-media/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/aa1be6a479fcf8f3-accept-card-payments-custom-pos-app-hero.png)

## Por que não pode simplesmente adicionar um formulário de cartão ao seu POS?

Porque um formulário de cartão torna a venda "sem cartão presente" (card-not-present), e o balcão de uma loja precisa de ser "com cartão presente" (card-present). Quando um cliente digita o número do cartão num formulário web, o pagamento é tratado como uma encomenda online: taxas mais elevadas, maior exposição a fraudes e mais risco de disputa do seu lado. Quando um dispositivo certificado lê o cartão ou telemóvel, o pagamento é presencial com cartão, o que é mais barato e seguro para todos.

A aceitação de cartão presente exige hardware ou software certificado. É por isso que cada caminho abaixo é executado através do produto presencial de um PSP, em vez do seu próprio código. A diferença nas taxas é explicada em [cartão presente vs cartão não presente](/en-US/blog/card-present-vs-card-not-present).

## Caminho 1: Como utilizar um leitor de cartões com a sua própria aplicação?

Escolha um PSP com um SDK presencial, compre um dos seus leitores certificados e emparelhe-o a partir da sua aplicação. O Stripe Terminal, a Adyen e outros funcionam desta forma.

1. Abra uma conta no PSP e ative o seu produto presencial.
2. Integre o seu SDK para iOS, Android ou React Native.
3. Encomende leitores certificados e registe-os na sua conta.
4. Detete e conecte leitores a partir da sua aplicação, depois recolha pagamentos através do SDK.
5. Planeie as atualizações de firmware do leitor, que o PSP disponibiliza automaticamente.

Não pode conectar um leitor qualquer: apenas leitores certificados com o seu fornecedor podem processar cartões, porque a certificação cobre a combinação exata de leitor, software e processador. Mais em [leitores de cartão para aplicações POS personalizadas](/en-US/blog/card-reader-sdk-custom-pos) e [certificação EMV para um POS](/en-US/blog/emv-certification-pos).

## Caminho 2: O que exige o Tap to Pay no iPhone?

O Tap to Pay no iPhone transforma o telemóvel no leitor. Os passos da própria Apple são: trabalhar com um PSP suportado, solicitar a autorização de Tap to Pay no iPhone, integrar a API ProximityReader ou o SDK do seu PSP, seguir as Diretrizes de Interface Humana da Apple e submeter a aplicação para revisão ([visão geral do Tap to Pay da Apple](https://developer.apple.com/tap-to-pay/)). A Apple indica que o PSP é responsável pelas certificações que permitem aos comerciantes aceitar pagamentos.

Na prática, isto significa:

1. **Uma conta de desenvolvedor empresarial.** O pedido de autorização deve vir do Titular da Conta de uma conta empresarial, e a inscrição como organização precisa de um número D-U-N-S. Consulte [números D-U-N-S e contas de desenvolvedor Apple](/en-US/blog/duns-number-apple-developer).
2. **O formulário de pedido.** Indique o seu PSP e as regiões onde irá operar.
3. **Uma autorização para desenvolvimento.** A Apple concede uma para construir e testar nos seus próprios dispositivos.
4. **Requisitos de UX da Apple.** A Apple envia os seus requisitos e diretrizes de marketing com a autorização, cobrindo texto de botões, pontos de entrada e integração.
5. **Uma autorização de distribuição.** Responde ao e-mail da Apple e solicita novamente para distribuição. O TestFlight e a App Store precisam desta autorização.
6. **App Review (Revisão da aplicação).** A sua aplicação é lançada assim que for aprovada.

Funciona no iPhone XS ou posterior e não funciona no iPad. O guia completo está em [como obter a autorização de Tap to Pay no iPhone](/en-US/blog/tap-to-pay-iphone-entitlement), com dicas de revisão em [passar na revisão com uma aplicação Tap to Pay](/en-US/blog/tap-to-pay-app-review) e alternativas em [por que motivo o Tap to Pay não funciona no iPad](/en-US/blog/tap-to-pay-on-ipad).

## Caminho 3: Como difere o Tap to Pay no Android?

Não existe uma autorização ao estilo da Apple no Android, mas o SDK do PSP aplica as suas próprias verificações. Requisitos típicos:

- Um dispositivo Android com NFC integrado a executar o Android 11 ou posterior
- Um dispositivo certificado pela Google que passe na atestação de integridade
- Uma compilação não depurável (non-debuggable): os SDKs dos PSPs recusam-se a aceitar leituras reais em modo de depuração, pelo que testa com um leitor simulado
- Permissões de localização e outras permissões que o SDK solicite

Os tablets Android podem funcionar se cumprirem os requisitos do fornecedor. Detalhes em [Tap to Pay no Android numa aplicação personalizada](/en-US/blog/tap-to-pay-android-sdk).

## Caminho 4: Um POS baseado no navegador pode aceitar cartões?

Sim, através de um terminal inteligente ligado à nuvem. O seu servidor indica à API do PSP para enviar um pagamento para um terminal específico no balcão; o terminal processa o cartão e reporta o resultado de volta ao seu servidor. Este é o único caminho presencial que um POS web pode utilizar, porque uma página web não consegue ler um cartão por contacto e o Safari não consegue aceder a leitores Bluetooth.

É ideal para lojas de atendimento ao balcão com um terminal fixo. Adiciona uma dependência de rede, pelo que deve planear o que acontece quando a ligação da loja cair.

## Como escolher um fornecedor de pagamentos para um POS personalizado?

Comece pelos países em que vende, depois a admissão (onboarding) e o hardware:

| Pergunta | Por que motivo importa |
| --- | --- |
| O fornecedor está ativo nos seus países? | O Tap to Pay e os leitores são lançados país a país |
| A adesão é self-service? | O Stripe é self-service; a Adyen foca-se em empresas maiores e avalia os candidatos de forma mais seletiva |
| Que SDKs oferece? | iOS, Android, React Native e terminais geridos por servidor diferem consoante o fornecedor |
| Que leitores são certificados? | Apenas leitores certificados funcionam |
| Suporta pagamentos offline? | O armazenamento e envio posterior (store-and-forward) é específico do fornecedor e transfere o risco de recusa para si |
| Está a registar outros comerciantes? | Se sim, é uma plataforma e pode precisar de acordos de facilitador de pagamentos (payfac) |

A nossa comparação lado a lado é [Stripe Terminal vs Adyen para uma aplicação POS personalizada](/en-US/blog/stripe-terminal-vs-adyen). Se planeia aceitar pagamentos em nome de outras empresas, leia primeiro [tornar-se facilitador de pagamentos ou utilizar uma plataforma](/en-US/blog/payment-facilitator-vs-platform); para uma única loja é simplesmente um comerciante.

## Que conformidade herda e qual mantém?

Utilizar o SDK ou leitor certificado de um PSP significa que os dados do cartão nunca tocam no seu código, o que mantém o seu âmbito PCI reduzido. O PSP assume as certificações de pagamento. Ainda assim, mantém:

- Um questionário de autoavaliação PCI com o seu processador
- Controlo de acessos, registo de logs e atualizações nos dispositivos que executam o seu POS
- Recibos, reembolsos e reversão de impostos corretos
- As regras de apresentação e marketing da Apple e do seu PSP para o Tap to Pay

Se estiver a criar também o resto do POS, o nosso artigo principal sobre como [criar o seu próprio sistema POS com IA](/en-US/blog/build-your-own-pos-system-with-ai) cobre PCI, impostos e distribuição, e [hardware POS para aplicações personalizadas](/en-US/blog/pos-hardware-for-custom-apps) cobre impressoras e gavetas.

## Quanto tempo demora a aceitar o seu primeiro pagamento com cartão?

| Etapa | Tempo típico |
| --- | --- |
| Conta empresarial Apple com D-U-N-S (para Tap to Pay no iPhone) | Dias a algumas semanas |
| Conta PSP e produto presencial ativado | No próprio dia a várias semanas, dependendo do fornecedor |
| Integração de SDK e pagamentos de teste | 1 a 3 semanas |
| Desenvolvimento do Tap to Pay, depois autorização de distribuição | Semanas |
| Revisão da App Store | Dias, mais tempo se for rejeitada |

## É possível aceitar cartões logo no primeiro dia?

Sim, construindo o seu checkout numa plataforma que já possui todas as aprovações. Essa plataforma é o Final. A sua IA cria o checkout no Flow Studio e, quando este solicita um pagamento com cartão, o Final Pay lida com o leitor ou com o Tap to Pay:

- **Leitores e Tap to Pay já aprovados.** O Final Pay aceita cartão, contactless e Tap to Pay em dispositivos suportados. Consulte [como aceitar um pagamento com Tap to Pay](/help/take-a-tap-to-pay-payment) e [como aceitar um pagamento no checkout](/help/take-a-payment).
- **A sua própria IA constrói o sistema.** Conecte o Claude, Cursor ou qualquer cliente MCP através do [servidor MCP do Final](/help/connect-your-own-ai-mcp).
- **Preços numa só linha.** Sem subscrição. Dinheiro é $0. Cartão é 2,49% + $0,10 nos EUA e mundialmente, 1,99% no Canadá e 0,99% na Europa.

A contrapartida honesta: processa através do Final Pay em vez de escolher o seu próprio fornecedor, e a disponibilidade varia por país e dispositivo, conforme listado em [onde o Final Pay está disponível](/help/where-final-pay-is-available). Se os pagamentos forem o seu produto, crie a integração por si próprio utilizando os caminhos acima. Se os pagamentos forem a forma como recebe, as aprovações já estão feitas.

## FAQ

**Q: Como aceito pagamentos com cartão na minha própria aplicação POS?**
A: Por meio do SDK presencial de um provedor de serviços de pagamento: um leitor de cartão certificado, um terminal inteligente conectado à nuvem ou Tap to Pay no celular. Seu aplicativo nunca processa dados brutos do cartão; ele apenas envia um valor e recebe o resultado.

**Q: Um POS baseado na web pode aceitar pagamentos com cartão presencialmente?**
A: Sim, operando um terminal inteligente ligado à nuvem através da API do fornecedor de pagamentos. Uma página web não consegue ler um cartão por contacto sozinha.

**Q: O que exige o Tap to Pay no iPhone?**
A: Um fornecedor de pagamentos suportado, a autorização de Tap to Pay solicitada pelo Titular da Conta de uma conta de desenvolvedor empresarial da Apple, uma autorização de desenvolvimento e depois uma de distribuição após revisão de UX da Apple, e a revisão da App Store. Funciona no iPhone XS ou posterior.

**Q: O Tap to Pay funciona no iPad?**
A: Não. O Tap to Pay no iPhone é exclusivo do iPhone. As aplicações POS para iPad aceitam cartões com um leitor Bluetooth certificado ou um terminal inteligente.

**Q: Qual provedor de pagamentos um POS personalizado deve usar?**
A: O Stripe Terminal é autoatendimento e rápido de implementar para equipes pequenas. O Adyen atende empresas maiores e é mais seletivo no processo de integração. Os seus países, hardware e volume decidem o restante.

**Q: Quanto a Final cobra por pagamentos com cartão?**
A: Sem assinatura. Pagamentos em dinheiro custam $0, e no cartão é 2,49% + $0,10 nos EUA e no mundo todo, 1,99% no Canadá e 0,99% na Europa.