Construindo um gateway de pagamento on-line completo como o Paypal [fechado]

Portanto, esta pergunta não é sobre a integração de um gateway de pagamento existente no meu site. Esta é mais uma questão de arquitetura.

Eu quero construir um sistema semelhante ao Paypal. Agora entendo que o Paypal oferece muitos recursos sob o teto e não posso implementar todos eles de uma só vez. Quero implementar a funcionalidade principal do Paypal e outros serviços desse tipo.

Portanto, minha pergunta é (em vez disso é a discussão) sobre como alguém poderia construir tal sistema. Alguns pontos para discutir:

1. Lidar com pagamentos através de bancos existentes. Suponho que precisaria acessar protocolos bancários locais para conseguir isso.
2. Permitir que os usuários armazenem e processem seus pagamentos com segurança
3. Como o Paypal lida com as transações?

Pensamentos?

O que você está falando é se tornar um provedor de serviços de pagamento. Estive lá e fiz aquilo. Era muito mais fácil há 10 anos do que é agora, mas se você tem uma quantidade fenomenal de tempo, dinheiro e paciência disponível, ainda é possível .

Você precisará entrar em contato com um banco adquirente. Você não disse em que região do mundo está, mas com isso não quero dizer uma agência bancária local. Cada banco principal geralmente possui um braço de aquisição de cartão separado. Portanto, aqui no Reino Unido, temos (por exemplo) o banco Natwest , que usa o Streamline (ou Worldpay) como seu braço adquirente. No total, apesar de termos dezenas de grandes bancos, todos eles acabam usando um dos cinco ou mais adquirentes de cartões.

Felizmente, todos os adquirentes de cartões do Reino Unido usam um protocolo padrão para comunicação de solicitações de autorização e liquidação no final do dia. Você encontrará peculiaridades menores, nas quais alguns bancos adquirentes suportam alguns recursos e possuem sintaxe ligeiramente diferente, mas as diferenças são bastante pequenas. Os padrões do Reino Unido são publicados pela Association for Payment Clearing Services (APACS) (que agora é conhecida como UKPA). Os padrões ainda são comumente referidos como APACS 30 (autorização) e APACS 29 (liquidação), mas agora são formalmente conhecidos como APACS 70 (livros 1 a 7).

Embora o padrão APACS seja amplamente suportado em todo o Reino Unido (Amex e Discover também aceitam mensagens neste formato), ele não é usado em outros países - cada país possui o seu próprio - por exemplo: Carte Bancaire na França, CartaSi na Itália, Sistema 4B no Espanha, Dankort na Dinamarca etc. Está em andamento um esforço para unificar os protocolos em toda a Europa - veja EPAS.org

A comunicação com o banco adquirente pode ser feita de várias maneiras. Novamente, porém, isso dependerá da sua região. No Reino Unido (e na maior parte da Europa), temos um gateway de comunicação que fornece conectividade a todos os principais adquirentes, eles são chamados TNS e existem dezenas de maneiras de se comunicar através deles para o banco adquirente, a partir de modems dial-up de 9600 bauds, ISDN, HTTPS, VPN ou linha dedicada. Por fim, a solicitação de autorização será convertida para o protocolo X25, que é o protocolo usado por esses bancos adquirentes ao se comunicarem.

Em resumo, então: tudo depende da sua região.

• Entre em contato com um grande banco e tente acessar o ramo de aquisição de cartões.
• Explique que você está configurando como um provedor de serviços de pagamento e solicite detalhes no formato de comunicação para solicitações de autorização e arquivos de liquidação no final do dia
• Configure uma conta de comerciante de teste, desenvolva um software de autenticação / liquidação e passe pelo processo de credenciamento. A maioria dos adquirentes ajuda você nesse processo gratuitamente, mas quando você deseja se registrar como um PSP credenciado, alguns pedem uma taxa.
• você também precisará cumprir alguns regulamentos, por exemplo, pode ser necessário registrar-se como instituição de pagamento

Depois de registrado e credenciado, você poderá aceitar clientes e configurar contas de comerciante em nome do banco / s em que está credenciado (tendo em mente que cada adquirente geralmente oferece suporte a vários bancos). Enxágue e repita com outros adquirentes conforme achar necessário.

Além disso, você tem muitos outros problemas, principalmente no PCI-DSS. Esse é outro tópico e já existem algumas perguntas e respostas neste site. Como eu disse, é um empreendimento fenomenal - provavelmente um projeto de vários anos, mesmo para uma equipe de tamanho razoável, mas certamente é possível.

Grande tarefa, é provável que você não deva reinventar a roda usando uma roda existente (como paypal).

No entanto, se você insistir em continuar. Comece pequeno, você pode usar um recurso de processamento de cartão de crédito (Moneris, Authorize.NET) para processar cartões de crédito. A maioria dos provedores tem uma API que você pode usar. Lembre-se de que talvez você precise usar provedores diferentes, dependendo do tipo de cartão (Discover, Visa, Amex, Mastercard) e do país (EUA, Canadá, Reino Unido). Portanto, crie-o para que você possa se comunicar com várias APIs de processamento de cartão de crédito.

A segurança é essencial se você estiver armazenando cartões de crédito e detalhes de pagamento. Verifique se você está criptografando as coisas corretamente.

Mais uma vez, não reinvente a roda. É melhor usar um provedor existente e concentrar sua atenção no desenvolvimento na solução de um problema que não pode ser adquirido com facilidade.