PdC de paiement partagé : guide de test et de vérification

Ce guide vous guide tout au long de la vérification du bon fonctionnement de chaque composant, dans l’ordre dans lequel ils doivent être testés. Commencez par le bas (module Commerce) et remontez (App Builder).

Étape 1 : vérification de l’installation du module Commerce

Après avoir exécuté bin/magento setup:upgrade et bin/magento setup:di:compile :

# Confirm module is enabled
bin/magento module:status Client_SplitPayment

# Confirm db_schema columns were added
bin/magento doctrine:schema:validate
# or check directly:
mysql -u <user> -p <dbname> -e "DESCRIBE sales_order;" | grep split

Sortie attendue : quatre colonnes commençant par split_ visible dans sales_order.

Étape 2 : vérification de la configuration de l’administrateur Commerce

Dans Commerce Admin :

Étape 3 : vérifier que les points d’entrée REST sont accessibles

Utilisez curl pour confirmer que les points d’entrée répondent (ils rejetteront les requêtes non autorisées, mais un 401 confirmera qu’elles sont correctement acheminées) :

# Should return 401 (not 404) — endpoint exists but requires auth
curl -X POST https://your-store.example.com/rest/V1/split-payment/orders/1/cash-received

# Should return 200 or session-based response — anonymous endpoint
curl -X POST https://your-store.example.com/rest/V1/split-payment/set \
  -H "Content-Type: application/json" \
  -d '{"storeCreditAmount": 0, "cashAmount": 0}'

Étape 4 — Tester l’interface utilisateur de passage en caisse

Validation du test :

Étape 5 — Protection du seuil d’essai

Etape 6 — Effectuer un test d’ordre de paiement fractionné

Une fois la commande passée, vérifiez dans Commerce Admin :

Si aucun commentaire App Builder n’apparaît : vérifiez les journaux d’actions App Builder avec aio app logs. L’événement ne s’est peut-être pas déclenché ou l’action a peut-être une erreur.

Étape 7 — Tester l’acceptation via le script de simulation

Le script de simulation est le moyen le plus rapide de tester le flux d’acceptation/refus sans l’interface utilisateur complète de l’opérateur.

cd commerce-checkout-starter-kit
cp commerce-backend-ui-1/.env.simulation.example commerce-backend-ui-1/.env.simulation
# Edit .env.simulation with your credentials

# List recent orders (find your test order entity_id)
node commerce-backend-ui-1/scripts/simulate-split-payment.mjs list

# Show split payment fields for a specific order
node commerce-backend-ui-1/scripts/simulate-split-payment.mjs show 42

# Accept the cash payment
node commerce-backend-ui-1/scripts/simulate-split-payment.mjs accept 42

Après avoir accepté, vérifiez dans la vue de commande de l’administrateur Commerce :

Etape 8 — Test de refus via le script de simulation

Placez un autre ordre de test (même configuration que l’étape 6), puis :

node commerce-backend-ui-1/scripts/simulate-split-payment.mjs decline <orderId>

Après le refus, vérifiez dans Commerce Admin :

Étape 9 — Tester le tableau de bord de démonstration

Après le déploiement de l’split-payment-orchestrator, aio app deploy imprime les URL d’action.

Ouvrez l’URL demo-dashboard dans un navigateur :

https://[runtime-host]/api/v1/web/split_payment_orchestrator/demo-dashboard

Si DEMO_UI_SECRET est défini :

https://[runtime-host]/api/v1/web/split_payment_orchestrator/demo-dashboard?secret=<your-secret>

Avec une commande en attente :

Étape 10 - Tester les journaux d’actions App Builder

# Follow logs in real-time
aio app logs --tail

# Or view last invocations
aio runtime activation list --limit 10
aio runtime activation logs <activation-id>

Pour le payment-orchestrator, recherchez :

[INFO] Split payment orchestration finished { orderId: '42' }

Par payment-accept ou payment-decline :

[INFO] Cash payment accepted on Commerce via REST { orderId: '42' }

Problèmes courants et correctifs

« La signature n’est pas valide » de Commerce OAuth

Cause : décalage d’horloge entre l’exécution d’App Builder et Commerce, ou bug de signature OAuth.

Correctif:

Les champs de paiement fractionnés n’apparaissent pas dans le passage en caisse

Cause : chemins d’injection LayoutProcessorPlugin ne correspondent pas à votre disposition de passage en caisse.

Correctif:

Le crédit de magasin ne s’applique pas / « Le paiement n’a pas pu être traité » à la commande

Cause : l’un des modules externes de la casse Edge ne fonctionne généralement pas correctement.

Vérifier :

L’action App Builder reçoit l’événement mais orderId est manquant

Cause : la liste des champs io_events.xml n’inclut pas les entity_id ou la forme de la payload de l’événement a changé.

Correctif:

Les commandes ne s’affichent pas dans le tableau de bord de démonstration

Cause : Commerce REST orders les critères de recherche ne renvoient pas les commandes ou split_cash_status champ ne se trouve pas dans la réponse REST.

Correctif:

Liste de contrôle de vérification

Toutes les ressources de cette série

Ressources de référence