Tag: État de la commande PrestaShop

L’intégration d’une passerelle de paiement dans PrestaShop peut sembler simple sur le papier.

La passerelle fournit la documentation API, les identifiants de test, les clés d’authentification, les URL de rappel et quelques points de terminaison. Le module PrestaShop envoie ensuite la requête de paiement, reçoit la réponse, crée la commande et redirige le client vers la page de confirmation.

Dans une véritable boutique PrestaShop, cependant, la passerelle de paiement fonctionne rarement seule.

Dès qu’un magasin utilise un module de paiement en une seule page (OPC) tel que SuperCheckout, plusieurs modules de paiement, flux de paiement personnalisés, iframes, méthodes de paiement basées sur JavaScript et personnalisations supplémentaires du processus de paiement peuvent tous interagir entre eux.

C’est là que de nombreuses intégrations de paiement se compliquent.

Lors de nos travaux sur la compatibilité des passerelles de paiement, nous avons constaté des cas où un mode de paiement fonctionnait parfaitement avec le processus de paiement par défaut de PrestaShop, mais se comportait différemment dans OPC. Par exemple, un fournisseur de paiement pouvait s’afficher correctement sur le processus de paiement standard, tandis que des options telles que BLIK, la sélection bancaire ou BNPL disparaissaient dans SuperCheckout.

La leçon essentielle à retenir est que l’intégration d’une passerelle de paiement ne se limite pas à la simple validation de l’appel API. Il s’agit d’assurer le bon fonctionnement de l’intégralité du cycle de paiement au sein de la page de paiement PrestaShop.

1.0 De quoi une passerelle de paiement personnalisée a-t-elle réellement besoin ?

De manière générale, une intégration de paiement PrestaShop doit gérer cinq éléments :

1. Afficher le mode de paiement lors du passage à la caisse.
2. Transmettez les données client ou de paiement à la passerelle.
3. Recevoir et valider la réponse de la passerelle.
4. Créez ou mettez à jour correctement la commande PrestaShop.
5. Ramener le client à la page de confirmation ou d’erreur appropriée.

Un module de paiement typique étend plutôt que la classe de base.

Le module de paiement fonctionne normalement avec des hooks tels que :

Le module d’accroche permet de rendre le mode de paiement disponible à la caisse.

Le module d’accroche gère ce que le client voit après son retour du processus de paiement.

Par exemple :

public function hookPaymentOptions($params) { if (!$this->active || !$this->checkCurrency($params['cart'])) { return []; } $paymentOption = new PaymentOption(); $paymentOption ->setCallToActionText($this->l('Payer par carte')) ->setAction( $this->context->link->getModuleLink( $this->name, 'redirect', [], true ) ); return [$paymentOption]; }

L’important est que ce hook ne présuppose pas que le mode de paiement puisse toujours être affiché.

La devise, le pays, l’opérateur, l’état du client, le montant du panier, la configuration du module et la disponibilité de la passerelle de paiement peuvent tous influencer l’affichage du mode de paiement.

2.0 La pièce qui change tout : OPC

Le processus de paiement par défaut de PrestaShop et un module OPC ne traitent pas nécessairement les méthodes de paiement exactement de la même manière.

Ce fut l’une des leçons les plus importantes tirées de l’utilisation de plusieurs modules de paiement.

Avec le processus de paiement par défaut, un module de paiement contrôle généralement lui-même l’affichage des options de paiement et le flux de paiement.

Avec un OPC (Optical Payment Control), le module de paiement devient une couche supplémentaire entre le module de paiement et le client. Cela signifie que les éléments suivants peuvent interagir :

Le client
↓
OPC / SuperCheckout
↓
Options de paiement
↓
Module de paiement
↓
API de passerelle
↓
Réponse de la passerelle
↓
Module de paiement
↓
OPC / PrestaShop
↓
Confirmation de commande

Un module de paiement peut donc être parfaitement correct du point de vue de l’API et pourtant ne pas fonctionner correctement au sein d’un OPC.

