STRIPE_USE_NEW_CHECKOUT ne fonctionne plus

Utiliser mon Dolibarr
,
1

Bonsoir,

Cela fait depuis que nous avons mis à jour Dolibarr vers la version 22.0 que nous ne pouvons plus utiliser le checkout de stripe, car, même si le processus de paiement de déroule correctement, Dolibarr n’arrive pas à faire le lien avec la facture réglée et renvoie une erreur au client.

C’est très embêtant car le checkout de stripe nous permettait de proposer d’autres solutions de paiement comme klarna et bancontact.

J’ai bien essayé de réglé le problème, mais je n’arrive pas à trouver quel est le changement qui a provoqué cette régression entre la v21 et la v22. Il y a une déclaration de bug sur GitHub, mais elle a été déclaré « won’t ne fixed »…

Est-ce que quelqu’un aurait une solution de contournement ?

Bonne soirée

Paiement liquide et autre - adhésion formulaire auto-inscription
2

Retourner en V21…
Ne pas suivre les MAJ quand ça n’apporte pas de fonctionnalités significatives par rapport à votre version actuelle qui marche bien.
Si votre Dolibarr fonctionne bien, faire une MAJ est dangereux.

3

Bonjour,

Oui, merci, j’y ai pensé, mais un downgrade est très compliqué. On a passé en 22.0 parce qu’on voulait le portail web.

J comprends bien que j’aurais tout du tester avant, mais les paiements fonctionnaient, c’est juste dolibarr qui refuse de les enregistrer. Du coup, j’ai pas été jusquà essayer dacheter un produit pour de vrai et je m’en suis aperçu 1 mois après la mise à jour. Autrement dit, beaucoup trop tard pour envisager un retour en arrière.

Bref, je vous remercie d’avoir pris le temps de me répondre, mais est-ce que vous auriez une piste de solution en v22 ? Je suis pret à coder, mais je ne sais pas dans quelle direction chercher.

Bonne journée

4

Je voudrais bien t’aider mais je passe déjà énormément de temps sur mon module pour association…

Faut que tu saches le nom de l’erreur, de quel fichier ça pourrais provenir, trouver le bloc en question.
Tu peux t’aidé de DeepSeek qui peut analyser des codes de plus de 1000 lignes. Il y a un GPT Dolibarr pour ChatGPT aussi.

Attention ils peuvent ce tromper, il faut savoir identifier les bugs et savoir comment ça marche entre ce module et Dolibarr.
Et toujours faire une sauvegarde du fichier Core avant de le modifier !

Mais ne perd pas espoir, ça doit pas être grand chose, un renommage d’une table, d’une colonne, d’une variable, et ça casse.

5

Hello,

Tu penses à quel gpt exactement ? Je ne connais que celui pour les utilisateur :

Est-ce que tu en as un autre en tête ?

Perso, je préfère utiliser claude et mistral, mais s’il y a vraiment un gain, je vais peut-être essayer avec chatgpt

6
1 « J'aime »
7

Salut la communauté.
Je déterre ce sujet car suis toujours en v21 et j’aimerais pouvoir monter de version de Dolibarr.
Mais j’ai absolument besoin que le module stripe fonctionne correctement, avec son tunnel propre et ses modes de paiement additionnels.
C’est assez compliqué pour moi de monter une préprod juste pour tester ça et je sais qu’en v22 de Dolibarr, ce tunnel stripe ne fonctionnait plus.
Est-ce que quelqu’un a des nouvelles depuis ? Savez-vous si cela est réparé ?
SI personne ne sait, je me lancerai dans le montage d’une préprod pour tester ça mais j’avoue que si je peux éviter, je prends volontiers :slightly_smiling_face:

Merci pour vos retours !

8

Bonjour,

Sur un client → Stripe sur 22.0.4 ne me pose pas de pb.

? Message, logs ?

9

En fait, il n’y a pas d’erreur en soi. Le paiement fonctionne.

Simplement stripe ne fonctionnait plus en mode checkout mais en mode page simple de paiement.

D’une part cette page n’inspire aucune confiance au client, mais surtout l’intérêt du mode checkout est de permettre de proposer le paiement direct via ApplePay, Google Pay, etc…

10

Hello,

Je te confirme que le new checkout de stripe ne fonctionne pas en v22. Je n’ai pas testé en v23, mais vu qu’il n’y a pas eu de modification liée à cette issue, je pense que le new checkout de stripe ne fonctionnera pas.

En revanche, la méthode ancienne fonctionne tjrs.

A plus

11

Merci pour ton retour. C’est hélas ce que je craignais et m’oblige à rester en v21 :cry:

12

Bonjour,

Alors voici ce que j’ai trouvé :

L’issue #34974 a été fermée avec le label « Won’t be fixed/implemented ». Ce label signifie explicitement que le rapport travail/bénéfice est jugé trop défavorable pour une correction. Ce n’est pas un oubli ou une mise en attente — c’est un abandon assumé de ce mode.

