Paiement Stripe préautorisé dans Adalo

AVERTISSEMENT Ce contenu est resté en ligne à des fins d’apprentissage, mais nous ne recommandons pas Adalo : pendant la période où nous l’avons utilisé, Adalow était peu sécuritaire, incomplet et, de façon générale, presque impossible pour livrer quoi que ce soit.

De plus, la bibliothèque de composants Pragmaflow n’est plus maintenue, après avoir été brisée à répétition par des mises à jour de la plateforme adalo.

‍

Dans ce tutoriel, nous voyons comment intégrer des paiements Stripe préautorisés et conformes dans votre app avec Stripe. ‍

https://stripe.com/docs/payments/checkout

Lien vers la trousse complète de composants Adalo de PragmaFlowhttps://adalo.pragmaflowservers.com/install-component

Inscrivez-vous à make.com ici (lien d’affiliation) :https://www.make.com/en/register?pc=pragmaflow

‍

Transcription de la première partie

L’app ici s’appelle money, pickle, et le but de l’app, c’est que n’importe qui peut aller parler à un professionnel de la finance pour un dollar cinquante la minute, sans payer certains des frais plus élevés qui viennent habituellement avec ça. Vous n’avez pas nécessairement besoin des cent mille qu’il faut pour parler à une de ces personnes.

Alors dans ce cas-ci, ce qu’on voulait faire, c’était préautoriser avant l’appel et ensuite, selon la durée de l’appel, on veut facturer le. Si vous avez déjà travaillé avec ce genre de choses, vous savez que ce n’est pas vraiment facile à faire. Comment on l’a fait? C’est, c’était un peu complexe, mais peut-être pas trop fou maintenant qu’on l’a réglé, et j’espère que ça va pouvoir vous être utile.

Alors le composant qu’on a utilisé, il y en a quelques-uns en fait, non, vous savez, le, le vraiment important ici, c’est notre web view. Et à part ça, ce sont tous des composants Adalo standards. Ça, c’est notre web view. Le better web view de Pragma flow, je suppose que c’est le surnom. Et la raison pour laquelle il est meilleur.

C’est qu’il peut détecter l’URL de la page sur laquelle vous êtes et ensuite poser des actions en fonction de ça. Alors on peut automatiser web flow, web flow. On peut automatiser des expériences web view dans l’app. Et on peut réagir à ce qui se passe dans la web view, ce qui crée une expérience vraiment intégrée et permet en quelque sorte de compléter certains flux de travail difficiles à régler quand l’app Addo elle-même ne peut pas comprendre ce qui se passe sur le web.

OK. Alors comment ça. Si vous regardez cette page, on a un compte à rebours caché; les comptes à rebours cachés sont vraiment utiles pour faire des actions de page quand on utilise une action personnalisée. Il y a un bogue connu dans Adela, et j’espère qu’un de vous va me dire que je suis juste un dinosaure et que ça a été corrigé, mais le bogue, c’était que si vous utilisiez une action personnalisée qui retourne de l’information ou des données, vous ne pouviez pas utiliser ces données dans les actions suivantes.

Cette action personnalisée était une action de page. C’est-à-dire une action qui se déclenche quand on arrive sur la page. Alors ce qu’on fait pour contourner ça, c’est créer un compte à rebours de 0,1 seconde. Je pense qu’on peut mettre zéro, mais quelque chose, je ne sais pas, juste, je suppose que c’est après le chargement de la page ou le composant juste, ça me semble une meilleure idée.

Alors qu’est-ce qui se passe ici? Bon. Il y a quelques affaires. D’abord, on crée le checkout dans. Et, vous savez, je me rends compte que je vais devoir reculer un peu, mais passons à travers ça et vous allez comprendre pourquoi je vais faire un zoom arrière. Alors on a l’ID d’enregistrement d’appel OWO. C’est l’ID de l’enregistrement dans la base de données OWO, pour que quand on fait notre action, qui va se passer dans make.com.

Et ensuite, on veut mettre à jour l’enregistrement. On va savoir quel enregistrement. Alors on va en reparler dans une seconde. Donc on envoie l’enregistrement Al actuel. On envoie le courriel de l’utilisateur et on envoie son nom. Alors qu’est-ce qui se passe quand on fait ça. OK. Si on regarde, ça, c’est le générateur d’instance Stripe.

