Trabalhei por 5 anos programando cartões de crédito - Tire suas dúvidas

Opa Igor, valeu pelas perguntas, vamos lá:

1. Não, o cartão não possui bateria
2. Sim, o sistema é passivo e precisa de energia externa para funcionar, e só liga quando chega perto de algo com NFC ou quando faz contato com o CHIP.
3. Aí você me pegou, como na etapa que eu trabalhava ele já chegava com o SO instalado, nunca me atentei muito a isso.
4. Os cartões em média possuem de 12k a 144k de memória, o tipo também não sei dizer exatamente, mas sei que possui memória volátil e não volátil, além de espaços ROM, e o quanto é utilizado depende do cartão, por exemplo, cartões com aproximação usam mais memória, cartões múltiplos (que possuem débito e crédito) também vai mais memória, cartões da ELO que são internacionais, vai mais memória ainda (pois eles utilizam aplicações diferentes para transações nacionais e internacionais).

Não muita, a única coisa diferente é que com o celular você consegue autenticar com a sua biometria, ao invés de precisar digitar a senha (mesmo que existam alguns raros cartões que também aceitem biometria)
Mas basicamente quando você cadastra um novo cartão nesses serviços de wallet, o banco "provisiona" um novo cartão pra você, a diferença é que ele fica pronto em segundos, ao invés de ter todo o processo de logística pro cartão chegar até você

É passado bastante coisa, a grande maioria delas as pessoas nem sabem que existe, por exemplo:

• Nome da aplicação do cartão (O texto que aparece na maquina quando você insere o cartão tipo "Selecionado: Mastercard") esse texto pode ser customizado, o banco pode colocar "Selecionado: Crédito Nubank"
• Linguagem preferida pelo cartão (O banco pode escolher qual lingua quer que o terminal fique após ler o cartão, normalmente é passado uma lista tipo pt,en,es, essa lista é em ordem de prioridade)
• Métodos de autenticação do cartão, tipo PIN Online, PIN Offline, assinatura (literalmente quando a pessoa assina o recibo)
• Contador de transações (Um contador interno do cartão que atualiza sempre que há uma tentativa de transação)
• E muitas outras coisas

Agora sobre a parte que eu acho que mais interessa você:

• Número do cartão (inteiro, sem criptografia, sem máscara, sem nada)
• Data de expiração
• Alguns poucos cartões também enviam o nome, mas é bem raro, e na maioria das vezes vem alguma coisa fixa tipo "Visa Paywave" (Quando é feito via CHIP esse campo é sempre enviado com o nome da pessoa mesmo)
• CVV (em um cartão existem até 4 CVVs para cada método de pagamento, tipo crédito e débito, os que aparecem durante uma transação são específicos para aquele método)
  • CVV impresso no cartão (usado pra compras online e nunca é enviado pelo cartão)
  • CVV do CHIP (usado para transações via chip)
  • CVV do NFC (usado para transações via antena)
  • CVV da tarja magnética (usado para transações via tarja magnética que quase não existem mais no Brasil)

E importante deixar claro que a máquina não tem nada de especial para que só ela consiga gerar essas informações, qualquer um com conhecimento de como funciona o fluxo consegue interagir com o cartão e solicitar essas informações (basicamente o que é feito aqui)

Opa, vamo lá:

Sobre o cartão de crédito possuir sistema operacional, basicamente smart cards em geral possuem um sistema operacional, nos casos que eu trabalhei eram 2, ou Java ou Multos, só diferenciava a maneira na qual a aplicação era instalada no cartão, mas o funcionamento na rua é o mesmo, é como se a comunicação entre a maquininha e o cartão fosse via API, para a maquininha tanto faz qual linguagem está rodando no cartão, desde que ele siga o padrão. Não consigo dar tantos detalhes sobre essa parte, porque eu trabalhava na instalação de aplicações e não na parte do sistema operacional, mas basicamente a gente recebia uma documentação de como funcionava a instalação de uma aplicação e seguia.

