LOSLES - sistema de pagamento automático que usa o próprio valor como identificador da cobrança

Publiquei como projeto pessoal um sistema open source de processamento de pagamentos chamado LOSLES.

A ideia central deste projeto é: "detecção de transferência bancária + uso do próprio valor como se fosse o ID do pedido".
Um pagamento comum por transferência bancária normalmente passa pelo seguinte processo.

• cadastro em uma empresa de PG
• registro empresarial
• análise
• integração de API
• cobrança de taxa de pagamento
• espera pela liquidação

Para desenvolvedores independentes ou projetos pequenos, isso muitas vezes se torna um peso considerável.
Por isso, o projeto nasceu da ideia: "será que dá para identificar um pedido apenas pelo valor?"

Por exemplo, se o preço de um produto for 10.000 won,

Primeiro pedido:
10.000 won

Segundo pedido do mesmo produto dentro de 30 minutos:
9.999 won

Terceiro pedido:
9.998 won

Quarto pedido:
9.997 won
...

Desse modo, cada pedido recebe um valor único.
(Na implementação real, começa em um desconto de 99 won e vai abatendo 98, 97, 96...)
Assim, o servidor consegue identificar a qual pedido corresponde apenas olhando o valor, sem necessidade de inserir um número de pedido separado.

O app Android do LOSLES tem o papel de detectar notificações de recarga do KakaoPay e enviá-las automaticamente para um servidor externo.
Usando a permissão de acesso a notificações do Android (Notification Listener), ele monitora em tempo real as notificações dos apps KakaoTalk e KakaoPay,
e, quando recebe uma notificação contendo o valor da recarga, extrai esse valor e envia uma requisição POST para a URL de servidor configurada.
Usado junto com o servidor web do LOSLES, é possível automatizar todo o processo, desde o depósito do usuário até a conclusão do pagamento.

Fluxo completo

1. o usuário cria um pedido
2. o servidor atribui um valor único
3. o usuário faz a transferência bancária com esse valor (no momento, apenas KakaoPay é suportado)
4. o app Android detecta a notificação de recarga
5. envia o valor para o servidor
6. o servidor faz a correspondência entre valor e pedido
7. conclui automaticamente o pagamento

Ou seja,

O pagamento é identificado não por
"quem enviou",
mas por
"quanto foi enviado".

Observações

O ponto importante é que o LOSLES não é um projeto que pretende substituir um PG oficial.
Em serviços de grande escala, os recursos oferecidos pelas empresas de PG, como reembolso, liquidação, recibos, tratamento de disputas e segurança, continuam sendo importantes.
Ainda assim, no caso de projetos pessoais ou venda de conteúdo digital em pequena escala,
pareceu excessiva a situação de
"ter que começar pelo registro empresarial e ainda passar pela análise de um PG só para poder receber pagamentos",

e este é um projeto experimental para testar uma forma de implementar pagamentos automáticos sem esse processo.
Atualmente está em versão beta e recebendo feedback.
Gostaria especialmente de ouvir opiniões sobre os pontos abaixo.

• problemas do método de identificação baseado em valor
• como tratar pedidos duplicados
• ideias para melhorar a segurança
• opiniões de quem já tem experiência em operação real

Obrigado.

[cichol]

Por exemplo, se em um restaurante tanto o kimchi jjigae quanto o doenjang jjigae custam 10.000 won, quando entra um pedido de 10.000 won não dá para distinguir qual prato foi pedido?

[arcoding]

Mesmo produtos diferentes com o mesmo preço precisam ter o desconto diferenciado em 1 won cada. No uso real, em vez de cadastrar os produtos no servidor do LosLes, ele vê o preço cheio do item e ajusta os descontos de forma diferente por conta própria.

[regentag]

Então vocês precisam continuar vendendo o mesmo produto por preços diferentes?

[arcoding]

Metade está certa e metade está errada: o preço tabelado continua sendo 10.000 won,
mas o primeiro pedido de pagamento dentro de 30 minutos recebe desconto de 99 won,
o segundo pedido de pagamento dentro de 30 minutos recebe desconto de 98 won, e assim por diante. Acho que isso não foi transmitido corretamente no texto.

[zihado]

Se o cliente enviar o valor errado por engano, a correspondência vai falhar.

[arcoding]

Esse é realmente o maior ponto fraco.
Para projetos pequenos, em que dá até para consultar manualmente por DM, tudo bem,
mas em empresas grandes parece melhor usar depois de contratar uma PG.