Création d’un PDC de paiement partagé : démonstration complète d’App Builder
Il s’agit de la présentation complète de la preuve de concept du paiement partagé basée sur Adobe Commerce et Adobe App Builder. La démonstration suppose que vous avez déjà utilisé les outils d’IA et une invite pour produire l’extension Commerce en cours de traitement et l’application App Builder. Cette vidéo montre ce qui se passe après la fusion de ce code, son déploiement sur un site web Adobe Commerce Cloud à l’aide du thème Luma natif et la mise en ligne du projet App Builder.
Un acheteur paie en partie en espèces et en partie en Store Credit. Commerce possède des extractions synchrones et les API dont le storefront a besoin ; App Builder gère l’orchestration, les workflows d’opérateur et les consommateurs d’événements d’E/S. L’implémentation de référence utilise un projet Commerce (PaaS) et le passage en caisse natif de Luma plutôt qu’un storefront Edge Delivery Services, qui reste un chemin d’accès courant pour de nombreux commerçants. Si vous utilisez Adobe Commerce as a Cloud Service dans une topologie différente, le code App Builder reste similaire, mais le storefront et le travail en cours semblent différents. Pour le code local, auto-hébergé et Commerce en mode cloud sur Luma, cette vidéo présente une répartition pratique entre le code en cours de traitement et App Builder pour de nouvelles fonctionnalités.
Vidéo
À qui s’adresse cette vidéo ?
- Architectes techniques planifiant l’extensibilité de Commerce
- Développeurs et développeuses mettant en œuvre des procédures de passage en caisse et des intégrations
- Équipes d’implémentation qui ont besoin d’une répartition réaliste entre PHP et App Builder
Configurer le scénario sur le storefront
Le compte de démonstration a Store Credit et vous voyez ce solde lors du passage en caisse. Ajoutez des produits jusqu’à ce que le total de la commande soit d’environ 80 $. Cette taille vous donne de l’espace pour afficher à la fois le chemin d’acceptation réussi et un chemin de refus, similaire à un déclin de carte, sans que les mathématiques ne vous combattent.
Split payment n’est proposé qu’aux clients connectés, car la session doit exposer le crédit de la boutique. Le passage en caisse des invités n’affiche pas l’option de partage.
- À l’étape Payment, choisissez la méthode Cash (la démonstration renomme Cash on delivery en Juste de l’argent).
- Une zone de paiement fractionné s’affiche sous le mode de paiement. Le champ Cash est prérempli sur le total de la commande et le composant lit les Store Credit de la session.
- Pour un panier d’environ 80 $, définissez 50 $ en espèces et 30 $ en crédit de magasin afin que le composant affiche 50 $ + 30 $ = 80 $.
- Lorsque les montants sont valides, passez la commande.
L’interface utilisateur déclenche un appel à une nouvelle API REST Commerce pour la division. Le passage en caisse reste synchrone : Commerce applique le crédit de magasin, stocke les lignes de fractionnement sur la commande et émet un événement d’E/S qu’App Builder consomme ultérieurement. La page de succès est immédiate pour le client.
Vérifier la commande dans l’administrateur Commerce
Dans Sales > Orders, ouvrez la nouvelle commande. La zone Payment information affiche le partage, par exemple 50 $ en espèces et 30 $ en crédit de magasin. Le statut est En attente lorsque l’argent n’est pas encore collecté ; le crédit de la boutique est déjà utilisé lors de la création de la commande.
Comments pouvez inclure du texte ajouté par App Builder. Le Payment orchestrator action dans App Builder a reçu l’événement d’E/S, vérifié les montants de partage et utilisé un REST authentifié pour ajouter des commentaires. Commerce traite cela comme tout autre appel REST et n’a pas besoin de connaître le rédacteur.
Utiliser le tableau de bord de l’opérateur App Builder (ERP ou back office)
Une expérience HTML simple s’exécute sous la forme d’une action web App Builder (aucune Admin pour cet affichage). Le tableau de bord appelle l’API REST Commerce Order et filtre sur En attente afin que vous puissiez trouver la composante en espèces de 50 $.
Vous intégrez généralement ce modèle à un outil ERP ou de fraude. Deux actions sont démontrées :
- Accepter — Confirme que l’argent a été reçu (en production, souvent un courrier automatisé provenant d’un tiroir-caisse ou d’un système de magasin).
- Refuser — Simule une fraude ou une étape de recouvrement ayant échoué (en production, généralement automatisée à partir de votre service des risques).
Accepter et terminer la commande
- Dans l’application App Builder, utilisez Accepter pour confirmer l’argent comptant.
- L’application appelle un nouveau point d’entrée Commerce qui finalise la ligne de trésorerie. Le flux de commande de base (facturation et, dans cette version, expédition automatisée) s’exécute avec le comportement natif de Commerce. Aucun de ces chemins ne nécessite la présence d’un humain dans Admin ; l’orchestration et le point d’entrée résident dans App Builder.
Actualisez la même commande dans Admin : le statut passe à Terminé lorsque l’argent est accepté, avec la facture et, lorsque le produit est livrable, une expédition pour raccourcir le cycle de vie complet dans la démonstration.
Refuser et annuler
- Ouvrez une commande préconfigurée qui se trouve toujours dans le scénario de déclin.
- Dans l’application App Builder, utilisez Refuser pour simuler une fraude ou un échec de collecte.
- En Admin, la commande est Annulée. L’historique indique un statut d’encaissement refusé, les commentaires expliquent le résultat, l’acheteur n’a pas été facturé la ligne de crédit du magasin comme s’il s’agissait d’une vente finale, et la facture de crédit du magasin est annulée avec l’annulation. Un système de production avertirait également le client et libérerait tout blocage de stock ou de service.
Seuil total des commandes (validation avant création de la commande)
La configuration d’App Builder ou d’Commerce peut prendre en charge les règles de validation ; cette version bloque les commandes supérieures à 100 de la valeur du panier (limite de démonstration que vous pouvez modifier). Une vérification de valeur n’est pas la règle métier la plus courante (les vérifications d’inventaire ou de disponibilité sont plus courantes), mais elle indique que la validation peut s’exécuter au Payment dans Commerce avant la création d’une commande, tandis qu’App Builder gère toujours l’automatisation du suivi.
- Ajoutez des produits jusqu’à ce que le total soit supérieur 100 de dollars.
- Le UI de fractionnement apparaît toujours ; le résultat de dépassement de limite n’apparaît que sur Ordre de placement.
- L’acheteur voit une erreur générique telle que Le paiement n’a pas pu être traité. Réessayez ou contactez l’assistance.
- Le cart reste inchangé afin que le client puisse réduire le total, choisir une autre méthode ou contacter l’assistance.
Une note de risque, une règle de région ou autre règle similaire peut s’appliquer ici ; Commerce bloque la commande et App Builder pouvez posséder des notifications et un travail sur les dossiers après coup.
Commerce on-premise, Commerce en mode cloud et Adobe Commerce as a Cloud Service
La présentation correspond Adobe Commerce une infrastructure que vous gérez ou Commerce in the cloud (PaaS) avec une vitrine traditionnelle. Pour les Adobe Commerce as a Cloud service (SaaS) avec un front-end différent et aucun module en cours de traitement de cette forme, les éléments d’App Builder sont largement les mêmes, tandis que le storefront et le travail d’extension seraient différents. Dans tous les cas, le même principe s’applique : Commerce ce qui doit se produire dans la requête Commerce et utilisez App Builder pour le reste de l’expérience.