Por que é importante usar os formulários de pagamento originais

O formulário de pagamento é o ponto onde o usuário digita os dados mais sensíveis, como o número do cartão, o CVC, os logins das carteiras. Se o formulário não for original (site falso, campo de cartão «gravado» no Merchant em vez do formulário de hospedagem do provedor, integração quebrada), você corre o risco de vazamento de dados, falhas bancárias, chargeback-ami e bloqueios. O formulário original é uma página/widget do provedor de pagamento (PSP/banco) que foi certificada de segurança e está conectada em um cenário correto (iFrame/Hosted Fields/Redirett).

O que é o «formulário de pagamento original»

Hospedagem em PSP: campos PAN/CVC/prazo - dentro do iFrame/Hosted Fields do provedor ou em seu domínio (redirect).

Corresponde ao PCI DSS: o merchant não vê ou armazena dados de cartão «crus», e só recebe o token.

Suporta SCA/3-D Secure 2: comprovante de pagamento bancário (push/SMS/biometria).

Protegido por protocolos: TLS rigoroso, HSTS, CSP, proteção contra clickjacking.

Identificável: domínio/certificado correto e UX previsível com adereços de merchant.

Por que isso é crítico (para usuários e negócios)

Para o usuário

Protecção de dados de cartas: A localização e o isolamento dos campos do mapa excluem o «olhar» com merchant e script.

Menos phishing e roubo de conta, o nome do destinatário e 3-DS2 confirmam o pagamento ao seu banco.

Maior probabilidade de pagamento bem-sucedido: integração correta = menos falhas técnicas.

Para Negócios

Complacência e multas menores: conformidade PCI DSS reduz a responsabilidade e o custo da auditoria.

Menos carregeback-ov: 3-DS2 transfere a responsabilidade para o emissor na disputa.

Mais conversão: SCA rápido, Apple/Google Pay, tokens salvos para one-click.

Proteção da marca: falta de «formjeking» (incorporação de script maliciosos) e de vazamentos.

Como deve ser a integração correta

1. Redirect para domínio PSP ou Hosted Fields/iFrame dentro da página do merchant.

2. Os campos do cartão (PAN/CVC/expedy) pertencem tecnicamente ao provedor - o merchant recebe o token.

3. O SCA/3-DS 2 é executado automaticamente para o aplicativo do banco, biometria, código SMS.

4. A segurança de página é HSTS, Conteúdo Security Policy (CSP), X-Frame-Opções, nonce/hashtag de script.

5. UX limpo: fonte/caixa única ou widget PSP de marca, descriptor correto do vendedor.

Quanto mais perigosos são as formas não originais

Formjecking (Magecart): JS maliciosos filmam PAN/CVC em voo.

Phishing/troca de domínio: URL semelhante, logos falsos, «fechadura» por si só não garante nada.

Falta de conformidade PCI: multas, auditorias obrigatórias, bloqueio de equinos.

Falhas e retenção: os emissores cortam as integrações cinzentas, mais do Que not honorário.

Vazamentos KYC: pedido de «foto de cartão de ambos os lados» e passaportes de e-mail - violação grave.

Sinais do formulário original (para o usuário)

Os campos do mapa estão no iFrame incorporado (o cursor e a caixa «dentro» da pequena janela) ou você vai para o domínio do conhecido PSP/banco.

Linha de endereço: HTTPS, certificado de validade, domínio correto sem erro.

3-D Secure/SCA aparece automaticamente (pulo/SMS/biometria do seu banco).

Nenhum pedido para enviar PAN/CVC/foto do cartão para chat/e-mail.

A política de privacidade e os termos de pagamento são abertos e legíveis.

Bandeiras vermelhas (parar imediatamente)

Campos de mapa diretamente no site do merchant sem iFrame/Hosted Fields.

Solicitam o PAN/CVC por e-mail/mensagem ou «foto de cartão de ambos os lados».

O domínio é estranho. shop-brand-verify. net 'em vez do domínio da marca/PSP.

A página puxa recursos não recorrentes (http) na etapa de pagamento ou «discute» o certificado.

Localização quebrada, logos pixelados, órfãos, temporizadores «pague por 2:59».

Folha de cheque para o usuário (1 minuto)

O pagamento é feito através de uma redireção para PSP ou iFrame/Hosted Fields.
HTTPS/certificado são validados, domínio sem substituição.
SCA/3-DS2 funcionou (pulo/SMS/biometria).
Não envio PAN/CVC/foto do cartão para o chat/e-mail.
As políticas de privacidade e contatos estão disponíveis.

Folha de cheque para negócios (integração/segurança)

Uso Hosted Fields/iFrame ou redirecionário PSP; merchant não vê PAN/CVC.
PCI DSS: SAQ A/SAQ A-EP por tipo de integração, toquenização, segmentação de redes.
Os CSP/HSTS/XFO estão incluídos; script externos - por allow-list com hashtag/nonce.
3-DS 2/SCA incluído; fallback на OTP/push; suporte a Wallets (Apple/Google Pay).
Monitoramento de mudanças de frente (SMI, canários), proteção contra formjacking.
Textos nítidos: quem é o equador/PSP, como os dados são tratados, prazos de retorno.
Pentestais regulares e controle de dependências (SCA - Software Composto Analisis).

Problemas típicos e como resolvê-los rapidamente

Sintoma	Razão	Solução
Muito «Declined/Do not honorário»	Integração errada, ausência de 3-DS2	Incluir 3-DS2, verificar regras BIN, descriptor e MCC
Os clientes queixam-se de «frod»	Formjeking/malformação na frente	Incluir CSP/SRI, transferir campos para Hosted Fields, forense e rotação de chaves
Pede foto do mapa por e-mail	Processo de safort inválido	Proibir imediatamente; somente através de um provedor KYC seguro, sem PAN/CVC
O banco frequentemente pede SCA	Sinais de risco/novos dispositivos	Ajustar orquestra, salvar tokens/dispositivos, melhorar o padrão comportamental

FAQ (breve)

Fechadura na linha de endereços = seguro?

Não. É só criptografia. Veja o domínio, o formulário de hospedagem, 3-DS2 e a política.

Por que é melhor que campos no site?

Porque o PAN/CVC vai diretamente para o PSP e não diz respeito ao merchant - menos riscos e exigências PCI.

É possível obter os dados do cartão por telefone/bate-papo?

Não. É uma violação grave do PCI. Use o link de pagamento/fatura com o uniforme de hospedagem.

Se o formulário estiver pendurado sem SCA?

Reinicie, verifique a rede/navegador. Certifique-se de não bloquear as janelas pop-up/script PSP.

Mini-política para a empresa (esqueleto pronto)

1. Apenas Hosted Fields/Redirect para PAN/CVC.

2. 3-DS 2/SCA é obrigatório para cartões; conexão Apple/Google Pay.

3. CSP/HSTS/XFO/SRI + domínios rígidos.

4. Monitorização de frente e alertas para substituição de script.

5. SAQ/auditoria PCI anualmente; Pentestes agendados.

6. Zapport nunca pede PAN/CVC/foto do mapa; apenas canais KYC protegidos.

A forma original de pagamento não é estética, mas segurança e legalidade. Campos de hospedagem, tocenização e SCA protegem o portador do cartão, aumentam a conversão e removem grande parte dos riscos do negócio. O usuário deve verificar domínio, formulário e SCA; ao negócio, usar apenas integrações certificadas com proteção de frente rígida. Seguindo estas regras, você fecha 90% dos cenários de fuga de dados e de falha de pagamento.