C’est pourquoi les tests de compatibilité des paiements doivent toujours inclure les deux :

• Processus de paiement par défaut de PrestaShop
• Le code OPC réellement utilisé par le magasin

Tester uniquement la procédure de paiement par défaut peut donner l’impression erronée que l’intégration est terminée.

3.0 Un exemple concret : les options PayU sont absentes de l’OPC

L’un des problèmes pratiques que nous avons rencontrés concernait les options de paiement PayU.

Sur la page de paiement standard de PrestaShop, PayU affichait correctement ses modes de paiement disponibles. Cependant, sur SuperCheckout, certaines options de paiement étaient manquantes.

Par exemple, selon la configuration et le panier :

• BLIK n’était pas visible de manière constante.
• La liste de sélection des banques ne s’est pas affichée correctement.
• Certaines lignes BNPL/paiement étaient manquantes.
• Dans certains cas, BLIK est apparu puis a disparu.

À première vue, cela ressemblait à un problème d’API PayU. Ce n’en était pas un.

L’étape diagnostique importante consistait à comparer le flux de paiement entre la page de paiement par défaut et SuperCheckout.

Lorsque le même module de paiement fonctionne sur la page de paiement par défaut mais échoue dans OPC, l’enquête doit s’étendre au-delà de l’API de la passerelle.

Nous devons vérifier comment l’OPC construit les méthodes de paiement et quelles informations il transmet aux modules de paiement.

4.0 Le montant du paiement peut affecter la visibilité du mode de paiement

Un aspect particulièrement important de cette enquête concernait le montant du panier. Les plateformes de paiement imposent souvent des limites minimales et maximales aux transactions. Par exemple :

Mode de paiement
↓
Vérifier le montant du panier
↓
Montant minimum ? Montant maximum ?
↓
Admissible / Non admissible

Lors de l’enquête de compatibilité avec PayU, nous avons constaté que la logique de filtrage des méthodes de paiement était liée au fait que le montant du panier était transmis lors des vérifications des méthodes de paiement.

Le flux concerné impliquait le calcul du panier et le filtrage des méthodes de paiement de PrestaShop, y compris la logique relative à :

Panier::LES DEUX

et :

PayMethodsCache::checkMinMax

C’est important car une option de paiement peut disparaître de la page de paiement sans que l’API elle-même ne renvoie d’erreur.

Il se peut tout simplement que la passerelle soit considérée comme inéligible pour le montant reçu par le module de paiement. Cela nous fournit une règle de débogage importante :

Si une option de paiement disparaît d’une page de paiement en ligne, ne concluez pas immédiatement à une défaillance de l’API de paiement. Vérifiez d’abord le montant du panier, la devise, les limites minimales et maximales, ainsi que les valeurs correspondant aux critères d’éligibilité du mode de paiement.

Cela devient encore plus important lorsque des remises, des frais de livraison, des taxes, des bons d’achat ou des calculs personnalisés sont impliqués.

5.0 Pourquoi certains modes de paiement fonctionnent lors du paiement par défaut mais pas lors du SuperCheckout

Une méthode utile pour étudier ces problèmes consiste à comparer les deux environnements de caisse.

5.1 Processus de paiement par défaut de PrestaShop

Panier
↓
Recherche d'options de paiement
↓
hooks paymentOptions
↓
Modules de paiement
↓
Options de paiement

5.2 Paiement OPC

Panier
↓
SuperCheckout
↓
Modes de paiement
↓
Modules de paiement
↓
Traitement OPC supplémentaire
↓
Interface utilisateur de paiement rendue

Le second flux comporte des pièces mobiles supplémentaires.

Par conséquent, lors du débogage d’un problème de paiement, nous ne nous contentons pas de vérifier : « Le module de paiement fonctionne-t-il ? »

Nous vérifions: « Le module de paiement fonctionne-t-il correctement lorsque sa sortie est consommée et affichée par cette implémentation de paiement spécifique ? »

Cette distinction a permis de gagner un temps considérable lors du débogage.

6.0 L’option de paiement ne représente qu’une partie de l’intégration.

À partir de PrestaShop 1.7, les modules de paiement utilisent généralement la génération de code HTML de paiement via l’ancienne méthode de hook de paiement.

Une option de paiement peut contenir des informations telles que :

$option de paiement
->setCallToActionText(...)
->setAction(...)
->setInputs(...)
->setAdditionalInformation(...)

objets au lieu de directement

Différentes passerelles nécessitent différentes combinaisons.

6.1 Passerelle basée sur la redirection

Le client clique sur le mode de paiement et est redirigé vers la passerelle de paiement.

Paiement
↓
Option de paiement
↓
Contrôleur de module
↓
Réseau

6.2 Formulaire de paiement intégré

Les champs de paiement sont affichés directement lors du passage à la caisse.

Paiement
↓
Option de paiement
↓
Formulaire de carte/paiement
↓
API de passerelle

6.3 Paiement via iframe

L’interface de la passerelle est intégrée au processus de paiement.

Paiement
↓
Option de paiement
↓
Iframe
↓
Réseau

Les deux dernières approches nécessitent une attention particulière car JavaScript, la manipulation du DOM, le chargement des iframes et les actualisations OPC peuvent affecter l’interface de paiement.

JavaScript 7.0 devient essentiel avec OPC

C’est un aspect que les guides génériques d’intégration des paiements négligent souvent.

Un OPC peut actualiser dynamiquement certaines parties du processus de paiement lorsque le client change :

• adresse de livraison
• Pays
• porteur
• mode de paiement
• détails de facturation
• Méthode d’envoi

Dans ce cas, le code HTML relatif aux paiements peut être remplacé.

Un événement JavaScript qui fonctionnait lors du chargement initial de la page peut donc cesser de fonctionner après une actualisation AJAX.

Par exemple :

Chargement initial de la caisse
↓
Paiement JS initialisé
↓
Le client modifie les informations de paiement/livraison
↓
OPC met à jour sa section paiement
↓
DOM d'origine remplacé
↓
Paiement JS non associé

Cela peut engendrer des symptômes déroutants.

Le mode de paiement peut s’afficher initialement, mais cliquer dessus ne produit aucun effet. Une iframe peut disparaître.

La liste des banques peut cesser de s’allonger.

Une option de paiement peut apparaître et disparaître après la modification d’un autre champ du formulaire de paiement.

Par conséquent, les travaux de compatibilité nécessitent souvent des modifications non seulement dans PHP, mais aussi dans le JavaScript du module de paiement.

8.0 Un exemple concret : SimplyLease + SuperCheckout

Un autre exemple concerne l’intégration de SimplyLease avec SuperCheckout. Le problème ne se limitait pas à l’API de la passerelle.

Certaines informations et certains éléments de calcul de SimplyLease faisaient partie de la présentation de paiement et devaient fonctionner correctement dans le flux SuperCheckout.

Les modifications de compatibilité concernaient à la fois les modèles de modules et l’intégration JavaScript côté SuperCheckout. Les fichiers concernés étaient les suivants :

modules/simplylease/views/templates/hook/payment_info.tpl modules/simplylease/views/templates/hook/product_calculator.tpl

modules/supercheckout/controllers/front/SupercheckoutCore.php modules/supercheckout/views/js/front/supercheckout.js
modules/supercheckout/views/js/front/simplylease_supercheckout.js

Ceci illustre bien pourquoi la compatibilité des paiements nécessite parfois des modifications en dehors du module de passerelle de paiement lui-même.

Le prestataire de paiement peut fournir les données correctes, mais la page de paiement doit tout de même :

1. Rendu.
2. Conservez-le lors des actualisations de la page de paiement.
3. Initialisez le JavaScript requis.
4. Veuillez synchroniser les informations de paiement avec le panier actuel.

9.0 Autre problème courant : le mode de paiement n’apparaît pas

Nous avons également rencontré des cas où un mode de paiement tel que Comfino n’apparaissait pas dans SuperCheckout même si le module de paiement lui-même était installé et configuré.

Ce type de problème devrait faire l’objet d’une enquête systématique.

Vérifier:

9.1 Le module est-il actif ?

$this->actif

9.2 La devise est-elle prise en charge ?

$this->checkCurrency($params['cart'])

9.3 Le pays est-il soutenu ?

Certaines plateformes de paiement limitent les modes de paiement en fonction du pays du client.

9.4 Le total du panier est-il inférieur aux limites de la passerelle de paiement ?

Les valeurs minimales et maximales des transactions peuvent empêcher l’affichage d’une méthode.

9.5 L’opérateur est-il pris en charge ?

Certains modules de paiement limitent les modes de paiement en fonction de l’opérateur.

9.6 Le filtrage OPC est-il la méthode ?

Le module de paiement peut renvoyer des méthodes valides qui sont collectées, filtrées ou affichées. Mais le COP peut encore modifier les modalités de paiement

9.7 JavaScript masque-t-il ou remplace-t-il l’élément ?

Un moyen de paiement peut techniquement être renvoyé par PHP sans pour autant être visible lors du passage à la caisse.

C’est pourquoi les outils de développement du navigateur sont aussi importants que les journaux PHP lors du débogage des intégrations de paiement.

10.0 Crochets auxquels nous devons réellement prêter attention

Une intégration de paiement personnalisée ne doit pas être traitée comme une implémentation à point d’ancrage unique.

Les points d’ancrage exacts dépendent de l’architecture de la passerelle et du processus de paiement, mais certains sont particulièrement importants.

10.1 Options de paiement

Il s’agit du principal moyen d’afficher le mode de paiement lors du passage en caisse.

Il est responsable du retour Options de paiement objets.

Les contrôles habituels comprennent :

if (!$this->active) { return [];
}
if (!$this->checkCurrency($params['cart'])) { return [];
}

Des restrictions supplémentaires spécifiques à la passerelle peuvent alors être appliquées.

10.2 Paiement et retours

Ceci est utilisé une fois que le client a finalisé son paiement ou est revenu à la suite du processus. Cela peut afficher :

• référence de commande
• statut de paiement
• instructions de paiement supplémentaires
• informations spécifiques à la passerelle

10.3 actionPresentPaymentOptions

Ce mécanisme devient particulièrement intéressant lorsque plusieurs modules de paiement et un OPC sont impliqués.

Il fonctionne avec les options de paiement rassemblées et peut s’avérer utile lorsque la caisse doit inspecter ou modifier l’ensemble des options de paiement disponibles.

Cela diffère de la mise en œuvre des options de paiement d’une seule passerelle. crochet.

Cette distinction est importante :

options de paiement
↓
Chaque module de paiement apporte son option
actionPrésentOptionsDePaiement
↓
Les options de paiement sélectionnées peuvent être traitées.

Lors du débogage de la compatibilité OPC, comprendre où les options de paiement sont collectées par rapport à l’endroit où elles sont finalement présentées peut faire la différence entre trouver rapidement le problème et passer des heures à l’intérieur du module de passerelle.

11.0 Création de commande : Ne jamais faire confiance au navigateur

Une fois le paiement reçu par la passerelle de paiement, l’étape cruciale suivante est la création de la commande. La méthode PrestaShop la plus importante à ce stade est :

validerOrder()

Voici un exemple simplifié :

$this->module->validateOrder(
$cart->id, Configuration::get('PS_OS_PAYMENT'),
Montant payé,
$paymentMethod,
$message, [],
nul, faux,
$client->clé_sécurisée
);

Trois valeurs méritent une attention particulière :

11.1 ID du panier

Le panier doit appartenir au client/à la session prévue et doit être valide.

11.2 Montant du paiement

Ne pas utiliser aveuglément :

$cart->getOrderTotal()

comme preuve que la passerelle a bien reçu ce montant.

Le montant doit être validé par rapport à la réponse de la passerelle.

11.3 Clé de sécurité

Le consommateur doit être correctement associé au flux panier/commande.

12.0 Les webhooks doivent être idempotents

Une passerelle de paiement peut envoyer le même webhook plusieurs fois. Par exemple :

Réseau
↓
Webhook
↓
Votre serveur
↓
Réponse 200

Si la réponse est perdue :

Réseau
↓
Webhook
↓
Votre serveur
↓
Réponse perdue
↓
nouvelles tentatives de passerelle

Si l’intégration crée une commande à chaque réception d’un webhook, des commandes en double sont possibles. Par conséquent, la fonction de rappel doit vérifier si le panier contient déjà une commande avant d’en créer une autre. Conceptuellement :

si ($cart->OrderExists()) {
// Déjà traité
// Retourner une réponse positive
}

Le gestionnaire de webhook doit être conçu pour traiter en toute sécurité les notifications répétées.

13.0 Paiement synchrone vs asynchrone

Toutes les plateformes de paiement ne confirment pas le paiement immédiatement.

13.1 Synchrone

La passerelle confirme immédiatement la transaction.

Le client
↓
Réseau
↓
Paiement approuvé
↓
validerOrder()
↓
PAIEMENT PS_OS
↓
Confirmation

13.2 Asynchrone

Le client peut retourner le produit avant la réception de la confirmation de paiement finale.

Le client
↓
Réseau
↓
Retour au magasin
↓
Commande en cours
↓
Webhook
↓
Vérifier le paiement
↓
État de l'ordre de modification
↓
Paiement accepté

Pour les passerelles asynchrones, l’utilisation d’un état de commande en attente dédié est souvent plus sûre que de marquer immédiatement la commande comme payée.

Une fois que le webhook confirme le paiement :

$history = new OrderHistory();
$history->id_order = (int) $order->id;
$history->changeIdOrderState( Configuration::get('PS_OS_PAYMENT'),
$commande
);
$history->addWithemail(true);

Cela garantit que la transition d’état de la commande passe par le mécanisme d’historique des commandes de PrestaShop au lieu de simplement modifier la valeur dans la base de données.

14.0 L’une des techniques de débogage les plus utiles : comparer les flux de vérification

Lorsqu’un mode de paiement fonctionne dans la procédure de paiement par défaut mais pas dans OPC, nous recommandons de comparer le flux complet.

Étape 1 : Vérifier le PHP

Est-ce que hookPaymentOptions() exécuté?

Étape 2 : Examiner les options renvoyées

Le module de paiement renvoie-t-il effectivement un option de paiement?

Étape 3 : Vérifier le panier

Comparez:

• la totalité de votre cycle de coaching doit être payée avant votre dernière session.
• monnaie
• des clients
• Pays
• porteur
• remises
• impôts
• frais de livraison

Étape 4 : Vérifiez le navigateur

Chercher:

• Erreurs JavaScript
• Éléments DOM manquants
• Requêtes AJAX
• requêtes échouées
• erreurs iframe

Étape 5 : Vérifier l’OPC

Déterminez si SuperCheckout est :

• filtrer l’option de paiement
• en remplaçant son HTML
• actualiser la section paiement
• modifier le panier avant l’exécution du module de paiement

Étape 6 : Vérifier la passerelle

Ce n’est qu’après confirmation du processus de caisse local que l’enquête devrait s’approfondir sur :

• Authentification API
• charge utile de requête
• Signature
• à un besoin identifié
• Webhook
• journaux de passerelle

Cette approche par couches est beaucoup plus rapide que de commencer systématiquement par l’API de passerelle.

15.0 Problèmes courants d’intégration des paiements que nous avons constatés

Les tests de compatibilité en conditions réelles révèlent généralement des problèmes qui ne sont pas évidents à partir de la documentation de la passerelle.

15.1 L’option de paiement disparaît

Causes possibles:

• devise non prise en charge
• restriction du pays
• Le montant du panier dépasse les limites de la passerelle.
• restriction de l’opérateur
• Filtrage OPC
• configuration du module de paiement
• JavaScript masquant la méthode

15.2 BLIK ou une autre option de paiement apparaît et disparaît

Causes possibles:

• consulter la mise à jour AJAX
• rendu de l’option de paiement
• Initialisation JavaScript
• total du panier en cours
• L’éligibilité au portail est en cours de recalcul.

15.3 La liste des banques ne s’élargit pas.

Enquêter souvent :

• Erreurs JavaScript
• éléments DOM remplacés dynamiquement
• gestionnaires d’événements attachés avant l’actualisation OPC
• Initialisation JavaScript du fournisseur de paiement

15.4 L’iframe disparaît

Enquêter:

• actualiser la page de paiement
• Initialisation de l’iframe
• Remplacement DOM
• Exécution de JavaScript après les mises à jour AJAX
  

15.5 Le paiement a été effectué avec succès, mais la commande reste en attente.

Vérifier:

• URL du webhook
• livraison par webhook
• vérification de la signature
• Recherche de panier/commande
• transition ordre-état
• authentification par rappel

15.6 Le mode de paiement fonctionne lors du passage en caisse par défaut, mais pas lors du passage en caisse classique.

Cela indique fortement que le problème pourrait provenir de l’interaction entre le module de paiement et l’OPC plutôt que de l’API de la passerelle elle-même.

16.0 Exigences de sécurité pour un module de paiement

Les modules de paiement gèrent des opérations sensibles ; la sécurité ne peut donc pas être considérée comme une amélioration optionnelle. Au minimum :

• Valider les signatures des fonctions de rappel.
• Valider la relation panier/client.
• Utilisez HTTPS.
• Valider les certificats TLS.
• Ne vous fiez jamais uniquement aux informations de paiement fournies par votre navigateur.
• Ne stockez jamais les informations brutes des cartes bancaires, sauf si l’architecture et les exigences de conformité le permettent explicitement.
• Ne pas enregistrer les informations de paiement sensibles.
  

• Évitez les fonctions serialize() et unserialize(). / pour les données externes non fiables.

• Valider et convertir les valeurs entrantes.
• Protéger les points de terminaison AJAX et de rappel personnalisés.
• Utilisez des jetons sécurisés lorsque cela est approprié.
• Rendre le traitement des webhooks idempotent.

Une page de confirmation de paiement ne constitue pas une preuve de paiement.

C’est la réponse vérifiée du serveur de la passerelle qui devrait déterminer si la commande est considérée comme payée.

17.0 Quels changements surviennent lors de la prise en charge de plusieurs modules de paiement ?

Une autre leçon tirée des travaux sur la compatibilité OPC est que l’ajout d’un deuxième ou d’un troisième module de paiement peut révéler des problèmes qui n’étaient pas visibles lorsqu’il n’existait qu’un seul moyen de paiement.

Par exemple :

PayPal PayU
Comfino
SimplyLease
Virement bancaire

Tous ces moyens de paiement peuvent être proposés sur la même page de paiement. Celle-ci doit donc gérer différents types de paiements :

• Structures HTML
• JavaScript
• exigences relatives aux iframes
• redirections
• Flux d’API
• règles d’éligibilité
• montants minimum/maximum
• rappels asynchrones

Une modification apportée à un mode de paiement peut affecter accidentellement un autre. C’est pourquoi les correctifs de compatibilité des paiements doivent être limités à des cas précis.

Par exemple, au lieu de modifier globalement toute la logique de traitement des options de paiement, identifiez le mode de paiement spécifique et appliquez la gestion de compatibilité uniquement lorsque cela est nécessaire.

18.0 Les tests doivent inclure des scénarios de panier réels

Tester une passerelle de paiement avec un simple produit à 10 € ne suffit pas. Une matrice de test adéquate doit inclure :