Sobre evolução do setor é um pouco difícil porque 5 anos nesse meio é muito pouco, pra ter uma ideia, a maioria dos cartões emitidos possuem validade de 5 anos, então é como se eu tivesse trabalhado apenas por uma "geração" de cartões. Mas vou tentar falar um pouco.
Sobre evolução de funcionalidade para o usuário do cartão no fim das contas não tem muita coisa, até porque tudo que se quiser fazer precisa de muita avaliação de segurança, e o pessoal está seguindo mais por uma linha de não precisar mais do cartão, do que de melhorar o cartão em si, mas tem algumas coisas legais que eu vi:

• O início dos cartões com NFC (inclusive é um dos motivos de terem parado de gravar o número em alto relevo, pois isso podia furar a antena)
• O início da escrita com tinta (como o número do cartão era uma coisa extremamente importante, não podiam correr o risco do número ser apagado, por isso usavam o alto relevo, mas agora o número não é tão importante, pois a maioria dos bancos possuem cartão virtual, e a tecnologia avançou muito então difícilmente a tinta sai)
• Voice card (Basicamente um cartão com bluetooth, que conecta no seu celular e te fala o que ta acontecendo no terminal, foi criado para auxiliar cegos a não tomarem golpe, já vi alguns de exemplo funcionando na minha frente, mas nunca um em produção)
• Wearables: Basicamente alguns clientes criaram maneiras diferentes de se ter pagamento por NFC, sem ser no formato de um cartão, mas o funcionamento era exatamente o mesmo, nunca vi ninguém usando, acho que não queriam sair fazendo propaganda do banco no pulso
• Features de segurança:
  • Cartões capazes de realizar cálculos criptográficos que auxiliam na segurança e dificuldade de clonagem
  • Substituição de PIN Offline por PIN Online (basicamente antigamente muitos cartões guardavam internamente o PIN e um contador de tentativas e verificavam offline se a senha estava correta, por isso era necessário ir no ATM alterar a senha, pois o ATM enviava comandos para o cartão trocar a senha, mas isso tinha muitos vetores diferentes de ataque, então agora o cartão nem liga para o PIN, ele só obriga o terminal a pedir, mas toda a validação é feita pelo banco no backend)

Não sou o OP mas vou botar uma curiosidade aqui:

Os cartões antigamente vinham com o número em alto relevo pois há muito tempo atrás, antes das maquininhas eletrônicas, o pagamento era feito manualmente, off-line.

A loja anotava em um papel o número do seu cartão, o preço da compra, e mandava esse papel no final do dia (ou da semana, ou do mês, que seja) para o banco para fazer a cobrança.

Se fosse uma compra muito alta ela poderia na hora fazer uma ligação para seu banco para confirmar que você tem limite. Se não, ela também tem um livro, que era atualizado periodicamente, com uma lista de números de cartões bloqueados, então ela procurava nessa lista seu número do cartão (a data de validade dos cartões servia, entre outras coisas, para essa lista não crescer infinitamente).

Como anotar o número do cartão manualmente (e mais todas as outras etapas manuais de segurança) era um processo trabalhoso e passível de erro, as lojas tinham uma máquina que fazia a cópia dos dados do cartão em alto relevo, usando papel carbono. Um exemplo dessa máquina funcionando: https://www.youtube.com/watch?v=hy-W2PTy1aA

No fim, ela te dava esse papel para você assinar e então ela conferia sua assinatura com aquela que estava preenchida no verso cartão.

Boas perguntas, vamo lá.

O cartão era programado em uma máquina parecida com essa MX6000 é basicamente uma máquina com vários módulos, e esses módulos faziam coisas diferentes, por exemplo: Um módulo escrevia no cartão (numero, nome, etc), um módulo se comunicava com o cartão para ser feita a programação, um módulo escreve na tarja magnética, etc. A equipe que eu trabalhava era responsável por fazer o script de personalização e controle, basicamente o cartão já chegava com sistema operacional instalado, mas sem nenhum dado de cliente, e o nosso script fazia os cálculos criptográficos e inseriam da maneira correta no cartão, junto com as informações únicas dele, como o número, data de validade, nome do portador, etc, após isso era rodado um script de controle, que simulava uma transação, para garantir que o cartão estava OK. A linguagem era uma linguagem de script proprietária da empresa para rodar no sistema dessas máquinas. Mas toda comunicação com o cartão é feito via APDU seguindo a ISO 7816, então na teoria pode ser feita com qualquer linguagem, desde que seja feito os comandos corretos na ordem correta.