Mais pourquoi a-t-on même besoin de générer une instance? C’est quoi, tout ça.  sur l’écran suivant, ici, ce qui va se passer, c’est que dans cette web view, on va charger un checkout Stripe. Et donc, en utilisant la web view, on n’est jamais vraiment dans l’app Al; le client ne met jamais ses informations dans l’app Addow.

Ce qui se passe, c’est qu’il les donne directement à Stripe par le processus de checkout de Stripe. Mais ce n’est pas une page statique. Ce n’est pas juste : hé Stripe, laisse-moi aller sur ta page de checkout. En fait, il faut dire : hé Stripe, crée une page de checkout pour cet utilisateur, pour telle raison, pour qu’il puisse payer. Et ça a du sens, parce qu’on veut de la sécurité.

On ne veut pas que les gens arrivent juste au, vous savez, et fassent ce qu’ils veulent et puissent modifier. Alors on commence avec le webhook personnalisé, et vous pouvez voir dans certaines de nos vidéos précédentes comment faire les bases de la configuration d’une action personnalisée avec un webhook. Le webhook est ici. Regardons ça.

Je veux vous montrer, en fait, ce sont les données qu’il attend, ce que je vous ai montré ici avant : l’ID d’enregistrement Adela, le courriel de l’utilisateur et le nom complet de l’utilisateur. Alors on passe par ici maintenant. On a des filtres, et voyons pourquoi, j’ai un peu oublié comment on a configuré ça. Parfait. OK. Alors on a un truc là-dedans qui s’appelle request type.

Et s’il est vide, comme s’il est vide. Non. S’il contient create. Alors regardons d’où ça vient. Quand on va dans notre action personnalisée, ici, on voit qu’on a aussi request type, et c’est codé en dur. La raison pour laquelle c’est codé en dur, c’est que cette requête va toujours être.

Alors on suit cette route et qu’est-ce qui se passe? On crée un client; il faut créer un client Stripe pour qu’ils sachent, vous savez, certaines informations sur la personne. Tout ce qu’on doit fournir, c’est le courriel et le nom. Et ensuite, quand on va ici, on demande une instance de checkout d’intention. Alors c’est quoi, une instance de checkout d’intention?

Une intention, c’est essentiellement une des façons dont Stripe fait la préautorisation. Alors on déclare une intention pour que le client. Dans le futur. Et donc on utilise V1 slash checkout slash sessions, et vous pouvez consulter la documentation de l’API Stripe pour en savoir plus. Ensuite, on doit envoyer ces clés : le type de méthode de paiement, qui dans ce cas-ci est card.

Le mode est setup, et c’est setup parce qu’on configure une intention. Le client : on a l’ID client ici, qu’on a obtenu de l’étape de création du client. C’est la valeur qui a été retournée. Et vous voyez que quand je passe la souris dessus, le numéro 10, c’est un peu difficile à voir, la création du client pulse joyeusement là, ce qui est un bel effet d’interface, et ensuite l’URL de succès.

Alors où est-ce qu’on va aller? Si tout fonctionne, on a cette URL juste ici, et c’est en fait, je crois, ce webhook aussi. Maintenant, l’autre chose, c’est request type égale success. On va parler de ce qui va se passer là dans une seconde. Et ensuite, on a l’URL d’annulation, et c’est s’il n’y a pas de.

Alors on va rediriger vers deux URL différentes, et ce sont toutes les deux ce webhook, mais la seule différence, c’est le paramètre, que vous voyez après le point d’interrogation ici : le paramètre request type égale failed ou égale success. Encore une fois, on va revenir là-dessus. Finalement, avec la réponse qu’on a obtenue ici, qui va inclure l’ID de l’instance.

Ce qu’on fait, c’est que d’abord, on a un ID de pré-autorisation. Alors si le code de statut est 200, c’est-à-dire s’ils sont. Alors on prend le body setup intent, qui est encore une fois retourné, comme vous le voyez à l’étape précédente. Bon. Ensuite, on a pre-auth instance created. Alors ça, c’est encore quelque chose qu’on utilise, vous savez quoi, revenons à ce qui se passe ensuite, parce que je ne pense pas que ça ait encore un bon contexte.