Scénario	Ce qu’il faut vérifier
produit unique	L’option de paiement apparaît
Produits multiples	Le montant correct atteint la passerelle
La remise	Le montant final à payer est correct.
Frais de port	Gateway reçoit le total correct
Fiscalité	Le montant de la passerelle correspond à la commande
Montant minimum de la passerelle	La méthode apparaît/disparaît correctement
Montant maximal de la passerelle	La méthode apparaît/disparaît correctement
Devise non prise en charge	La méthode est cachée
Pays non pris en charge	La méthode est cachée
Paiement par défaut	Le paiement fonctionne
OPC	Le paiement fonctionne
Paiement mobile	L’interface utilisateur fonctionne
Paiement échoué	État correct de la commande/du paiement
Paiement réussi	La commande a été correctement créée.
nouvelle tentative de webhook	Pas de commande en double
Abandon de clients	Aucune commande payée incorrectement
Délai d’attente de la passerelle dépassé	Gestion correcte des requêtes en attente/erreurs

Pour les intégrations OPC, testez également l’actualisation de la page de paiement. Modifiez :

• propos
• porteur
• Pays
• mode de paiement
• Quantité
• réduction

et vérifiez que les options de paiement restent correctes après chaque actualisation.

19.0 Une approche pratique du développement

Compte tenu des problèmes qui surviennent fréquemment lors des intégrations réelles, un ordre de développement plus sûr est le suivant :

19.1 Configurer la passerelle de paiement pour qu’elle fonctionne avec le module de paiement par défaut de PrestaShop

Il faut d’abord établir que :

Option de paiement
↓
Requête de passerelle
↓
Réponse de la passerelle
↓
validerOrder()
↓
Confirmation

fonctionne correctement.

19.2 Ajout du traitement des rappels/webhooks

Ne laissez pas la confirmation asynchrone pour la fin.

19.3 Ajouter une gestion appropriée de l’état de l’ordre

Tester:

• succès
• échec
• En attente
• temps mort

19.4 Test avec des chariots réalistes

Utilisez les remises, les frais de port, les taxes, les différentes devises et les totaux différents.

19.5 Intégration avec OPC

Ce n’est qu’une fois le flux de passerelle de base stabilisé que vous devriez étudier la compatibilité avec SuperCheckout.

19.6 Test JavaScript et actualisations dynamiques

Ceci est particulièrement important pour les formulaires de paiement intégrés, les iframes, les interfaces BLIK/de sélection bancaire et autres composants de paiement interactifs.

19.7 Testez tous les modes de paiement simultanément

Un système de paiement prenant en charge cinq modes de paiement doit être testé comme un système global, et non comme cinq modules isolés.

20.0 Faut-il créer une passerelle personnalisée ou utiliser un module existant ?

Toutes les passerelles ne justifient pas une intégration personnalisée. Un module personnalisé est pertinent lorsque :

• La passerelle est régionale ou de niche.
• Il n’existe aucun module PrestaShop maintenu
• La passerelle nécessite une logique métier personnalisée
• Vous avez besoin d’un abonnement ou d’un flux de règlement spécifique.
• Vous avez besoin de fonctionnalités que les modules existants ne peuvent pas fournir.

Mais la mise en place d’une intégration de paiement implique également d’en assumer la responsabilité de la maintenance. PrestaShop évolue.

Évolution de PHP. Évolution des API de passerelle.

Les exigences de sécurité évoluent. Les modules de paiement évoluent.

Et finalement, le prestataire de paiement modifie quelque chose qui perturbe une intégration qui était par ailleurs stable.

Pour les passerelles de paiement courantes, un module établi et maintenu peut donc s’avérer nettement moins coûteux que la maintenance d’un code de paiement personnalisé pendant plusieurs années.

21.0 La leçon principale de l’intégration des paiements PrestaShop

La principale leçon à tirer de l’utilisation des passerelles de paiement est que l’API n’est souvent pas la partie la plus difficile. Envoi :

Requête API → Réponse de l'API

c’est généralement simple.

Le plus difficile, c’est tout ce qui l’entoure :

