Reçu de transaction par e-mail et historique de transactions sur mon site

Reçu, historique de transactions

a marqué ce sujet comme résolu.

Comment fonctionne les emails auto après l’inscription, le reçu de paiement et l’historique de transaction sur les sites internet.

Merci pour vos réponses je suis nouveau développeur et j’ai un projet de swap crypto mais j’ai pas assez de moyens donc je code moi même.

Salut @H225,

Ouf, c’est assez vague comme question et il y a des tas de façons différentes d’implémenter ces fonctions.

Pour les emails après l’inscription, lorsque tu soumets ton formulaire d’inscription dans ton navigateur, un appel est fait au serveur du site. Là, ton inscription est traitée et soit l’email est envoyé directement soit il existe un procédé asynchrone qui va envoyer ces emails en lisant l’événement de ton inscription quelque part (en base de données, dans un agent de messages, etc.). Comme dit plus haut, il y a plein d’autres façons de faire mais ceci te donne une base.

Quant au reçu de paiement et historique de transactions, il va falloir que tu sois plus précis car c’est vraiment trop vague.

PS: Je ne pense pas que ce post soit dans le bon forum

+1 -0

Comment fonctionne les emails auto après l’inscription, le reçu de paiement et l’historique de transaction sur les sites internet.

H225

Je suppose que tu parles ici implicitement d’une application Web

Le nom technique est email transactionnel. Après que l’utilisateur eut effectué une action, un email est généré en conséquence et le backend applicatif fait alors envoyer l’email via un serveur SMTP tiers. À moins de vouloir gérer soi-même un serveur SMTP, on a généralement recours à un service commercial pour ce faire, par exemple AWS SES. Certains services proposent même une API HTTP à la place d’un accès SMTP, ce qui peut faciliter l’implémentation.

La backend ne peut généralement pas se permettre de bloquer une requête en cours en attendant de finaliser son envoi d’email (qu’il faut considérer non déterministe temporellement). Le pattern traditionnel est alors de découpler cet aspect en ayant recours à une queue de tâches. Mais il nous sera difficile de t’aiguiller d’avantage sans détails techniques supplémentaires.

+1 -0

La backend ne peut généralement pas se permettre de bloquer une requête en cours en attendant de finaliser son envoi d’email (qu’il faut considérer non déterministe temporellement). Le pattern traditionnel est alors de découpler cet aspect en ayant recours à une queue de tâches. Mais il nous sera difficile de t’aiguiller d’avantage sans détails techniques supplémentaires.

Je pense qu’il n’a pas spécialement besoin de s’embêter avec ce genre de détail s’il est nouveau développeur. Et je sais de quoi je parle.

Dernièrement je m’amusais à envoyer des email transactionnels sur un chemin HTTP souvent sollicité. Je me suis rendu compte par moi-même qu’il fallait que je rende le tout asynchrone sans quoi je n’allais pas m’en sortir.

Mais peut-être que dans son cas, ça se justifie ? Non seulement parce qu’il débute, mais ensuite parce qu’il n’aura peut-être pas une centaine d’emails à envoyer à la minute.

Dans le dernier cas, l’idée, c’est d’avoir tout seul le recul suffisant pour se dire « O.K., là ça va pas, j’ai un nouveau problème, comment je le résout ? ».

Pour ma part j’en suis à envoyer un email à chaque fournée alors que d’autres pourraient me dire « autant faire un buffer pour en envoyer 50 d’un coup ». Oui, mais dans mon cas précis, ça ne le justifie pas forcément.

Pour recentrer la discussion, @H225, tu utilises un langage / un framework en particulier ? On peut peut-être t’aiguiller sur les outils que tu peux utiliser.

Je te recommanderai simplement d’éviter Mailjet. Pour bosser avec eux, c’est un enfer.

@geo, je compte acheter un template et le modifier voici le crédit dans la description :

Credits Bootstrap 5 apexcharts bootstrap-vue vue-carousel vue-router vuelidate sass Webpack

Mais je pense qu’il y’a du html et du CSS, aussi du php et du Java script

+0 -0

Credits Bootstrap 5 apexcharts bootstrap-vue vue-carousel vue-router vuelidate sass Webpack

H225

Ça ne se sont que des technologies front. C’est ce qui permet d’avoir une interface visible par le navigateur, mais ça ne concerne pas le back où l’on retrouve les processus serveurs, dont ici la gestion des transactions.

+2 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte