Betalingsconcepttest splitsen: snelle naslaggids

Deze pagina geeft een overzicht van de manier waarop de modelleerserie voor het testen van gesplitste betalingen is georganiseerd. Elk genummerd bronpromptbestand wordt toegewezen aan de gepubliceerde Experience League-pagina, er wordt een voorgestelde sectievolgorde voor lezers weergegeven en er worden notities voor auteurs en onderhoudspersonen verzameld.

File-by-file referentie

​ creeer een gespleten betaling POC: App Builder en AI hulpmiddelen ​

Source etiket: 00_TUTORIAL_OVERVIEW.md (conceptueel overzicht; de gepubliceerde reeks opent met deze pagina.)

Doel: Inleiding en richtlijn voor het leerprogramma.

waarom het nodig is: geeft ontwikkelaars "waarom"vóór “hoe.” Verklaart wat zij zullen bouwen, wie het publiek is, en kritisch — wat zij moeten aanpassen als hun plaats van een schone installatie van de Luma verschilt. Deze fungeert ook als inhoudsopgave voor de rest van de reeks.

gebruik van de Leerprogramma’s: Openende sectie. Stelt context in vóór technische stappen.

​ Gesplitste betaling POC: architectuur en ontwerpbesluiten ​

Doel: Diep-duik verklaring van elk architecturaal besluit in PoC.

waarom het nodig is: het enige gemeenschappelijkste punt van verwarring wanneer het werken met dit PoC begrijpt waarom iets in PHP tegenover App Builder is. Zonder deze context, proberen de ontwikkelaars om dingen te bewegen die niet kunnen worden bewogen (zoals de toepassing van het opslagkrediet) en ontbreken. In dit document worden deze fouten met duidelijke argumenten voorkomen.

Belangrijkste behandelde onderwerpen:

{het gebruik van 0} Leerprogramma:"Architectuur"of "hoe het"sectie"werkt. Kan door ervaren Commerce-ontwikkelaars worden overgeslagen, maar is essentieel voor App Builder-nieuwkomers.

​ Gesplitste betaling POC: eerste vereisten en milieu opstelling ​

Doel: Volledige pre-vlucht checklist alvorens om het even welke code wordt geschreven of de herinneringen worden in werking gesteld.

waarom het nodig is: de opstellingsfase heeft het hoogste mislukkingstarief in leerprogramma’s. Dit document zorgt ervoor dat Commerce Admin correct is geconfigureerd (exacte COD-titel, opslagkrediet ingeschakeld, evenwicht van de testklant, integratie tot stand gebracht), dat het App Builder-project I/O-gebeurtenissen heeft en dat de Commerce-gebeurtenisprovider is aangesloten, en dat de lokale omgeving de juiste versies heeft.

punten van de Nadruk:

{het gebruik van 0} Leerprogramma:"Eerste vereisten"of "Begonnen het worden"sectie. Moet interactief worden ingevuld — niet alleen lezen.

​ Gesplitste betaling POC: de verwijzing van de milieuvariabelen ​

Doel: Alle milieuvariabelen voor alle drie componenten in één plaats.

waarom het nodig is: De zelfde vier geloofsbrieven OAuth verschijnen in drie verschillende dossiers met verschillende veranderlijke namen (COMMERCE_* tegenover COMMERCE_INTEGRATION_*). Het hebben van één enkele verwijzing verhindert "waarom niet dit het werk"zuiveren waar één credentiële reeks een typefout heeft.

Bedekte Componenten:

gebruik van de Leerprogramma’s: sidebar van de Verwijzing of "Configuratie"sectie. Wordt ook gebruikt als een begeleider van de build-vragen.

​ Gesplitste betalingsPOC: de moduleAI van Commerce herinnering ​

Doel: Volledige, op zichzelf staande herinnering AI om de volledige Client_SplitPayment PHP module te produceren.

waarom het nodig is: dit is het primaire AI bouwwerk vervorming voor PHP kant. Het is zo geschreven dat een ontwikkelaar zonder PHP-ervaring het kan overdragen aan Cursor (met Claude) en een werkende module krijgt. Elk dossier wordt gespecificeerd, wordt elk gedragscontract bepaald, worden de kritieke implementatienota’s omvat, en de bevelen om de module achteraf toe te laten worden verstrekt.

Coverage:

