Veux tu dire une indication de paiement ?
Il ya plusieurs options :
duniter://g1:<PUBKEY> : non implémenté encore par les clients, mais avec le temps cette solution devrait s’imposer… car plus générique, et fonctionne sur les téléphones (ouverture de l’App compatible)Je pensais plutôt, à l’intégration du paiement lors d’un processus de commande: permettre le paiement avec Ğ1 sur un site de vente en ligne. J’ai trouvé la doc sur l’api HTTP, je suppose qu’il faut l’utiliser pour bricoler une intégration…
Je pense que ça pourrait faire l’office d’un service à développer oui 
Tu peux t’inspirer du code de Gannonce, qui surveille la blockchain pour détecter les versements sur le crowdfunding.
EDIT : Par exemple, avec un commentaire contenant la référence d’une annonce, c’est plutôt simple à développer à travers un module Duniter : gannonce-pod/src/services/duniter-service.js at master · c-geek/gannonce-pod · GitHub
Le paiement depuis le site ne me parait pas bon, mais plutot une redirection. Ensuite, comme indiqué par @Inso, il faudrait scruter la BlockChain pour savoir si le paiement est effectif.
Une autre solution me vient en tête : faire une redirection, puis que celle-ci retourne le document de transaction lui même, qui ainsi peut etre vérifié dans son intégralité, la disponibilité de ses sources, etc.
Car avant que la transaction ne soit écrite, il y a un délai.
Sinon, les lightning network seraient une autre solution, plus instannée : mise à disposition de fond dans un pool entre le marchant (le site) et le client (l’acheteur), puis à chaque opération d’achat, le document est mis à jour par l’acheteur. La site vendeur peut instannément être sûr que la transaction est OK.
Oui exactement comme aujourd’hui avec les banques classiques : depuis le site du marchand, un bouton « Payer » redirige vers le site de la banque avec un ordre de paiement, puis une fois la transaction réalisée le site “de la banque” (ici non pas une banque, mais le porte-monnaie Cesium) redirige vers le site marchand en fournissant la transaction.
On peut d’ailleurs imaginer que le bouton « Payer » contienne un identifiant de la commande, qui figurerait dans le champ commentaire de la transaction afin de bien la repérer ensuite en blockchain.
De mémoire, la situation que l’on décrit est presque déjà réalisable, puisque l’on peut appeler Cesium avec des champs de transaction pré-remplis, où il ne manque plus que la signature. Par contre, il manque un paramètre “URL de callback” pour renvoyer la transaction au site marchand.
Ah oui ça c’est une excellente idée : on peut avoir un canal Lightning ouvert avec le site. Mais c’est plutôt dans le cadre de sites où l’on fait régulièrement de l’achat / vente, style eBay.
Il y a quelques années j’ai implémenté l’API de Pyaapl en tant que “commercant proposant l’achat par Pyaapl” --donc utilisateur de l’API–.
Je n’ai pas jeté les yeux depuis sur mon bout de code, c’est juste pour signifier que leur API etait simple d’utilisation et très concise et @cgeek décrit bien le déroulement.
Sur le site, dès que l’utilisateur appuyer sur le bouton “Acheter avec paypal”, celui ci etait redirigé vers Paypal,
il indique l’ ID etc…puis confirmation ou non de la transaction.
De mon coté, en callback
j’ai le retour de l’information que l’utilisateur a annulé ou validé la transaction.
Pour Cesium, en gros, ce serait avoir une URL avec un callback… ouais ca devrait aller ! 
hop nouveau ticket
Ça va être énorme … on aura un processus complet pour l’e-commerce en Ğ1 : la monnaie -> le site -> bouton de paiement -> contrôle -> payé -> livré.
Il manquera plus que l’application de paiement back-end à installer chez soi pour le contrôle du paiement.
Pour revenir au processus de paypal et avoir une idée de ce que je devais faire:
$url = “https://api.paypal.com/v1/oauth2/token”; // modulaire pour changer l’url avec la sandbox et faire les test sur l’API
$options = array(CURLOPT_URL => $url,
CURLOPT_POST => 1,
CURLOPT_POSTFIELDS => “grant_type=client_credentials”,
CURLOPT_HEADER => “Accept: application/json”,
CURLOPT_USERPWD => $user.":".$pass,
CURLOPT_HTTPAUTH => CURLAUTH_BASIC,
CURLOPT_RETURNTRANSFER => TRUE,
CURLOPT_PORT => “443”,
);
$url = “https://api.sandbox.paypal.com/v1/payments/payment”; soit
$url = “https://api.paypal.com/v1/payments/payment”;
$str = ‘{“intent”:“sale”,“redirect_urls”:{“return_url”:"’.$return_url.’",“cancel_url”:"’.$cancel_url.’"},’;
$str .= ‘“payer”:{“payment_method”:“paypal”},“transactions”:[{“description”:"’.$desc.’",“amount”:{“total”:"’.$amount.’",“currency”:“EUR”}}]}’;
$options = array(
‘http’ => array(
‘header’ => “Content-Type: application/json\r\nAuthorization: Bearer “.$token.”\r\n”, // token reçu precedement
’method’ => ‘POST’,
‘content’ => $str,
),
);
Si on part sur un noeud Duniter avec un module marchand, alors d’après moi :
Côté paiement, il suffit de connaitre le noeud cible du paiement. C’est ce noeud cible qui pourra se charger de le diffuser à des noeuds membres pour s’assurer que la transaction soit prise en compte.
/dunipay/announce )Côté backend de contrôle, une première approche de specs serait deux types de requêtes d’après moi :
Une requête pour annoncer un paiement ( /dunipay/announce ). En paramètres de la requête :
Une requête pour vérifier le % de validation de la requête ( /dunipay/status ) qui retourne un nombre de blocs requis avant de valider un paiement. Ce nombre de bloc est configurable par le marchand, par défaut il pourrait être de 6. Permet d’afficher dans le site du marchand le temps restant avant d’accepter un paiement
Petit maquettage dans Cesium :
<install_cesium>/api avec par défaut, une page de documentation sur l’API, avec boutons de démo :
<install_cesium>/api/#/v1/payment :il faudrait sans doute ajouter à cette page le choix du noeud. Cela rendrait encore plus souple son usage.
Au niveau code, il n’y aurait aucun stockage (en session, etc.) des paramètres de connexion, qui seraient jettés juste après usage.
vos remarques ?
Ok, nice
Remarque d’ordre dialectique
“Depuis un site vous pouvez…de déclencez l’ouverture d’un page sur l’adresse suivante.”
Je dirais, dans la mesure ou l’on s’adresse a un dev de presenté la chose suivante :
“Utilisation de l’API cesium pay (un truc dans le genre)
Effectuer une requete sur l’url suivante , de type [POST/GET]”
je penche pour requete POST.
Url de la requete :
-"<install_cesium>/api/#/v1/payment :"
Type de requete :
-POST
Parametre :
-amount [obligatoire] [definir “1.0” “1” pensé aux characteres étant définis comme acceptable “le point ou la virgule ou les deux”]
-comment [optionnel]
-name [optionnel / obligatoire ?]
-etc
Return :
à défnir ce que tu retourne a l’utilisateur de l’api, genre
-status : ok / fail
-si fail, raison du fail, probleme sur la couche tcp/ip eventuel/ probleme interne au traitement possible, information manquante (amount pas définis / information obligatoire manquante) / transaction impossible
-hash de la transaction ? ou carrement l’url vers un de vos sites qui affiche les données concernant la blockchain et cet id de block ou est enregistre la transaction directement ?
@Inso a décrit plusieurs aspects a suivre.
Et tu affiche un exemple de requete, un bout de code (eventuellement dans plusieurs langage)
pour l’exemple
apres j’ai pas encore saisi tout ce que cela implique d’autorisation / les clés publiques et leurs gestion vis a vis de duniter/cesium etc, je tatonne…
dans le cas de Cesium, ce ne sera pas possible. C’est une App JS pure, pas de serveur (sauf un frontal web) ;(
Magnifique !
À noter que, je crois bien, les longueurs d’URL sont limitées à 2000 caractères. Ça laisse quand même une bonne marge pour envoyer de l’information même par GET.
Pour l’accès au service c’est pas trop genant.
Pour l’URL de retour, on pourrait éventuellement faire du POST. Je peux ajouter une option pour cela. Genre redirect_type
Sinon @max, habituellement comment tu ouvres la page du service de paiement ? est-ce par : iframe, page avec target="_blank", etc. ou bien dans la meme page web (meme window) ? C’est pour savoir comment appeller la requete de retour : sur la window courante ou une autre…
c’etait dans la meme page il me semble.
la ca me chagrine, je capte pas.
Le processus "classique " c’est que le click d’achat effectue une requete (post / get)
cette requete me renvois directement une reponse.
Qui m’indique le code de ma requete HTTP 200 OK blablabli…
et eventuellement le header “Location” qui lui est intereprete par le navigateur web pour rediriger vers l’url associé a ce champs
voir les headers: HTTP “Location” dans le protocole HTTP
Edit:
Au dela de mes turpitudes,
compatibilité avec le protocole HTTP 2.0 ??
attention la RFC pique les yeux 
Je pense que kimamila imagine plutôt le scénario où le bouton « Payer » sur le site marchand renvoie l’utilisateur vers une nouvelle page (HTTP GET, ce sur quoi insiste kimamila) qui, une fois la transaction signée, génère une requête HTTP GET/POST vers une URL attendue par le serveur.
Exemple :
Mais il s’agit bien d’un processus à 2 requêtes HTTP : l’une pour accéder à l’interface de paiement Cesium, l’autre pour retourner la transaction signée au site marchand qui en fait bien ce qu’il veut, mais qui peut en tout cas considérer qu’il a un chèque entre les mains.
da 
Je pensais plutôt à une intégration directe sur le site marchand sans passer par une redirection http/get. J’ai eu l’occasion de travailler avec la blockchain stellar et la librairie proposée est super bien conçue. Ils ont mis en place une api rest et des librairies pour faciliter l’usage de l’api côté client.
Dans leur système le propriétaire d’un compte a accès à sa clef privée. Du coup, il peut décider de la stocker sur un site de vente en ligne auquel il fait confiance, il est du coup possible d’implémenter un système de paiement intégré au site.
Je n’ai pas la connaissance de cette bibliotheque, et je trouve ca interessant de pouvoir ouvrir cette possibilité.
D’un autre coté, en tant que client lambda qui achete un produit, je prefere que ce soit mon appli “portefeuille” qui traite en direct plutot que de distribué a tout bout de champs ma clé / créer des comptes et tout le tuttim sur les sites marchands.