Alors quand on, quand on obtient notre réponse, hein. Et ça va mettre à jour l’enregistrement Addo. Ce qui va se passer, c’est qu’après l’exécution de cette action, on va faire une de deux, deux actions de suivi. Soit on va lier vers pre-op to, qui est la page où on va afficher l’instance de checkout.

Maintenant qu’on a l’ID, ou bien on va lier vers pre-op error, si on a trouvé qu’il y avait une erreur. OK. Alors comment on détermine ça? La façon dont on détermine. C’est parfois. Alors j’ai dû trouver une bonne façon de faire ça avec les contraintes qu’offre Addo. J’aime éviter la possibilité que quelque chose tombe dans deux catégories, ou peut-être une réponse qui ne tombe dans aucune, parce qu’alors ça va bloquer.

On doit, on doit couvrir toute la gamme des possibilités. Alors j’ai décidé d’utiliser un code numérique, parce que de toute façon, c’est souvent comme ça qu’on envoie la réponse. Et donc, ça veut dire que si la réponse du checkout est entre 202 90, on appelle ça un succès. Parfois, ça retourne 2 0 1 S, je dirais. Alors j’ai décidé de couvrir toute la gamme.

Maintenant, si on tombe sur un 3 0 1, c’est une redirection. J’ai pas trop envie de jouer avec ça. Je pense qu’on va appeler ça une erreur. Alors  être un peu conservateur. Et donc on y va. Si, oh oui, en fait, c’est drôle. Alors peut-être que je vais corriger ça pour plus grand que 300. On n’a pas encore eu de 300, mais j’avais laissé une plage où rien ne se passerait, et, et ce serait bizarre.

Alors maintenant, c’est corrigé. Donc si c’est une redirection ou un 400 ou un 500, qui sont des erreurs d’autorisation ou de serveur, alors on va juste aller à l’écran pre-op error. OK. Alors comment on renvoie cette réponse? C’est ce qu’on fait ici. Si on a le code de statut égale 200, parce que c’est essentiellement. Je pourrais probablement aussi reproduire de ce côté-ci les mêmes conditions, et ce serait sûrement sage; je n’ai pas encore eu d’erreur, alors je vais juste laisser ça pour la fluidité du tutoriel.

Mais on pourrait dire si le code de statut est entre, au lieu de égale, mais s’il égale 200, on renvoie l’intention à Adela. Si, ensuite, on doit dire si la pre-op instance est créée, et on utilise ça juste pour comprendre, lors de l’appel, si on peut faire avancer l’utilisateur. Est-ce qu’il a une pre-op instance? C’est notre suivi.

Alors encore une fois, si c’est, si c’est vrai, alors on envoie le, oh oui, désolé. Si c’est un succès, on envoie true. Sinon, false; d’ailleurs, ici, on n’envoie rien. Si c’est. Vous pouvez juste voir comment ça fonctionne en passant la souris sur le si, et quand vous êtes dans make, vous le voyez facilement. Alors l’URL de pré-autorisation actuelle : si ce n’est pas 200, alors on dit failed.

Si c’est 200, alors c’est encore une fois l’URL du body qui vient de la dernière instance, et c’est cette URL qu’on va brancher dans la web view. Bon. Finalement, l’ID client Stripe, qu’on va retourner; on ne va pas stocker les identifiants du client. Mais l’ID client lui-même est quelque chose d’utile à invoquer plus tard.

Bon. Alors ça, c’est la première moitié. Et à la fin, on va retourner l’URL et le code de réponse. Donc, en gros, on y va. C’est la réponse au vrai web. Alors c’est ce qu’Adal va voir comme réponse. À la fin de ce flux, peu importe ce qui s’est passé, à moins que ça ait suivi cette route fad request, il va recevoir URL, qui est l’URL, et il va recevoir le code de statut de la réponse.

Je pense qu’il y a un peu de redondance ici à ce stade, parce que vous nous voyez après avoir fait quelques itérations sur la façon de faire ça, et il faudrait sûrement faire un peu de ménage là-dedans. Alors je ne crois pas que ce soit encore utile, mais ce qui est vraiment cool, c’est que vous pouvez utiliser les Webhooks de make.com pour répondre directement.

Au, au vrai, alors vous pouvez contrôler ce qui est retourné à l’action personnalisée dans Adel, parce que les champs qui s’affichent sont les champs qui sont ici. Alors quand je lance ça et que je fais mon test, je vais voir URL dans la réponse à la fin. OK. Alors ce qu’on va faire, je pense, c’est s’arrêter ici et revenir dans une vidéo, partie deux, sur la façon de terminer ça.