Opa Lemuel, essa não é minha área principal, tenho mais experiência com a comunicação entre cartão e terminal em si, por exemplo, qual o processo até que o terminal consiga as informações do cartão, como número e data de validade, como funcionam os processos de validação de PIN, quais são as principais funcionalidades anti clonagem que existem, etc, mas vou tentar te dar alguns insights sobre o que você me perguntou.

1. Complexidade técnica, muitas adquirentes, principalmente fora do país, não possuem APIs REST simples para integração, inclusive muitas usam um padrão antigo chamado ISO 8583, que é horrível de se integrar. Além de não ter camada quase nenhuma de abstração, sendo necessário que você tenha bastante conhecimento na área para saber o que são os campos e quando usar cada um.
2. Gestão de fraude, as principais sub-adquirentes/Payfacs, auxiliam seus usuários com gestão de fraude de uma maneira mais dedicada do que as adquirentes fariam.
3. Algumas sub-adquirentes/Payfacs podem oferecer serviços de failover, que é caso tenha um problema com a adquirente principal, podem enviar as transações para outra adquirente que esteja on-line, além de em alguns casos ter uma lógica interna de enviar a transação para a adquirente que irá cobrar mais barato para determinado tipo de transação (diferentes bandeiras e tipos de cartão possuem taxas diferentes para o processamento, por exemplo, processar uma transação de um cartão black custa mais caro para a adquirente do que um cartão gold)

É basicamente a mesma coisa que decidir entre usar C++ ou python, se fizer em C++ (adquirente) pode ser mais eficiente, mas usando python (sub-adquirente) você tem várias facilidades que simplificam sua vida

Opa Thays, sobre a parte de segurança no Tap on Phone existem várias preocupações adicionais, como garantir que todo número aleatório seja gerado de uma forma extremamente segura, garantir que o celular está integro (não está rootado, com bootloader desbloqueado, em alguns casos valida até mesmo se está com medo desenvolvedor habilitado) garantir que a camera não está ativa durante uma transação, para que o dono do celular não possa gravar seu cartão, etc.
No mundo de pagamento existe um conselho chamado PCI, ele é o responsável por avaliar e criar requisitos de segurança para todos os escopos, e para o Tap on Phone eles criaram um novo padrão chamado MPOC (Mobile Payment On Customer Off-the-shelf device) onde eles publicam uma lista e um manual bem extenso sobre as práticas de segurança que devem ser seguidas para poder ser certificado e poder operar em produção.

Vamo lá:

• Existe um sistema operacional? Sim, inclusive as mais modernas hoje rodam Android, as antigas não tenho certeza de qual é o sistema operacional.
• Usualmente, as aplicações são escritas em quais linguagens? Por se tratar de Android, pode usar qualquer coisa que rode em Android.
• Existe um cartão SIM (4G como nos telefones) dentro da maquininha? É possível o uso delas via Wi-Fi? Existe sim, a maioria das maquininhas possui Wi-Fi, a maioria também tem suporte para cartão SIM e algumas podem se conectar no seu celular por bluetooth com alguma aplicação e utilizar a conexão dele para enviar a transação.
• O protocolo de comunicação entre a maquininha e os servidores segue algum padrão específico? Nada muito diferente, não existe nenhum padrão pra isso, o pessoal só tenta deixar a comunicação o mais rápido possível e o payload o menor possível por se tratar de um hardware que não é super potente.

Essa tu pergunta pro @michel_telo_da_programacao que ele deve ter contatos que possam te ajudar kkkkfff

aí você me complicou kkkkk, disso eu não sei

Isso depende apenas do banco, eles que fazem a validação final de nome, então bancos diferentes podem ter regras diferentes, alguns aceitam só primeiro e último nome, alguns abreviam sobrenome, etc.
A informação do nome fica armazenada no cartão, mas só pode ser acessada via CHIP.

Boa Eduardo, vou tentar responser algumas coisas aqui pra tentar te ajudar, mas essa não é a minha área principal de conhecimento, 3DS é transação digital, meu foco é o que a gente chama de transação de mundo físico, onde involve um cartão e um terminal físicos.

1. 3DS não tem relação nenhuma com o cartão físico, apenas com o emissor (banco), basicamente é ele quem precisa implementar o 3DS e ele quem decide quais produtos dele terão essa segurança. E o gateway de pagamento também precisa ter suporte para o 3DS, e isso pode ser feito em 2 níveis:
   • Data Only: Junto com os dados do cartão é solicitado informações adicionais do usuário, como CPF, endereço, telefone, etc E isso é usado para dar uma confiança a mais na transação, porém caso o banco não aprove, não existe a chance de pedir desafio e a transação é negada.
   • Full: Além do data only, existe a chance do banco pedir o desafio.
2. Até onde eu sei, atualmente o 3DS é a melhor maneira de se ter segurança em uma transação digital, no quesito de garantir que a pessoa que realizou a compra é realmente a dona do cartão, mas isso não é uma solução definitiva para chargebacks porque ainda existem chargebacks fraudulentos por desacordo comercial (pessoa reclamar por dizer que não recebeu o produto, quando na verdade recebeu) e outros motivos. Mas basicamente o 3DS Full funciona como um 2FA, aí depende, você considera o 2FA uma solução definitiva para roubo de credenciais?
3. Aí você me pegou, só trabalhei em parceria com um, mas acredito que a maioria funcione da mesma maneira, porém com efetividades diferentes, justamente pelo que você comentou, de possuir mais transações, possuir pessoas com mais experiência na área, etc. Mas todos precisam cumprir exigências e regulamentos de tratar fraudes, lavagem de dinheiro, etc.
4. Ele possui um sistema operacional porque ele não é tão passivo assim, a princípio pode parecer que ele só retorna informações pré-gravadas nele, mas ele possui um diretório de arquivos, possui arquivos privados que não podem ser lidos (por possuírem chaves criptográficas específicas deste cartão, que caso seja lido, pode levar o cartão a ser clonado), também precisa saber como responder corretamente cada comando e armazenar estados internamente e possui capacidade de realizar criptografias tanto simétricas quanto assimétricas

Espero que tenha conseguido te ajudar com alguma coisa, mas se tiver alguma outra dúvida só mandar

Eu particularmente não acredito tanto nessa informação, se for parar pra pensar no que é necessário para conseguir uma combinação válida de número de cartão + data de expiração + CVV + nome:
Número de cartão possui 16 dígitos, os primeiros 6 são o BIN, então não são aleatórios, o último é um checksum, então também não é aleatório, sobram 9 dígitos aleatórios, muitos deles podem ser de cartões válidos, mas aí para cada um você precisa achar o CVV correto (3 dígitos, equivale a 1000 combinações), data de validade (é só mês e ano, e um cartão tem validade máxima de 5 anos, então sobram 60 combinações) e nome (nem sei como fazer uma conta disso, mas imagino que usariam um ataque de dicionário ao invés de brute force), basicamente pra cada número de cartão que podem encontrar, são mais de 60k de combinações entre CVV e data de expiração, e ainda precisa juntar com os nomes, levando em conta que todo gateway de pagamento deveria ter um rate-limit e todo banco após múltiplas tentativas fracassadas com o mesmo cartão deveria realizar algum tipo de bloqueio, a chance é bem baixa.

Boa tarde, respondi uma pergunta bem parecida, mas vou resumir aqui.
A tecnologia usada é NFC mesmo, não sei de nenhuma sub categoria nesse sentido, pode detalhar um pouco melhor essa dúvida?

Agora sobre os dados lidos, são exatamente iguais aos dados lidos por uma maquininha tradicional que aceite aproximação:

É passado bastante coisa, a grande maioria delas as pessoas nem sabem que existe, por exemplo:

• Nome da aplicação do cartão (O texto que aparece na maquina quando você insere o cartão tipo "Selecionado: Mastercard") esse texto pode ser customizado, o banco pode colocar "Selecionado: Crédito Nubank"
• Linguagem preferida pelo cartão (O banco pode escolher qual lingua quer que o terminal fique após ler o cartão, normalmente é passado uma lista tipo pt,en,es, essa lista é em ordem de prioridade)
• Métodos de autenticação do cartão, tipo PIN Online, PIN Offline, assinatura (literalmente quando a pessoa assina o recibo)
• Contador de transações (Um contador interno do cartão que atualiza sempre que há uma tentativa de transação)
  E muitas outras coisas