┌── Règles monétaires
├── Règles du pays
├── Montant du panier
├── Restrictions du transporteur
├── OPC
├── JavaScript
├── Iframes
├── Rafraîchissements AJAX
├── Crochets Web 
├── États de l'ordre
└── Notifications en double
↓
Le client → Paiement → Module de paiement → Réseau
↓
Création de commande
↓
Confirmation de commande

L’intégration d’un système de paiement n’est réussie que si l’ensemble de la chaîne fonctionne de manière cohérente.

C’est également pourquoi un problème tel que « BLIK est manquant » ou « la liste des banques ne s’ouvre pas » ne doit pas être immédiatement traité comme un problème d’API de passerelle.

La cause réelle pourrait être un calcul du total du panier, une vérification d’éligibilité du mode de paiement, le rendu OPC, l’initialisation JavaScript ou une actualisation AJAX remplaçant l’interface de paiement.

22.0 Liste de vérification finale pour une passerelle de paiement PrestaShop personnalisée

Avant de considérer l’intégration comme terminée, vérifiez :

• Le module de paiement étend Module de paiement.
• Options de paiement est correctement implémenté.
• retour de paiement est mis en œuvre là où cela est nécessaire.
• Les options de paiement sont utilisées Options de paiement.
• Les restrictions de change sont vérifiées.
• Les restrictions liées au pays et à l’opérateur sont vérifiées le cas échéant.
• Le total du panier est validé.
• Les réponses de la passerelle sont vérifiées.
• Les signatures des fonctions de rappel sont validées.
  
• Valider l’ordre() Cet appel n’est effectué qu’après vérification réussie du paiement.
• Le montant utilisé pour la commande est validé par rapport à la réponse de la passerelle.
• Les webhooks sont idempotents.
• Les notifications en double ne créent pas de commandes en double.
• L’ordre correct des états est utilisé.
• Les paiements échoués et les paiements en attente sont traités séparément.
• Les données de paiement sensibles ne sont jamais enregistrées ni stockées inutilement.
• Le protocole HTTPS est obligatoire.
• La page de paiement par défaut de PrestaShop a été testée.
• L’OPC a été testé séparément.
• JavaScript a été testé après les actualisations de la page de paiement AJAX.
• Les iframes et les éléments de paiement interactifs ont été testés.
• Plusieurs modules de paiement ont été testés simultanément.
• Des paniers d’achat réalistes avec réductions et frais de livraison ont été testés.

Conclusion

Une passerelle de paiement personnalisée dans PrestaShop est bien plus qu’une simple intégration API.

L’API ne représente qu’une partie de l’implémentation. Le véritable défi technique commence lorsque le module de paiement doit coexister avec le système de paiement de PrestaShop, un OPC tel que SuperCheckout, d’autres modules de paiement, du JavaScript dynamique, le recalcul du panier et les rappels asynchrones de la passerelle de paiement.

Notre expérience en matière de problèmes de compatibilité des paiements a renforcé une approche importante : toujours isoler l’origine du problème avant de modifier le code.

Si PHP ne renvoie pas le mode de paiement, examinez le module de paiement et ses critères d’éligibilité. Si PHP le renvoie mais que le client ne le voit pas, examinez l’OPC et le rendu côté client. Si l’interface utilisateur s’affiche mais ne répond pas, examinez JavaScript et les actualisations AJAX. Si le paiement réussit mais que la commande reste en attente, examinez le flux de rappel et d’état de la commande.

Cette approche est bien plus fiable que de supposer que chaque problème de paiement est un problème d’API.

Pour les développeurs travaillant sur l’intégration des paiements PrestaShop, l’objectif ne doit pas se limiter à permettre à une passerelle d’accepter une transaction. Il s’agit de garantir la fiabilité de l’ensemble du cycle de vie du paiement, de l’affichage initial de la page de paiement à la validation finale de la commande, même en présence de plusieurs moyens de paiement et d’un code OPC personnalisé.