‍

Transcription de la deuxième partie

‍

‍

Bon. Salut tout le monde! On est de retour pour la vidéo deux sur la façon de créer une instance de préautorisation Stripe dans a dial qui n’exigera pas que votre app soit conforme PCI, parce qu’on contourne tout le problème. Alors. Reprenons là où on a laissé la dernière. On a fait ça ici. Une action personnalisée sur notre première page pour créer l’instance de checkout; d’ailleurs, ça ici, c’est juste une animation de chargement, parce que ça prend quelques secondes et c’est bien de faire savoir à l’utilisateur que l’app n’est pas bloquée.

Bon. Alors après avoir créé l’instance avec make.com et avec une action personnalisée. Et qu’on dirige l’utilisateur selon le résultat, on se retrouve sur l’écran de pré-autorisation comme tel. Et donc ce qu’on a ici, c’est une web view, et c’est vraiment simple. Ce qu’elle va faire, c’est afficher l’URL, et elle prend l’URL qui a été retournée par la section précédente.

Et la façon dont elle l’obtient, encore une fois, c’est que ça passe par ce make hello et on le branche, tout simplement. Alors quand on demande le, ça s’appelle le setup intent, hein? Le, l’intention ou l’écran de pré-autorisation, pour qu’on puisse recueillir les informations de carte de crédit et facturer plus tard, on va obtenir une URL. Cette URL va être un peu.

Et on présente ça au client. On l’envoie à cet écran.  pour qu’il puisse entrer ses informations, et strike va les récupérer. Et elles ne se retrouvent jamais dans la base de données d’a download. C’est vraiment utile. Maintenant, si on regarde ce qui se passe vraiment ici, on fait des actions conditionnelles, hein?

Alors dans la dernière, regardons juste ici, dans la dernière section. Ce qu’on faisait, c’est que quand on a demandé l’intention, on a aussi précisé où on allait re. En fait, c’est l’adresse du webhook d’ici. Alors quand un utilisateur a terminé son checkout, il va en gros être redirigé vers un écran qui va en fait à cette URL.

Ce qui se passe ici, c’est qu’à la seconde où il arrive sur cet écran, on va le rediriger. Alors il ne le verrait jamais vraiment, ici, c’est. Donc la première chose qu’on va faire, c’est mettre à jour l’actuel. Et on va dire que, qu’est-ce qu’on fait ici? Hein? On ne change rien? C’est drôle. On pourrait peut-être enlever ça.

Ouais. OK. Je ferai le ménage là-dedans après. Alors on ignore celui-là. Ce qu’on fait, c’est qu’on fait un lien selon le résultat, ce qui a plus de sens. Je me demandais ce qu’on mettait à jour là. Alors on va, selon si cette link URL contient success. La façon dont on fait ça : la link URL vient de l’URL du composant web view.

Alors chaque fois que l’écran change, ce composant va détecter l’URL, puis il va la vérifier par rapport à cette condition. Donc si, à n’importe quel moment, la link URL contient success. On va faire un lien vers call now or schedule. OK. C’est la page suivante. Et je l’utilise juste comme page de routage. Quand vous arrivez dessus, elle vous envoie d’un côté ou de l’autre, selon que vous avez planifié un appel ou que vous voulez faire un appel en direct tout de suite, l’autre.

Alors regardons juste ici, c’est pre off error. Hein? Donc s’il y avait une erreur, si le lien contient fail. Encore une fois, c’est précisé dans notre configuration : on les envoie soit vers un lien où un des paramètres, oh oui. Le mauvais. Alors on les envoie vers un lien où un des paramètres contient success ou sinon contient fail.

Je pense que la plupart d’entre vous qui regardez ça reconnaissez probablement ce format. C’est un paramètre, hein? Ou une requête. Et je pense qu’on appelle ça des paramètres aussi. En gros, quand vous configurez votre action personnalisée, c’est la même chose. Et si on voulait en ajouter un autre, on ajouterait une esperluette, puis un deuxième égale valeur.

