Website G1 payment integration

Archives Discussion
1

Hello,

what is the recommended way to integrate G1 payment on a website ?

1 Like
2

Veux tu dire une indication de paiement ?
Il ya plusieurs options :

3

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


4

Je pense que ça pourrait faire l’office d’un service Ă  dĂ©velopper oui :slight_smile:

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

5

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.

6

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.

7

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.

8

Pour Cesium, en gros, ce serait avoir une URL avec un callback
 ouais ca devrait aller ! :wink:
hop nouveau ticket

3 Likes
9

Ç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.

3 Likes
10

Pour revenir au processus de paypal et avoir une idée de ce que je devais faire:

  1. Le site marchand - utilisateur de l’API emet une requete d’identification

$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”,
);

  1. Puis la requete de paiement, en indiquant les adresses de retour , “return_url, cancel_url”

$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,
),
);

  1. gestion du retour des informations dans les urls concernés

11

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.

  • L’URL de paiement (de la forme duniter:// , ou une adresse Cesium) prend en paramĂštre :
    • L’adresse du noeud du marchand.
      • L’adresse de callback de la transaction peut en ĂȘtre automatiquement dĂ©duite ( /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 :

    • L’URL de validation du paiement : AppelĂ© par le backend dĂšs que le paiement est validĂ©
    • L’URL d’annulation/refus du paiement : AppelĂ© par le backend si une double-dĂ©pense est dĂ©tectĂ©e, ou si le rĂ©seau a refusĂ© la transaction en partant sur une autre branche depuis trop longtemps
    • L’identifiant de la transaction (txhash) : Pour chercher la transaction dans la blockchain

  • 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

12

Petit maquettage dans Cesium :

  • une URL dĂ©diĂ©e, plus light au niveau des lib que Cesium;
  • URL d’accĂšs <install_cesium>/api avec par dĂ©faut, une page de documentation sur l’API, avec boutons de dĂ©mo :

image.png919×929 89.6 KB

  • URL de paiement <install_cesium>/api/#/v1/payment :

image.png1241×896 96.1 KB

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 ?

4 Likes
13

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.

  1. Url de la requete :
    -"<install_cesium>/api/#/v1/payment :"

  2. Type de requete :
    -POST

  3. 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

  4. 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


14

dans le cas de Cesium, ce ne sera pas possible. C’est une App JS pure, pas de serveur (sauf un frontal web) ;(

15

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.

1 Like
16

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


17

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 :sunglasses:

18

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.

1 Like
19

da :+1:

20

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.