Paiement G1 automatique vente en ligne

Bonjour,

notre association aimerait proposer un support (: tutoriel vidéo auto-massage) payable en june et surtout accessible automatiquement après paiement.

Après avoir pris connaissance des logiciels existants dans l’écosystème, il semblerait que ça s’approche de https://g1sms.fr/fr … sauf que nous souhaiterions proposer un module de paiement tel qu’il en existe pour les paiement CB en ligne, adapté au paiement june.

Merci de toutes les infirmations que vous pourriez nous transmettre à ce sujet ?!

S’il un tel module n’existait pas encore, nous serions prêt à coopérer avec un développeur pour le rendre accessible.

Excellente journée et au plaisir,

(PS : aux dernières nouvelles, voilà ce que nous avons trouvé sur le cryptomarché :
=> https://bit.ly/2JapWWw)

Bonjour,

Ces modules de paiement font appel à un tiers de confiance (banque, établissement financier) qui gère la monnaie. Un tel tiers n’existe pas encore pour Ğ1, et est contraire aux principes de base de sécurité d’une monnaie Blockchain.

Donc il ne peut pas y avoir un tel module de paiement avec paiement « sur internet » pour le moment en Ğ1, sauf si vous tenez à créer l’entreprise kivabien.

Un paiement sécurisé pour Ğ1 se fait par un client local. Le projet Ğ1Lien pourrait être présenté aux RML15 si elles ont lieu, et c’est le plus pertinent pour votre besoin.

Votre site pourrait générer à la volée un lien contenant les informations nécessaires à la transaction, qui provoquerait l’ouverture du client local (Silkaj, Sakia, Césium) de l’utilisateurice pour effectuer la signature de la transaction en toute sécurité.

Evidemment, il faudra pour cela que les clients implémentent la reconnaissance des Ğ1Liens.

2 J'aimes

Qui dit ça ? Quelles contre-indications vois-tu au tiers de confiance ?


Un client qui automatise les transactions sur un serveur que l’on contrôle est aussi une solution.
Mais, ça n’est pas adapté aux personnes qui ne savent ou ne veulent pas contrôler et maitriser un serveur. Dans le cas contraire, une solution avec tiers de confiance serait la voie à suivre, bien que ça n’est pas près de voir le jour.

Oups, j’ai pas bien compris la question initiale. C’est pas l’automatisation de transactions régulières. Il s’agit de l’automatisation du paiement en ligne sur un site web.

Moi :wink:

Et aussi le grand-père :

Commerce on the Internet has come to rely almost exclusively on financial institutions serving astrusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model

Ce genre de cas, qui a des conséquences bien moins graves si on est sur de la gestion distribuée.

1 J'aime

ah, visiblement ça ne semble pas techniquement simple et à priori déontologiquement inacceptable ?!
par contre, malgré les explications apportées (merci au passage !), je ne comprends pas pourquoi un outil d’échange comme la June ne permettrais pas d’échanger des supports dématérialisés (: vidéos, documents,…) comme un paiement CB ?

Par exemle, qu’est-ce qui empêcherait d’acheter de la musique en ligne avec la June :

  • n° CB = Clé publique June
  • détenteur de la carte Nom, Prénom = Pseudo ou Nom, Prénom du compte June
  • sécurcode au dos de la carte (3 chiffres) = un code généré par sms ou…

Quant au modèle économique que cela génère, j’ai par comparaison un marteau dans ma caisse à outils, très pratique quand je veux clouer des planches… effectivement, il peut aussi être utilisé pour blesser autrui (: en ce qui me concerne, cette dernière utilisation ne fait pas partie de mes valeurs !)

Soit dit au passage, j’ai une amie qui es très emballée par la June, sachant qu’elle va être confrontée à la même situation de vente de musiques et de places de concerts, qu’elle a majoritairement automatisée afin de dégager plus de temps pour elle et son travail… si non, elle ne s’en sors pas !!! => https://www.julie-marie.net/)

Cordialement,

On peut recevoir un payement et déclencher une action… en surveillant les transactions reçues sur un portefeuille (comme c’est fait ici pour fabriquer des ZenTag)

Ton site Web, au moment de la vente « online », mémorise la commande de l’acheteur.
Lui demande d’installer https://Cesium.app
Puis flasher le QRCode du portefeuille de ton site. Où envoyer le payment avec le bon MONTANT et le CODE en commentaire…

Une fois la bonne TX entrante reçue tu peux déclencher l’expédition

et voila

:hear_with_hearing_aid:

[edit]

Ah, ce n’est pas ce que j’ai écrit. J’ai uniquement écrit que le paiement ne doit pas se faire en ligne via un tiers de confiance, autant que possible.

Quant à identifier la personne qui a payé une place par sa clef publique ou par un code échangé par un autre biais, c’est tout à fait faisable, oui. Par exemple, votre site peut générer une transaction avec la référence d’achat en commentaire, et pourrait vérifier les paiements ainsi.

Un module de paiement ferait, ensuite, le lien entre les références entrées en commentaire et l’achat effectué. Mais ce module n’est pas encore codé.

Non, simplement déconseillé. Un tiers de confiance offre un point faible pour le système de paiement, mais peut faciliter les choses (paiement instantané, garanties, etc…). Il faut juste ne pas mettre tous ses oeufs dans le même panier.

OK, je vous remercie de vos retours… laisser maturer un peu l’histoire, en commençant déjà par proposer le support dans gchange, voir ce que ça donne !

A la prochaine :relaxed: :pray:

OK, merci Fédéric…

comment configurer au préalable le montant automatiquement et le commentaire de validation de paiement ?

Il faut expliquer comment faire le payement avec son cesium.app et renseigner le montant et le commentaire.

Sinon, il faut utiliser une URL comme ça https://g1.duniter.fr/api/#/v1/payment/8qs69HriAdytcCLzvQGJ15XBwpjAVFx8JoVM2ahue1y7?amount=3.14&comment=G1sms
Mais le service va fermer je crois… hein?

Ah Ok, le service va fermer, signifie que l’application (: en ligne ?) va disparaitre (: du fait de la disparition de Cesium en ligne ?)… est-ce que j’ai bien compris ??

En fait le service passe en lecture seule. Plus de connexion possible, donc plus d’opérations nécessitant des identifiants.

Ah, et au niveau sécurisation (: compte, transactions,…) ça dit quoi ?

Le service Césium-web ferme justement pour éviter que les utilisateurs prennent la mauvaise habitude de se connecter sur une instance sur le web, que nous ne pouvons pas sécuriser suffisamment pour le moment.

Le fermeture des instances Cesium-web va dans le sens de la sécurité des transactions.

Je crois que votre question a besoin d’être précisée. Sécurisation de quoi, et dans quel cadre ?

comptes : il n’y a pas de stockage de « comptes » comme sur un site web classique, nulle part. Les trousseaux cryptographiques sont générés à chaque connexion des utilisateurices.

transactions : irréversibles après 100 blocs sauf consensus des noeuds calculants.

je faisais référence au message de « Vit », à propos de la lecture seule…

Pa railleurs, pour le moment nous procédons aux transactions manuellement par gchange et Cesium, ce qui fonctionne à merveille… c’est juste en prévision de l’augmentation du volume des demandes, qui gagnerait en qualité de satisfaction de délivrer automatiquement le support dès que la personne fait le versement (: c’est sympa de ne pas trop attendre quand on acquière quelque chose, d’autant plus quand c’est dématérialisé ?!)

Quoi qu’il en soit, un grand merci aux contributeurs et trices de tout ceci, ça a le mérite d’être clair, simple, efficace et de fonctionner… bravo !

Tu pourrais nous montrer ce que tu as fait, s’il te plait, ça enrichirait les exemples de « User Case »

je ne suis pas sûr d’avoir compris la question… cependant, au niveau de Duniter, Césium,… je ne suis qu’un usager qui trouve extra l’aboutissement d’une telle plateforme (je ne développe pas… et ne fait qu’échanger !)
=> à titre d’exemple d’usage : https://bit.ly/3bnqdSe
c’est d’ailleurs cette offre que nous aimerions livrer automatiquement après paiement G1