Et on pourrait faire ça. Je ne le ferai juste pas parce qu’on n’en a pas.  bon. Alors c’est comme ça qu’on prend le paiement. Maintenant, ce que je veux faire, c’est revenir sur quelque chose d’important, et je m’excuse d’avoir, genre, séparé cette idée sur deux vidéos. Ici. Je précise en fait. Alors ce qu’on fait, c’est qu’on obtient l’information, hein?

On, on obtient le, on crée le client. On obtient l’intention. On pourrait, d’ailleurs, essayer de chercher le client d’abord, ce qui serait un bel ajout. Comme ça, on n’en crée pas un nouveau chaque fois, mais ce n’est pas grave. Et donc, à partir de ça, on met à jour l’enregistrement Dialo. En haut, vous remarquerez que j’ai l’enregistrement d’appel a Dialo.

I. Et ça veut dire que je sais quel enregistrement je mets à jour. Si je m’arrête une seconde, pour la plupart, c’est vraiment difficile à faire dans a dial, parce que pour une raison quelconque, ils ont complètement caché leur enregistrement. I. Et donc c’est vraiment, vraiment difficile. Et le, l’horreur qu’on doit habituellement faire, c’est d’aller chercher tous les enregistrements, puis de filtrer pour celui qui correspond au courriel de l’utilisateur, ou d’en trouver un, genre, créer notre propre ID et chercher une correspondance.

Et, et toute cette affaire est pourrie. Pas juste parce que la performance est terrible, et pas juste parce que demander tous les enregistrements d’une collection, c’est ridicule. Pas juste, ouais, en tout cas, je pourrais passer 20 minutes juste à dire à quel point c’est mauvais. Alors on, on ne veut jamais. Et donc  un jour, quand j’ai fait face à ça, je parlais à Steve.

J’ai dit : Steve, peux-tu juste me faire un composant qui va chercher l’ID d’enregistrement? Et donc on a ça depuis un bout, et c’est pas mal ingénieux : le bouton Addo record ID. Alors comment ça fonctionne? Le truc, c’est que Steve l’a fait d’une façon qui fonctionne vraiment bien, mais qui est aussi très contraignante, et ce que je veux dire, c’est que vous devez vraiment réfléchir : comment est-ce que j’intègre ce truc dans mon flux de travail?

Hein. Les options sont limitées. Genre, on ne peut même pas vraiment changer la taille de la police encore. J’ai dû mettre ce rectangle derrière et tout, mais, mais la réalité, c’est que c’est quand même pas mal génial. Alors voici ce que je fais. Je filtre selon les critères de l’enregistrement que j’essaie de trouver, comme n’importe quelle liste. Je veux un des appels de l’utilisateur connecté, hein?

Parce que je vais chercher l’appel de l’utilisateur actuel, celui qu’il, en gros, je charge l’appel actuel. Et donc, et je, je ne pense pas pouvoir obtenir ça d’une liste parente, mais peut-être que ce serait une façon de le faire aussi. Ce qu’on a ici, c’est pre-auth required égale true. C’est mon critère. Vous n’avez pas nécessairement besoin de savoir pourquoi c’est ça qui m’amène à l’appel actuel, mais c’est le cas.

Alors quand j’ai cet appel actuel et que je clique sur le bouton, je peux, vous savez, c’est un bouton comme un autre, alors je peux faire ce que je veux quand je clique dessus. Une des choses, c’est que je fais un lien vers la page suivante, et l’autre, c’est que je mets à jour l’appel actuel. Et la mise à jour que je fais : j’ai créé un champ qui s’appelle Adela record ID.

Et donc, en gros, juste pour expliquer le flux de façon générale, quand vous arrivez sur cette page, elle crée un nouvel appel pour vous, en supposant que vous, en supposant en gros que vous n’avez pas déjà un objet d’appel actif. Et j’évalue ça avec le champ que je viens de mentionner il y a une seconde, qui est le, le pre-auth required.

Parce que si vous l’avez déjà préautorisé, alors. Alors soit on doit recommencer le flux, soit vous l’avez déjà utilisé pour un appel; encore une fois, ça n’a peut-être pas de sens. Alors suivez-moi ici : l’important, c’est que quand on a la condition où je sais que c’est un nouvel appel, je dois y ajouter un numéro pour pouvoir l’identifier dans le futur.