Tutorial use: “Build the Commerce module” section. The prompt itself is the artifact — developers copy it into their AI tool and run it.

Split payment POC: App Builder orchestrator AI prompt

Purpose: Complete, self-contained AI prompt to generate the split-payment-orchestrator App Builder application.

Why it’s needed: The four App Builder actions (payment-orchestrator, payment-accept, payment-decline, demo-dashboard) are the core of the “what moved out of PHP” story. This prompt generates all of them with full behavioral specifications, correct app.config.yaml structure, and the event registration configuration.

Coverage:

Tutorial use: “Build the App Builder application” section. Companion to the Commerce module prompt.

Split payment POC: Experience Cloud UI extension AI prompt

Purpose: AI prompt to generate the optional Experience Cloud Admin UI SDK extension.

Why it’s needed: The demo dashboard in the orchestrator prompt is intentionally rough — it is proof-of-concept, not production. Deze sectie toont ontwikkelaars de volgende stap: het inbedden van het gesplitste betalingsdashboard in Commerce Admin Shell gebruikend Admin UI SDK. Het ontbrak volledig uit de oorspronkelijke aanwijzingen.

Coverage:

{het gebruik van 0} Leerprogramma:Facultatieve "Bewegend verder"of "de weg van de Productie"sectie. Kan worden overgeslagen als de zelfstudie alleen op de concepttest is gericht.

​ Gesplitste betaling POC: het testen en de controlegids ​

Doel: Step-by-step het testen gids die elke component in de correcte verificatieorde behandelt.

waarom het nodig is: Bouwend de componenten is de helft van het werk. De ontwikkelaars hebben een duidelijk controlepad nodig dat van het laagste niveau (gegevensbestandkolommen, REST eindpunten) begint en aan de volledige stroom van begin tot eind bouwt. De originele herinneringen hadden een opstelling controlelijst maar geen expliciete testende stroom.

Coverage:

gebruik van de Leerprogramma’s: "het Testen"of de sectie van de “Verificatie”. Ook waardevol als het oplossen van problemenverwijzing.

​ Gesplitste betaling POC: volgende stappen na het bewijs van concept ​

Doel: Roadmap voor het evolueren van PoC in productie-klaar patronen.

waarom het nodig is: een PoC leerprogramma’s brengt het risico van verlatende ontwikkelaars met “wat nu?” gevoel. In dit document worden de natuurlijke progressies van demo naar productie in kaart gebracht: het demo-dashboard vervangen door een Experience Cloud-extensie, een echte ERP verbinden, API-net toevoegen, de App Builder-workflow uitbreiden en de checklist voor productietoepassingen.

Zeer belangrijke inhoud:

{het gebruik van 0} Zelfstudie:"Volgende stappen"sluitende sectie. Ook nuttig als gesprekstarter voor het scoping van een echt project.

Voorgestelde zelfstudiesecties

Op basis van deze bestanden bestaat een standaardstructuur voor lezers uit:

Belangrijke opmerkingen voor auteurs van zelfstudies

op de het themaveronderstelling van de Luma: Elke bouwt herinnering produceert code voor een schone installatie van de Luma. In de zelfstudie moet dit duidelijk bovenaan worden vermeld — ontwikkelaars met aangepaste kassingen moeten de injectiepaden van LayoutProcessorPlugin en mogelijk de configuratie RequireJS aanpassen. De reeksinleiding en bouwstijlherinneringen omvatten aanpassingscallouts voor dit.

op de PHP module: De leerprogramma uitdrukkelijk verstrekt de PHP code niet als kopiëren-deegdownload. De AI herinnering produceert het. Dit is opzettelijk — het leert het patroon van het gebruiken van AI om uitbreidingen van Commerce tot stand te brengen, niet alleen kopiëren-kleeft boilerplate. De gegenereerde code moet echter exact overeenkomen met de code in app/code/Client/SplitPayment/ wanneer deze wordt gevraagd naar een schone omgeving.

op de drempel $100: Dit is een hard-gecodeerde waarde PoC. In de zelfstudie wordt opgemerkt dat echte winkels dit via de Commerce Admin-configuratie willen configureren in plaats van een constante bij compilatie.

op de afhankelijkheid van de opslagkredieten: De gespleten betalingsstroom zoals gebouwd vereist Magento_CustomerBalance (de inheemse module van de opslagkrediet).

Gerelateerde gesplitste betalingen POC-middelen