Passerelles de paiement — lire le marchand ou le client DERRIÈRE le préfixe (PayPal, Stripe, TWINT, SumUp…)

Passerelles de paiement — lire le marchand ou le client DERRIÈRE le préfixe

Une passerelle de paiement (PayPal, Stripe, TWINT, SumUp, GoPay, Klarna, Payrexx, Mollie, Adyen, wallee, Worldline / SIX, Apple Pay, Google Pay) est un PRÉFIXE NOMINAL sur le libellé, jamais l'entité de l'opération (plan marchands du 20.09, décision user 2). L'entité — QUI est derrière — est le marchand chez qui l'on a payé, ou le client qui paie. Le registre data/passerelles.json porte, pour chacune, ses libellés vus et une lecture en clair ; cette fiche pose la règle de classement, qui ne change pas d'une passerelle à l'autre.

1. Lire le libellé : trois formes, trois entités

Trois pièges de lecture :

• PayPal TRONQUE le nom du marchand à 11 caractères après l'astérisque : « LANGUAGETOO » est LanguageTool,

« THEMECANAL » est ThemeCanopy, « PAYPROGLOBA » est PayPro Global. Tu réunis la forme tronquée et la raison sociale en UNE entité, et tu la nommes en clair.

• SumUp nomme le TITULAIRE du terminal qui encaisse — le marchand ou l'artisan chez qui l'on paie —, jamais le

payeur. Sur la banque d'un client qui a LUI-MÊME un terminal SumUp, un crédit « SUMUP » est le versement net de ses propres encaissements.

• Apple Pay et Google Pay ne sont que des porte-cartes : la ligne porte le marchand réel (« APPLE PAY MIGROS » →

Migros). Ne confonds pas avec « APPLE.COM/BILL » ou « GOOGLE *… », qui sont des achats chez Apple ou Google.

2. Le sens de la ligne décide du traitement, pas la passerelle

Débit (le client paie) : c'est un ACHAT chez le marchand derrière — tu classes le marchand comme s'il n'y avait pas de passerelle (fiche métier, socle transverse, montant, pro/privé). Un PAYPAL *<prénom> en débit est un paiement à un particulier : privé par défaut (2850), sauf pièce qui prouve une prestation pro.

Crédit (le client encaisse) : un versement Stripe / PayPal / SumUp / TWINT / Payrexx / Worldline est de l'argent de SES clients qui arrive. Ce qui décide, c'est de savoir si la vente est DÉJÀ écrite quelque part — jamais l'étiquette « versement » (journal-des-recettes, twint piège 3 : double-comptage OU disparition du CA, les deux erreurs existent) :

• Ventes au comptant, aucune liste de ventes déposée (coiffure, restaurant, marché, thérapeute, commerce : le cas

courant de l'indépendant) : l'encaissement EST la vente. Le fondamental le dit : « si la caisse ou la banque l'exprime, c'est du CA » — chaque crédit TWINT / SumUp / Stripe est une ligne = une vente, et il n'y a PLUS de journal des ventes à déposer. Le produit vient de la NATURE (un service → 3400, une revente → 3200, une fabrication propre → 3000), jamais du canal. Le montant reçu est NET : le produit est le BRUT, la commission une charge 6940, lues sur le décompte — {base: net, taux: commission lue}, le code calcule, jamais un brut inventé.

D 1020 montant NET reçu
D 6940 commission retenue (lue sur le décompte de la passerelle — jamais estimée en silence) C 34xx montant BRUT (la vente n'existe nulle part ailleurs : c'est ici qu'elle s'écrit)

• La vente est déjà écrite (une facture ouverte reprise au 1100, un journal des recettes ou un livre de caisse déposé

ET comptabilisé) : le versement n'est qu'un MOUVEMENT DE TRÉSORERIE — l'argent change de poche. Tu enregistres l'arrivée du NET et la COMMISSION, contre la créance ou le compte de liaison ; tu ne crédites PAS un 3xxx une seconde fois, sinon tu doubles le CA.

D 1020 montant NET reçu
D 6940 commission retenue C 1100 / compte de liaison montant BRUT (la vente est déjà journalisée)

• Ils versent tous NET, et la commission n'apparaît sur le relevé bancaire que chez Payrexx (« Brutto: … Gebühren: …

Netto: … » dans le libellé). Sans décompte déposé, la commission ne peut qu'être estimée — et il faut le DIRE (prestataires-encaissement).

• Stripe verse en LOT : un virement regroupe plusieurs ventes, moins remboursements et chargebacks. Un versement

n'égale jamais une vente ; sans liste de ventes, le lot est le CA de la période qu'il couvre, à dire au client.

• SumUp envoie une facture de frais mensuelle À NE PAS PAYER : elle récapitule des commissions déjà déduites des

versements — la compter en charge à payer les compte deux fois.

• Worldline mêle la location du terminal à la commission : deux natures (6940 commission, 6xxx location), à séparer

sur l'avis de paiement.

• **Crédit <PASSERELLE> *<prénom>** : un particulier qui envoie de l'argent — un client (une vente au comptant, ou

l'encaissement d'une facture déjà écrite), un proche (apport privé 2851), un remboursement. Si l'origine n'est pas établie, tu demandes (encaissement-origine-inconnue) ; tu ne poses pas un produit sur une origine inconnue.

Passerelle seule (ni marchand ni client derrière) : le virement du solde PayPal vers la banque est un transfert interne si le client détient un compte PayPal (compte de bilan 109x, stripe-paypal-revolut-wise) ; les frais (« TWINT ACQUIRING », « PAYPAL » frais de conversion) sont des commissions (6940).

3. Ce que le registre apprend, et ce qu'il n'apprend pas

• L'entité décidée derrière la passerelle entre au registre appris (data/marchands-appris.json) avec sa passerelle

(« via paypal ») : le dossier suivant reconnaît « PAYPAL *DIGITECGALA » comme Digitec dès le run.

• Une passerelle seule n'est jamais un marchand des fiches : ses libellés vus vivent dans data/passerelles.json, pas

dans une fiche métier (le merge des entrées apprises les écarte).

• Le registre dit QUI, jamais quel compte : le compte vient du sens de la ligne (§2), de la fiche du marchand et du

montant.

Liens

• twint — TWINT, le cas suisse (P2P et marchand)
• stripe-paypal-revolut-wise — modèle comptable des processeurs (compte 109x, brut / frais / net)
• prestataires-encaissement — barèmes et forme des décomptes (Payrexx, TWINT, SumUp, Stripe, Worldline)
• journal-des-recettes — le fondamental : « si la caisse ou la banque l'exprime, c'est du CA » ; seules les impayées

au 31.12 se déposent, jamais un journal des ventes

• twint — piège 3 : double-comptage OU disparition du CA, le critère est arithmétique (la vente est-elle

déjà écrite ?), jamais lexical