Agora sobre a parte que eu acho que mais interessa você:

• Número do cartão (inteiro, sem criptografia, sem máscara, sem nada)
• Data de expiração
• Alguns poucos cartões também enviam o nome, mas é bem raro, e na maioria das vezes vem alguma coisa fixa tipo "Visa Paywave" (Quando é feito via CHIP esse campo é sempre enviado com o nome da pessoa mesmo)
• CVV (em um cartão existem até 4 CVVs para cada método de pagamento, tipo crédito e débito, os que aparecem durante uma transação são específicos para aquele método)
  • CVV impresso no cartão (usado pra compras online e nunca é enviado pelo cartão)
  • CVV do CHIP (usado para transações via chip)
  • CVV do NFC (usado para transações via antena)
  • CVV da tarja magnética (usado para transações via tarja magnética que quase não existem mais no Brasil)

Inclusive você pode baixar e instalar o aplicativo nesse repositório (https://github.com/thiagosprestes/skia-cards, que é um exemplo que demonstra que aproximando o cartão do celular é possível ler esses dados, ele não salva ou envia nenhum dado, na dúvida pode fazer o teste com o wi-fi desligado, ou checar o código que está aberto.

Bacana que você trabalha na área, se tiver alguma outra dúvida pode mandar mensagem aqui na thread ou no linkedin https://www.linkedin.com/in/rbressans/

Opa Caio, falando da Stripe, ela é um Gateway de pagamentos, basicamente ela recebe as informações em um formato que ela define, e com base nisso faz o roteamento das transações para outras adquirentes (Stone, Rede, Cielo, etc), no caso da Stripe é "só" implementar os processode segurança necessários para operar com pagamento (que já é bastante coisa, precisa ter pelo menos o PCI DSS, e possívelmente ter o PCI PIN também, e alguns países pedem coisas a mais também), e aí depende de quais tipos de pagamento você vai ofertar, e do nível de acesso que você vai ter das informações no seu backend, integrar com uma adquirente e deixar com uma cara mais fácil de se integrar para os seus clientes.
A parte pesada mesmo de integração fica com a adquirente, ela que precisa se conectar com cada bandeira (e essa conexão não é apenas para realizar uma transação, também vem a parte de conciliação, pagamento, troca de chaves criptográficas, etc), e seguir os padrões solicitados por cada uma.

Opa Matheus, essa parte não é minha área principal, então posso estar falando alguma besteira, mas até onde eu sei o adquirente trabalha mais na parte de análise do lojista (garantir que um lojista não está passando transações suspeitas para lavagem de dinheiro, etc), e por isso acaba não sendo muito em tempo real, porque o dinheiro só é liberado alguns dias depois, então tem um tempo para conseguir fazer a análise.
Já o Banco faz análise de risco de transação em tempo real, mas não tenho detalhes sobre como é esse processo.

Opa Diego, depende do motivo de estarem armazenando, se for pra fazer apenas acompanhar a quantidade de transações de um cartão específico, ou pra logs, etc, eles só guardam um hash do número do cartão e acompanham com base nisso (mas o hash é feito com base em uma chave criptográfica pra ser mais seguro), se for para fazer transações recorrentes, aí é necessário poder reverter a criptografia, então n pode ser um hash e aí eles armazenam em um banco de dados criptografado.

A parte tecnológica em si não tem nada de especial, é como qualquer outro dado sensível (precisa ser mascarado em logs, encriptado "at rest" e "in transit" e garantir que somente pessoas e serviços altorizadas tenham acesso). Onde fica realmente complicado é que é preciso comprovar em auditoria que você possui tudo isso implementado, aí você precisa passar em uma auditoria de uma empresa autorizada pelo PCI

KKKK pois é, inclusive em algumas versões antigas do netbeans é possível desenvolver Java Card Applets, que seriam aplicações para rodar em cartões, você só precisa de um cartão para instalar essa aplicação (cartões de crédito possuem uma chave para poder instalar novas aplicações, então não dá)