Réponse courte. Le prix de référence est en dinars, sur le catalogue. Le client voit le prix dans sa devise, calculé avec un taux de référence et une règle d'arrondi écrite, figé au moment de la commande et conservé sur la fiche : le montant débité est celui affiché. Deux encaissements : un prestataire local pour CIB et Edahabia en dinars, et un prestataire étranger, rattaché à une entité hors d'Algérie, pour les cartes internationales en euros, parce que les grands prestataires étrangers n'ouvrent pas de compte à une entreprise algérienne aujourd'hui. Les banques européennes exigent une authentification forte du porteur pour la plupart des paiements en ligne, et la page de paiement la gère. Les deux prestataires envoient un webhook vers un seul traitement, et il n'y a qu'une commande et une machine à états ; le canal est un champ. Le rapprochement se fait par canal, dans sa devise, contre le versement du prestataire ; l'équivalent en dinars au taux figé sert au chiffre d'affaires. Un remboursement repart par le canal d'origine, au centime. Six semaines, dont la première sans code et avec le comptable.
Ce guide s'adresse au fondateur installé en France dont les clients sont des deux côtés, cours en ligne, soins, réservations, cadeaux livrés à Alger, au gérant en Algérie dont une partie des clients paie depuis l'étranger, et au responsable qui rapproche chaque mois un versement en euros et un versement en dinars sans savoir lequel manque. Il ne redit pas comment on intègre le paiement local, la page, le webhook et les états de commande, décrit dans le guide sur le paiement en ligne ; il décrit ce qui s'ajoute quand une partie des clients paie dans une autre devise, et il prolonge notre page sur l'ingénierie logicielle.
Ce que voit le client, en six étapes
Ce que vit le client, qu'il soit à Paris ou à Alger, et le moment où l'application ne fait plus confiance à l'écran.
Voir le prix dans sa devise : la devise vient de la carte qu'il va utiliser ou de son choix explicite, jamais d'une détection approximative ; le taux est figé à cet instant. Choisir le moyen : carte internationale, ou CIB et Edahabia ; le canal en découle, et le client ne voit qu'une page. Payer sur la page du prestataire : le montant et la devise sont fixés côté serveur avant la redirection, et la banque européenne peut demander une authentification forte ; c'est l'étape accentuée.
Revenir sur l'application : le retour du navigateur n'est pas une preuve, on attend le webhook, selon la règle posée dans le guide sur le paiement en ligne. Recevoir la confirmation dans sa devise, avec le reçu, par le canal décrit dans le guide sur les notifications. Être remboursé si besoin par le même canal, dans la même devise, au même montant, sans que le taux du jour intervienne.
Encaisser en deux devises, en cinq couches
La commande unique est la couche qui évite la double comptabilité ; la deuxième couche porte la condition que ce guide ne peut pas lever à votre place.
Prix et devises. Un prix catalogue en dinars ; un prix affiché dans la devise du client, calculé avec un taux de référence choisi avec le comptable, arrondi selon une règle écrite, figé à la commande et conservé sur la fiche. Les prix viennent du même moteur que le guide sur le devis et la facture. Deux encaissements. Un prestataire local pour les cartes algériennes en dinars ; un prestataire étranger pour les cartes internationales en euros, rattaché à une entité hors d'Algérie : les prestataires étrangers publient la liste des pays où un compte peut être ouvert, et l'Algérie n'y figure pas aujourd'hui, la France oui. Commande unique. Une fiche, une machine à états, un seul traitement de webhook pour les deux prestataires : signature vérifiée, identifiant de paiement idempotent, montant et devise comparés à ceux de la commande, un seul passage à « payée » ; le canal est un champ, pas une autre commande.
Rapprochement. Par canal et par devise, contre le versement du prestataire : frais attendus, net attendu, date de versement ; l'équivalent en dinars au taux figé sert au chiffre d'affaires, jamais au rapprochement ; deux totaux, jamais additionnés. Remboursements et litiges. Remboursement par le canal d'origine dans la devise d'origine ; contestations de paiement traitées avec les preuves de la commande, confirmation, livraison, échanges, selon le guide sur le service après-vente ; avoir lié à la commande.
Deux clients, deux chemins, une seule commande
La figure suit deux clients qui achètent la même chose : l'un à Paris, l'autre à Alger. Deux chemins, une fiche.
Le client à Paris voit 160 euros, calculés depuis 24 000 dinars au taux de référence figé à 10 h 02 ; il paie sur la page du prestataire étranger, sa banque exige une authentification forte, et le prestataire envoie un webhook signé avec l'identifiant du paiement et les frais. Le client à Alger voit 24 000 dinars, sans conversion, et paie sur la page du prestataire local, dont le retour navigateur est ignoré et le webhook attendu. Les deux webhooks arrivent sur le même traitement : signature, identifiant idempotent, montant et devise comparés à la commande, et la fiche passe à « payée », une seule fois, quel que soit le canal.
La fiche porte le prix catalogue, le prix affiché, le taux figé avec son heure, le canal, les frais du prestataire et l'état ; le remboursement repartira par le même canal. Ce que la figure ne tranche pas, et que ce guide ne tranche pas non plus : quelle entité encaisse les euros, comment les fonds circulent entre les deux pays et ce que dit le régime des changes ; ce sont des questions à régler avec le comptable et le conseil avant la première semaine. Montants, frais et taux sont un exemple construit.
«Le client ne choisit pas une devise : il voit le prix dans la sienne, calculé depuis le prix catalogue en dinars avec un taux figé au moment de la commande et conservé sur la fiche.»
Le rapprochement du 10 novembre, en deux devises
La figure montre ce que le serveur attend de chaque prestataire, et ce qui est arrivé. Deux canaux, deux totaux, et une ligne qui ne colle pas.
Chaque commande porte son canal, le montant payé par le client dans sa devise, le taux figé, l'équivalent en dinars, les frais et le net attendus selon le barème du prestataire, et la date de versement attendue. Les commandes en euros attendent le versement du 17 ; les commandes en dinars ont reçu celui du 12, et une ligne présente un écart, marqué pour être expliqué, pas additionné. Le remboursement de 60 euros repart par le canal d'origine, dans la devise d'origine, et le taux ne bouge pas : le client récupère exactement ce qu'il a payé.
Le gérant lit un total par canal, dans sa devise, et ne les additionne jamais ; l'équivalent en dinars au taux figé sert au chiffre d'affaires sur le tableau de bord, selon le guide sur le tableau de bord temps réel, et à l'export vers le cabinet, selon le guide sur l'intégration. L'import des versements et le rapprochement tournent en tâche de nuit, selon le guide sur les tâches en arrière-plan. Les montants de la figure sont un exemple construit ; les barèmes de frais et les délais de versement sont ceux de chaque prestataire.
«Chaque canal se rapproche dans sa devise, contre le versement de son prestataire ; l'équivalent en dinars sert au chiffre d'affaires et jamais au rapprochement.»
Six situations réelles, et ce que l'application fait
Les six situations qu'on retrouve dans presque toutes les entreprises qui vendent des deux côtés de la mer, et la construction qui les règle.
Les trois premières lignes se règlent par la page de paiement en euros, le taux figé à la commande et le parcours avec authentification forte : le client paie en une minute, le montant débité est celui affiché, et une carte refusée a un message et une relance. Les trois suivantes se règlent par la commande unique, le rapprochement par canal et le remboursement par le même chemin : un paiement ne crée jamais deux commandes, un versement qui ne colle pas se lit ligne par ligne, et un remboursement ne dépend pas d'un virement manuel. Aucune ne se règle par un cousin plus réactif sur WhatsApp.
Vu ailleurs : où les prestataires étrangers ouvrent des comptes, l'authentification forte, et ce qui se transpose
Trois faits se transposent tels quels. Où un compte peut être ouvert : les prestataires de paiement étrangers publient la liste des pays où une entreprise peut créer un compte ; chez le plus connu d'entre eux, la France y figure et l'Algérie non, à la date où nous écrivons ; ce qui se transpose, c'est que l'encaissement en euros passe par une entité dans un pays de la liste, et que c'est une décision d'entreprise, pas de code. L'authentification forte : en Europe, depuis septembre 2019, les banques exigent pour la plupart des paiements par carte en ligne une authentification du porteur, le plus souvent par 3-D Secure ; un parcours qui ne la gère pas voit ses paiements refusés ; ce qui se transpose, c'est une page de paiement qui la déclenche quand la banque la demande, et un test avec les cartes de test du prestataire. Le webhook comme seule preuve, déjà posé pour le paiement local ; ce qui se transpose, c'est un seul traitement pour les deux prestataires.
Ce que ces faits ne décident pas pour vous : l'entité, le taux de référence et sa source, qui paie les frais, et les règles de remboursement ; la première semaine du projet y répond, avec le comptable, et c'est le gérant qui signe.
Les règles d'un encaissement en deux devises qui tient
Six règles, écrites la première semaine. Le prix de référence est en dinars, et le prix affiché est calculé, jamais tapé. Le taux est figé à la commande et conservé sur la fiche. Le montant et la devise sont fixés côté serveur avant la redirection. Une seule commande, le canal est un champ, un seul traitement de webhook. Le rapprochement se fait par canal et par devise, jamais additionnés. Le remboursement repart par le canal d'origine, dans la devise d'origine, au centime.
Et une règle de méthode : la question de l'entité qui encaisse et du régime des changes se règle avec le comptable et le conseil avant d'écrire une ligne ; l'application est construite pour le montage retenu, pas l'inverse. Où tournent les serveurs et où vivent les données est une décision à part, décrite dans le guide sur l'hébergement.
Six entreprises, et le chemin d'encaissement qui manquait
Six situations composées à partir de projets que nous rencontrons ; les noms sont génériques et les chiffres sont des exemples.
- Une plateforme de cours en ligne, élèves à Alger, parents à Paris. Les parents payaient par virement et le cours commençait avant que le paiement soit identifié. La construction : prix en euros figé à l'inscription, page du prestataire étranger sur l'entité française, webhook, cours débloqué à la seconde ; le modèle est décrit dans le guide sur le soutien scolaire.
- Un cabinet dentaire à Alger, patients de la diaspora l'été. L'acompte du plan de traitement arrivait par Western Union avec une photo du reçu. La construction : acompte en euros payé depuis la France, taux figé, acompte rattaché au plan de traitement ; le cas est décrit dans le guide sur le cabinet dentaire.
- Une boutique de cadeaux livrés à Alger, commandes depuis la France. Le prix en euros était recalculé chaque matin et les clients contestaient les écarts. La construction : taux figé à la commande, montant débité égal au montant affiché, remboursement par le même canal.
- Un hôtel à Oran, réservations depuis la France et paiements sur place. Deux tableurs, un en euros, un en dinars, jamais rapprochés. La construction : une commande par réservation, canal sur la fiche, rapprochement par canal ; le modèle est décrit dans le guide sur la réservation d'hôtels.
- Un fondateur à Marseille, boutique en ligne à Alger. Il avait créé l'entité en France pour encaisser les euros et n'avait pas de vue commune. La construction : une application, deux prestataires, un tableau de bord avec deux totaux dans leur devise ; la gestion à distance suit le guide sur le commerce depuis la France.
- Une startup lancée depuis la France, clients en Algérie. Elle facturait tout en euros et perdait les clients locaux sans carte internationale. La construction : prix catalogue en dinars, CIB et Edahabia en local, euros pour la diaspora ; le calendrier de lancement suit le guide sur la startup lancée depuis la France.
Le calendrier 2027
Six semaines pour une application qui encaisse déjà en dinars ; la première semaine se passe sans code, avec le comptable.
Semaine 1, décisions : l'entité qui encaisse les euros, les prestataires, le taux de référence et sa source, la règle d'arrondi, qui paie les frais, les règles de remboursement ; signées avec le comptable et le conseil. Semaine 2, prix et devises : prix catalogue en dinars, prix affiché dans la devise du client, taux figé à la commande et conservé, affichage et reçus dans les deux langues, selon le guide sur l'application bilingue. Semaine 3, encaissement en euros : page du prestataire étranger, authentification forte, webhook signé, idempotence, tests avec les cartes de test du prestataire.
Semaine 4, commande unique : un traitement de webhook pour les deux prestataires, canal sur la fiche, machine à états, confirmation au client dans sa devise. Semaine 5, rapprochement : frais et net attendus par canal, import des versements, écarts par ligne, remboursements par canal d'origine. Semaine 6, mesure : part des commandes par canal, taux de réussite des paiements en euros, écarts de rapprochement, revue du lundi. Chaque semaine se termine par une démonstration, selon le guide sur la livraison sans casse.
Ce qui fait échouer un encaissement en deux devises
Cinq causes, vues dans des applications qu'on reprend. Le prix en euros recalculé à l'affichage : le client voit un montant et en paie un autre. Le montant fixé côté navigateur : il se modifie. Deux commandes pour un paiement : une par devise, et la double comptabilité commence. Les totaux additionnés : des euros et des dinars dans la même colonne, et un rapprochement impossible. Le remboursement au taux du jour : le client récupère plus ou moins que ce qu'il a payé.
Et une cause de méthode : construire l'encaissement en euros avant d'avoir réglé l'entité qui encaisse. L'application suit le montage ; elle ne le remplace pas.
Questions fréquentes
Les questions que posent les fondateurs et les gérants quand ils nous décrivent des clients des deux côtés de la mer.
- Comment encaisser un client en France pour un service en Algérie ?
- Par un prestataire de paiement étranger, rattaché à une entité dans un pays où il ouvre des comptes, la France par exemple ; les grands prestataires étrangers n'ouvrent pas de compte à une entreprise algérienne aujourd'hui. Le client paie en euros sur la page du prestataire, avec l'authentification forte que sa banque exige, et le webhook confirme la commande. Quelle entité et comment les fonds circulent sont des questions pour votre comptable et votre conseil.
- Pourquoi un taux figé à la commande ?
- Parce que le client doit être débité du montant qu'il a vu. Le prix de référence est en dinars ; le prix en euros est calculé avec un taux de référence au moment de la commande, arrondi selon une règle écrite, et conservé sur la fiche. Le remboursement repart au même montant, dans la même devise, sans que le taux du jour intervienne.
- Faut-il deux commandes, une par devise ?
- Non, jamais. Une seule commande, une seule machine à états, et le canal d'encaissement est un champ de la fiche. Les deux prestataires envoient leur webhook vers le même traitement, qui vérifie la signature, l'identifiant et le montant, et fait passer la commande à « payée » une seule fois.
- Comment rapprocher des euros et des dinars ?
- Séparément : chaque canal se rapproche dans sa devise contre le versement de son prestataire, avec les frais et le net attendus ligne par ligne. Les deux totaux ne s'additionnent jamais. L'équivalent en dinars au taux figé de chaque commande sert au chiffre d'affaires et à l'export vers le cabinet, pas au rapprochement.
- Pourquoi la banque française refuse-t-elle la carte ?
- Le plus souvent parce que le parcours ne gère pas l'authentification forte que les banques européennes exigent depuis 2019 pour la plupart des paiements en ligne, ou parce que le montant a été modifié côté navigateur. La page du prestataire déclenche l'authentification quand la banque la demande, et l'application affiche un message clair et relance le client.
- Comment rembourser un client qui a payé en euros ?
- Par le même canal, dans la même devise, au même montant, via le prestataire étranger ; un avoir est lié à la commande. Jamais par un virement manuel ni au taux du jour. Le remboursement apparaît dans le rapprochement du canal euros avec son signe négatif.
- Combien de temps pour mettre cela en place ?
- Six semaines dans le calendrier type, dont la première sans code avec le comptable pour l'entité, le taux et les frais ; puis prix et devises, encaissement en euros, commande unique, rapprochement, mesure. Le délai dépend surtout du temps pour ouvrir le compte du prestataire étranger sur l'entité retenue.