Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Configuration personnalisée

Gestion des transactions 

Détails des transactions

Annulations

Remboursements

Capture

Tests

Tests unitaires

Tests d'intégration 

Configuration 

Lancer des tests 

Opérations- Maintenance

Stockage des données

Objets personnalisés

Commandes

Services 

Disponibilité

...

Les configurations des comptes dépendent des devises activées sur le site. Après avoir activé une / plusieurs devises sur le site, il est possible de créer les configurations nécessaires. Pour cela, une interface personnalisée est disponible dans : Merchant Tools> Axepta Module> Accounts Configuration . Dans cette interface, les devises activées sont listées, avec la possibilité de modifier / créer ces configurations.

Vous devez configurer les éléments suivants :

  • MerchantID : l’identifiant du compte de paiement Axepta
  • Clé HMac : La clé de chiffrement liée à l’ID MerchantID
  • Clé Blowfish : La clé Blowfish pour les données de paiement
  • Clé d’activation : la clé d’activation du compte, qui vous permet de définir les différents modes de paiement disponibles.

Une fois la configuration créée, il est possible d’activer / désactiver les moyens de paiement disponibles via les cases à cocher.

Configuration des tâches

Pour que les tâches de capture fonctionnent correctement, il sera nécessaire de définir un / plusieurs sites d’exécution pour eux via le contexte des étapes.

Gestion des transactions 

La cartouche est dotée d’une interface de gestion des transactions Axepta. Elle se trouve dans Merchant Tools> Axepta Module> Manage Orders. Lorsque vous cliquez sur le numéro de commande, vous trouverez les détails de cette commande / transaction Axepta associée.

Détails des transactions

Sur cette page se trouvent les informations générales de la commande (différents statuts SFCC). Des informations sur les différents appels Axepta effectués pour la commande sont également disponibles. Sur la partie gauche Opérations de paiement des commandes, nous trouvons la liste des appels, avec le type d’appel effectué, ainsi que le statut. Nous avons donc les opérations PAIEMENT, CAPTURE, REMBOURSEMENT, ANNULATION... Sur la droite, nous trouvons les détails du retour des appels de service (donc tous les détails de la transaction effectuée). À partir de cette page, il est également possible d’annuler ou de rembourser le paiement.

Annulations

Pour effectuer une annulation, la commande doit répondre aux critères suivants :

  • order.paymentStatus égal à "NOT PAID"
  • order.status.value is not "CANCELED"
  • order.custom.axpIsCaptured is not "TRUE"