Et c’est cohérent : cette fonctionnalité n’a jamais été officiellement supportée (elle était « expérimentale »), et il existait déjà un bug similaire signalé en mai 2024 (issue #29575) montrant que STRIPE_USE_NEW_CHECKOUT=1 générait des erreurs 400 côté Stripe avec l’API version 2022-11-15. GitHub Le problème remonte donc à plusieurs versions.

Si vous voulez des alternatives regardez du côté de Mollie Dolistore (déjà bossé avec eux sur des e-commerce).

MBinformatique à développé un module fonctionnant avec Monetico avec des fonctionnalités simples, évolutions a venir.

Une autre option est de s’y coller :slight_smile:

→ mais perso si besoin de e-commerce ou d’une belle plateforme de vente en ligne, je regarderai à déporter les achats dans un WooCommerce ou Prestashop, puis de synchroniser vers Dolibarr.

Bonne journée

1 « J'aime »
13

Merci pour ton retour complet, c’est bien dommage que ce module soit à l’abandon car stripe est une plateforme fiable et stable, pourvue de nombreuses fonctionnalités…
Je reste donc en v21 pour ma part, en espérant un jour un module stripe alternatif sérieux.

Bonne journée à tous !

14

Je suis tout a fait d’accord avec toi, je dirais même qu’e Stripe prend de plus en plus de place, avec ses multiples possibilités de paiement …

1 « J'aime »
15

Le module n’est pas à l’abandon, c’est l’option STRIPE_USE_NEW_CHECKOUT pour utiliser Stripe en mode variante différent du mode standard qui l’est. Sans cette option, avec le mode par défaut, le module Stripe marche très bien dans tout Dolibarr.

16

C’est ce que j’avais en effet compris. Sauf que c’est justement cette option qui donne toute la valeur ajoutée au module et à Stripe.

La page de paiement classique, sans cette option ferait fuir n’importe qui, et on perd les options de paiements alternatifs qui sont devenus des essentiels.

Personnellement, c’est même ce qui justifie que j’accepte de payer les frais, assez élevés, de Stripe.

2 « J'aime »
17

Bonjour Laurent, c’est justement cela le besoin, utiliser Stripe en dehors de Dolibarr qui est devenu indispensable : revolut, Apple pay, Alma etc… Stripe propose des modes de payements “alternatifs” a la cb qui sont devenus incontournables. L’utilisation du module “dans” Dolibarr ne permet pas cela.

1 « J'aime »
18

Je plussoie !
Et j’avoue que je ne comprends pas pourquoi cette option est abandonnée. J’imagine qu’il doit y avoir une bonne raison, mais pour le moment, je suis assez étonné…
Perso ça m’oblige à rester en v21, c’est dommage :sleepy_face:

19

Bonjour @daraelmin,

J’ai investigué la régression v21–> v22 et j’ai peut-être une piste.

En v22, le fichier paymentok.php a été renforcé avec une vérification du paiement via l’API Stripe côté serveur.
Ce nouveau code fonctionne pour le mode standard, mais pourrait ne pas avoir été adapté au mode STRIPE_USE_NEW_CHECKOUT.

En mode NEW_CHECKOUT, le TRANSACTIONID stocké en session est un Checkout Session ID (cs_xxx). Or le code v22 tente de le récup. via PaymentIntent::retrieve() qui attend un pi_xxx, ce qui pourrait expliquer l’erreur.

Si cette hypothèse est correcte, le patch serait minime:

Dans htdocs/public/payment/paymentok.php, vers la ligne 418, après le setApiKey, et juste avant :

$paymentIntent = \Stripe\PaymentIntent::retrieve($TRANSACTIONID);

Ajouter :

if (strpos($TRANSACTIONID, 'cs_') === 0) {
    $checkoutsession = \Stripe\Checkout\Session::retrieve($TRANSACTIONID);
    $TRANSACTIONID = $checkoutsession->payment_intent;
}

N’ayant pas Stripe en production sur un Dolibarr (que du custom de mon côté), je ne peux pas tester moi-même.
Si tu veux mettre les mains dans le cambouis :wink:

1 « J'aime »
20

Hello,

J’ai investigué aussi, et je crois que c’est un peu plus complexe que ça.

Une stratégie est de reprendre le payementok.php de la v21, mais il a été corrigé car il y avait un bug « aléatoire » qui entrainait une erreur de temps en temps.

Bref, sur la nouvelle version, la séquence dans newpayment.php v22 avec STRIPE_USE_NEW_CHECKOUT :

$_SESSION['TRANSACTIONID'] = $sessionstripe->id;   // = "cs_xxx..." (session Checkout)

Puis en JavaScript, le code appelle :

stripe.confirmPayment({ elements, confirmParams: { return_url: '<?php echo $urlok; ?>', ... } })

C’est là, je crois que se situe le bug:

stripe.confirmPayment() est l’API de Stripe Elements / PaymentIntent, PAS de Stripe Checkout. Quand Stripe redirige vers return_url après confirmPayment, il ajoute en query string :

?payment_intent=pi_xxxxx&payment_intent_client_secret=xxx&redirect_status=succeeded

MAIS il n’ajoute PAS session_id=cs_xxxxx.

Comme $_SESSION['TRANSACTIONID'] est déjà rempli avec cs_xxx (l’ID de la session Checkout), le second if n’est jamais exécuté, et $TRANSACTIONID reste à cs_xxx.

Ensuite, dans la vérification Stripe :

if (preg_match('/^pi_/', $TRANSACTIONID)) {
    $paymentIntent = \Stripe\PaymentIntent::retrieve(...);
} else {
    // Tente de retrouver une "charge" avec cs_xxx, ce qui échoue
}

Avec cs_xxx, le code tente de récupérer ça comme une « charge » (ch_xxx) et là, ça plante et on a le message d’erreur : « Stripe payment verification failed: TRANSACTIONID is not set or session key does not match. »

Pour info : En v21, ça fonctionnait, car la logique sauvegardait pi_xxx (payment_intent) au lieu de cs_xxx (session) dans $_SESSION['TRANSACTIONID'], la priorité était donc inversée : GETPOST('payment_intent') était lu avant la session, mais cela pouvait déclenché des erreurs innatendues.

Le truc, c’est que je suis pas sûr du pourquoi et du comment éviter le bug aléatoire de la v21 (et que je ne suis pas sûr de mon diagnostic non plus)

1 « J'aime »