En configurant ce bouton pour filtrer dessus et en cliquant sur le bouton. Je peux aller mettre à jour l’AALA record ID. Je pense que j’ai pris beaucoup trop de mots pour dire ça. Alors merci de votre patience. J’espère que vous regardez ça en vitesse double.  comment on fait ça? Alors on, vous savez, on branche du magic text, comme n’importe quoi d’autre. On utilise button with record ID, on choisit record ID, et c’est tout.

Alors maintenant, quand j’arrive dans make.com, je connais mon ID d’enregistrement, et ça me simplifie tellement la vie. Je vais m’arrêter ici. Et ensuite, ce qu’on va faire, c’est revenir, on va revenir à la partie trois, où je vais vous montrer comment on récupère l’intention. Et j’espère que je vais savoir de quoi je parle, parce qu’en fait, c’est Phil qui a fait ça.

Alors on va peut-être le faire venir si je n’arrive pas à l’expliquer. Merci d’avoir regardé; aimez, abonnez-vous, et cetera. Restez à l’écoute pour la partie trois.

‍

Transcription de la troisième partie

‍

Bon, tout le monde. Bienvenue à la partie trois. Alors bouclons cette affaire. On travaillait sur l’app money pickle. On a passé à travers les deux premières sections. Petit récapitulatif : on a créé une instance d’intention setup ou de pré-autorisation pour pouvoir y envoyer notre utilisateur. On a envoyé notre utilisateur à. On a fait toutes sortes de, vous savez, demandes d’intention, de mises à jour de l’enregistrement, de vérifications pour savoir si ça a fonctionné, toute l’intégration qui fait que ça a du sens dans l’app Al.

C’étaient donc les parties un et deux; on a parlé dans la partie deux de la façon de trouver l’ID d’enregistrement, pour que. On sache quel enregistrement mettre à jour au lieu de tous les demander et de filtrer, ce qui, je le répète, est tout simplement horrible. Alors ne faites jamais, jamais ça. Ne faites jamais ça. Et vous pouvez trouver le composant record button ID sur notre site.

Je ne l’ai pas mentionné dans la dernière vidéo; je vais le mettre dans les commentaires. Alors maintenant, on a la préautorisation, on a tout ce qu’il nous faut. Le client a fait son appel. On sait que le client a passé 20 minutes en appel, disons, et maintenant on doit lui facturer ça. Alors comment on revient en arrière pour le faire? OK.

En gros, on déclenche juste une action personnalisée quand l’appel est terminé. Voyons si on peut trouver cet écran rapidement. Oui, le voici. On utilise le composant d’appel vidéo garlic IO. Salut à eux. C’est pas mal bon, ça fait vraiment bien son travail. C’est bien. Et ensuite, on a raccrocher.

Action. Alors la seule chose, c’est que c’est un peu difficile de faire des actions selon qui raccroche. Non, vous savez quoi, en le disant à voix haute, c’est niaiseux. Je peux contourner ça. Alors dans l’ensemble, excellent composant, et une des choses qu’on fait, c’est qu’on  on utilise integr make, alors quand on termine l’appel, on utilise en gros make pour traiter le paiement.

Alors c’est comme ça que c’est déclenché. Voyons voir, qu’est-ce qu’on envoie? Heure de début, heure de fin. Comme ça, on connaît le montant, même si les dates et heures d’a Dialo sont envoyées dans un format vraiment bizarre. C’est. Le format epoch Unix, mais basé sur des jours, pas des secondes. Alors il faut le convertir. C’est vraiment fatigant. Alors parfois, c’est plus facile de juste faire le calcul ici.

Alors on envoie le courriel de l’utilisateur, le nom, le setup intent ID, regardez la vidéo un pour en savoir plus. On envoie l’ID client, encore une fois dans la vidéo un, on envoie l’Adela call record ID, parce qu’on veut mettre à jour l’appel. Je viens de le mentionner, mais c’est dans la vidéo deux; on calcule le coût de l’appel ici et. Je me demande si ça va fonctionner, parce qu’on fait le coût selon la durée.

Alors il faudra peut-être vérifier que ce n’est pas brisé. J’ai fait une modification ici récemment pour le corriger.  Alors voyons. Mais ça, c’est l’information qu’on envoie. Ce qui se passe de ce côté-ci, c’est qu’on a le webhook où on la reçoit, et maintenant : est-ce que la durée de l’appel dépasse 10 minutes? Parce que si ce n’est pas le cas, c’est gratuit, alors on arrête ça là.