Si la commande répond à ces critères, un bouton « REMBOURSEMENT » est disponible en haut de la page. Lorsque ce bouton est cliqué, un premier appel vérifie que la commande n’a pas de capture (via le service axepta.inquire , puis un appel est effectué au service axepta.reverse , qui clôturera le paiement et annulera la commande. Une ligne de transaction « remboursée » sera donc ajoutée à la liste.

Remboursements

Pour effectuer un ou plusieurs remboursements, la commande doit répondre aux critères suivants :

  • order.custom.axpIsRefundCompleted égal to "false"
  • order.custom.axpIsCaptured égal à "true"

S’il répond à ces critères, un champ et un bouton sont ajoutés en haut de la page. Par défaut, la valeur saisie est le total de l’ordre. Vous pouvez saisir un remboursement partiel (donc un montant inférieur) si nécessaire. Lors de la validation, un appel au service axepta.capture est effectué et une ligne de transaction est ajoutée. Ce sera soit « REMBOURSEMENT PARTIEL » ou « REMBOURSEMENT » selon le montant.

Capture

Comme indiqué précédemment, 3 modes de capture sont disponibles :

  • Auto

Ce mode de capture ne nécessite aucune action. L’ordre est marqué comme « PAID » et les différents attributs Axepta relatifs à la capture sont remplis. Côté Axepta, la transaction est automatiquement capturée dès sa validation.

  • Avec délai

Ce mode de capture n’a également aucune action du côté Axepta (la commande est capturée par elle-même après la période spécifiée dans les préférences du site). Cependant, pour qu’il soit à jour et marqué comme capturé sur SFCC, il est nécessaire d’activer le Job Axepta - Update Delayed Captures . La tâche s’exécutera sur les commandes dont la date de saisie est « expirée ». Sur ceux-ci, un appel est effectué pour vérifier le statut du paiement, via le service axepta.inquire . Après le retour, il effectue des actions similaires au mode « Auto » (pour marquer la commande comme capturée).

  • Manuelle

Ce mode de capture nécessite un appel au terminal de capture. Ces appels sont gérés par la tâche Axepta - Capture Orders. Cette tâche s’exécute sur les commandes Axepta dont le statut est « EXPÉDIÉ » et qui ne sont pas saisies. Il appelle ensuite le service axepta.capture sur ces commandes. Si la rétroaction est positive, l’ordre est marqué comme Capturé et PAYÉ.

Tests

Les cas de test sont conçus pour couvrir à la fois la fonctionnalité de la boutique, du point de vue du client final, ainsi que la fonctionnalité de gestionnaire , du point de vue du commerçant. Se reporter également à la section 2 – Présentation des composants : Cas d’utilisation pour plus d’échantillons Axepta a été testé avec : 

  • SFRA version 5.3.0
  • Site Genesis 104.1.3
  • Version API SFCC jusqu’à 22.10

Tests unitaires

Un ensemble de tests unitaires est disponible pour les différentes assistances utilisées. Ils sont écrits avec le chai plugin. Pour exécuter les tests, vous devez exécuter la commande npm run test : npm run test: integration --baseUrl {{yourDomainUrl}}

Pour exécuter les tests unitaires, exécutez la commande suivante : npm run test

Le résultat doit être de 15 passes :

Tests d'intégration 

En plus des tests unitaires, un ensemble de tests d’intégration sont également présents sur la cartouche SFRA et Site Genesis. Ceux-ci sont basés sur "codeceptjs plugin" avec son pilote "Test Cafe driver"

Configuration

Pour pouvoir exécuter les différents tests, il est nécessaire de configurer un "sandbox "sur lequel exécuter les tests.

Pour ce faire, ouvrez int_axepta_sfra / test / integration / config.js file :

Dans ce fichier, modifier les lignes suivantes :

Storefront: {
url: '<https://YOURSANDBOX/s/RefArch/home?lang=fr_FR',>
baseUrl: '<https://YOURSANDBOX',> // BASE URL
login: '/on/demandware.store/Sites-RefArch-Site/fr_FR/Checkout-Login' // Checkout
login page,
},
Customer: {
email: '', // YOUR TEST CUSTOMER EMAIL
password: '' // YOUR TEST CUSTOMER PASSWORD
}
With SiteGenesis, open int_axepta_sitegenesis / test / integration / config.js file :
Storefront: {
baseUrl: 'YOUR-SANDBOX-URL/on/demandware.store/Sites-SiteGenesis-Site/'
},
Customer: {
email: 'TEST-EMAIL',
password: 'PASSWORD'
},

Lancer des tests 

Ensuite, 2 commandes sont disponibles, chacune pour un mode d’intégration différent.

  • Mode redirection

Ensuite, la commande npm run testint:redirect (SFRA) ou npm run testintsg:redirect (SiteGenesis) est utilisée pour exécuter les tests pour le mode de redirection. Les tests pour ce mode sont disponibles dans le fichier int_axepta_sfra/test/integration/tests/Checkout_Redirect_test.js ou int_axepta_sitegenesis/test/integration/tests/Checkout_Redirect_test.js

  • Mode iframe

Ensuite, la commande npm run testint:iframe ou npm run testintsg:iframe (SiteGenesis) est utilisée pour exécuter les tests pour le mode de redirection. Les tests pour ce mode sont disponibles dans le fichier int_axepta_sfra/test/integration/tests/Checkout_Iframe_test.js ou int_axepta_sitegenesis/test/integration/tests/Checkout_Iframe_test.js

Opérations- Maintenance

Stockage des données

Objets personnalisés

Cette cartouche ajoute un objet personnalisé axpAccountsConfiguration, nécessaire pour stocker des informations sur les comptes. Il contient des informations définies dans Merchant Tools> Axepta Module> Configuration des comptes.

Commandes

Axepta stockera les résultats de communication dans des notes de commande telles que : 

Image Added


De nouveaux attributs personnalisés sont ajoutés aux commandes :

  • axpCCBrand : La marque de carte
  • axpCaptureDate : La date de saisie du paiement
  • axpCaptureDelayedDate : La date de capture différée
  • axpCode : Le code de réponse d’Axepta
  • axpIsOrder : Indicateur indiquant si l’ordre a été traité par Axepta
  • axpIsCaptured : Indicateur indiquant si le paiement a été saisi
  • axpIsRefundCompleted : Indicateur indiquant si le remboursement est terminé
  • axpPayID : ID de paiement d’Axepta
  • axpRefundedAmount : Le montant qui a déjà été remboursé
  • axpTransID : ID de transaction d’Axepta

Services 

L’intégration Axepta utilise les services ci-dessous 

Image Added


Tous les services utilisent la configuration de profil ci-dessous. Elle peut être facilement modifiée pour différents commerçants. Un profil différent / un profil distinct peut être ajouté pour chaque service.

Image Added

Disponibilité

Chaque erreur liée à Axepta est signalée au point de terminaison de l’API Axepta. La charge utile de la requête contient la description de l’erreur, ID de commande et la charge utile de suivi de pile au format JSON. La commande échouera et contiendra une « erreur » dans les notes de commande (DS – Gestion des commandes). De plus, dans les journaux d’erreurs, cette situation sera ajoutée, avec des détails spécifiques. L’utilisateur final recevra un message d’erreur technique générique : « Nous sommes désolés que votre commande n’ait pas pu être passée. Cela s’est probablement produit en raison d’un volume de commande élevé ou d’erreurs de connexion temporaires. Veuillez attendre quelques minutes et soumettre de nouveau votre commande. Nous ne traiterons pas votre paiement tant que vous n’aurez pas passé votre commande. Si vous avez d’autres questions, veuillez communiquer avec nous. »

Indisponibilité de Axepta 

En cas d’indisponibilité du service Axepta, le contenu de l’iFrame ou de la redirection est rompu.

Exemple :

Image Added

Support


Guide Utilisa

Rôles -Responsabilités

...