On, vous savez, passe ce filtre, puis on va faire un appel à l’API Stripe. On fait un appel à V1 setup, intense slash l’ID du setup intent qu’on essaie de récupérer. On l’obtient. Et c’est à peu près tout. Alors ça va retourner de l’information, et on va créer un payment intent au lieu de juste le configurer, ce qu’on a fait avant.

Alors on fait notre calcul pour le coût de l’appel. On précise notre devise, le courriel du destinataire. Pour les types de paiement. Oh, on doit laisser ça vide, cool, l’ID client, que vous avez vu dans la vidéo un, encore une fois, et qui est de toute façon retourné par l’étape précédente. Alors on pourrait dire qu’on n’en a pas du tout besoin dans Dialo. Et si c’est le cas, aussi bien aller l’enlever après; choisir une méthode de paiement existante, payment method ID.

Hein? Alors encore une fois, à partir du payment intent, on a toute cette information. On n’a pas besoin de la remapper, et Alors maintenant, on doit confirmer le payment intent. Et on peut le faire parce qu’on a toute l’information sur le client et sur l’intention. Alors on donne le payment intent ID. On donne l’information qu’on a obtenue du numéro 10.

Et ouais. Alors on y va et ouais, c’est pas mal ça. Oh oui. C’est vrai. Parce qu’une fois que vous confirmez, confirmer, c’est, c’est comme une façon de dire, vous savez, on le prend. Alors voilà. On a confirm et capture. Je dois avouer à ce stade que je vais en fait préciser dans les commentaires la nuance entre confirm et capture, parce que j’ai oublié ce qu’ils.

Mais voici les deux étapes que Phil a dû faire. Alors sans pouvoir les expliquer en détail, mais je suis pas mal sûr que si je m’arrêtais, regardais la documentation et revenais,  ce serait assez facile à expliquer. Alors encore une fois, pour confirmer, on utilise le payment intent ID, on utilise la méthode de paiement, et ensuite, pour le capturer, on utilise le payment intent ID et le montant.

Et ensuite, on. Alors c’est tout, c’est assez simple une fois qu’on a compris. Je veux dire, il y a beaucoup de complexité et, et franchement, la première vidéo a peut-être sauté un peu d’un sujet à l’autre. Alors vous savez, mais merci de votre patience. C’est, au bout du compte, comme ça que vous pouvez utiliser a Dialo et make.com pour créer un. Je ne veux même pas appeler ça de la conformité PCI, parce que ce n’est pas pertinent dans le sens, genre, conformité PCI non pertinente, ou c’est, vous savez, quelque chose qui est entièrement dans le système de Stripe et dont vous n’avez pas à prendre la responsabilité.

Et donc on n’a pas à se soucier d’a download, vous savez, de quoi que ce soit, du comportement ou de la sécurité ou de la conformité de ce côté-là. Une autre chose que vous allez remarquer, encore une fois juste pour être sûr : on n’a jamais envoyé d’informations de carte de crédit. D’Adal à make.com. Tout ça se passe entre make et Stripe.

On n’a jamais rien mis de privé comme ça directement dans Adal, et c’est le but. Et tout passe par notre web view, par le checkout de strip. Et donc, donc c’est ça, tout est magnifique. On utilise ce qui existe déjà. On ne rebâtit rien nous-mêmes. Alors encore une fois, j’espère que ça vous a été utile; si c’est le cas, aimez et abonnez-vous, on va sortir d’autres vidéos, et on va certainement publier des vidéos sur notre outil low-code à venir.

Nom de code FIA pour l’instant, conçu pour être le constructeur low-code qui va vous amener du. Niveau junior jusqu’au niveau développeur et, vous savez, idéalement, grâce à des capacités progressives et, et en retirant en quelque sorte les garde-fous à mesure que vous progressez, en faire une plateforme que tout le monde aime vraiment.

Il va être open source. Il est gratuit. On va offrir de l’hébergement. Ça devrait être une, une expérience vraiment géniale, géniale. Et on a hâte de lancer les toutes premières, premières versions, qui vont encore être horribles, mais , ça va s’améliorer très vite. Alors, alors restez à l’écoute.

Et ouais, je suppose que si ça vous intéresse, abonnez-vous, et vous allez en entendre plus sur ce projet aussi. Oh, merci beaucoup encore d’avoir regardé. C’était Mitch, et à bientôt.

‍