Dela betalnings-POC: snabbreferens för självstudiekurser

På den här sidan sammanfattas hur de delade korrekturserierna för betalningar är ordnade. Den mappar varje numrerad källpromptfil till den publicerade Experience League-sidan, visar en föreslagen avsnittsordning för läsare och samlar in anteckningar för författare och underhållare.

Fil för fil-referens

Skapa en delad betalnings-POC: App Builder- och AI-verktyg

Source-etikett: 00_TUTORIAL_OVERVIEW.md (konceptuell översikt; den publicerade serien öppnas med den här sidan.)

Syfte: Introduktion och orientering för självstudien.

Varför det behövs: Ger utvecklare"varför" före"hur". Beskriver vad de kommer att bygga, vilka målgruppen är och kritiskt vad de måste anpassa om deras webbplats skiljer sig från en ren Luma-installation. Fungerar även som innehållsförteckning för resten av serien.

Användning av självstudiekursen: Öppningsavsnittet. Anger sammanhang före eventuella tekniska steg.

Delad betalnings-POC: arkitektur och designbeslut

Syfte: Detaljerad förklaring av alla arkitektoniska beslut i PoC.

Varför det behövs: Den vanligaste förvirringspunkten när du arbetar med den här PoC:n är att förstå varför något är i PHP jämfört med App Builder. Utan den här kontexten försöker utvecklare flytta saker som inte kan flyttas (som butikskreditprogram) och misslyckas. Det här dokumentet föregriper sådana fel med tydlig motivering.

Viktiga ämnen som behandlas:

Användning i självstudiekursen: “Arkitektur” eller “Så fungerar det”. Kan hoppas över av erfarna Commerce-utvecklare, men det är viktigt för App Builder-nykomlingar.

Delad betalnings-POC: förutsättningar och miljökonfiguration

Syfte: Slutför checklistan före flygning innan kod skrivs eller uppmaningar körs.

Varför det behövs: Installationsfasen har den högsta felfrekvensen i självstudiekurser. Det här dokumentet ser till att Commerce Admin är korrekt konfigurerad (exakt COD-titel, butikskrediter aktiverad, testkundens saldo, integrering skapad), att App Builder-projektet har I/O-händelser och att Commerce händelseleverantör är ansluten och att den lokala miljön har rätt versioner.

Betoningsobjekt:

Användning av självstudiekursen: “Förutsättningar” eller “Komma igång”. Ska fyllas i interaktivt - inte bara läsas.

Delad betalnings-POC: miljövariabelreferens

Syfte: Alla miljövariabler för alla tre komponenterna på ett och samma ställe.

Varför det behövs: Samma fyra OAuth-autentiseringsuppgifter visas i tre olika filer med olika variabelnamn (COMMERCE_* kontra COMMERCE_INTEGRATION_*). Genom att använda en enda referens förhindrar du felsökningen"varför fungerar inte" där en autentiseringsuppsättning har ett stavfel.

Komponenter som omfattas:

Användning av självstudiekurser: Referenssidofält eller konfigurationsavsnitt. Används även som ett tillägg till bygguppmaningarna.

Delad betalnings-POC: Meddelande från Commerce-modulen AI

Syfte: En fullständig, självständig AI-fråga om att generera hela Client_SplitPayment PHP-modulen.

Varför det behövs: Det här är den primära AI-byggartefakten för PHP-sidan. Det är skrivet så att en utvecklare utan PHP-erfarenhet kan skicka det till Cursor (med Claude) och få en fungerande modul. Varje fil anges, varje beteendekontrakt definieras, viktig implementeringsinformation inkluderas och kommandon för att aktivera modulen efteråt anges.

Täckning:

Använd självstudiekursen:“Bygg Commerce-modulen”. Själva uppmaningen är artefakten - utvecklarna kopierar den till sitt AI-verktyg och kör den.

Delad betalnings-POC: App Builder orchestrator AI-fråga

Syfte: En fullständig, självständig AI-fråga om att generera App Builder-programmet split-payment-orchestrator.

Varför det behövs: De fyra App Builder-åtgärderna (payment-orchestrator, payment-accept, payment-decline, demo-dashboard) är kärnan i"vad som flyttat ut ur PHP"-artikeln. Den här uppmaningen genererar alla med fullständiga beteendespecifikationer, korrekt app.config.yaml-struktur och händelseregistreringskonfiguration.

Täckning:

Användning i självstudiekursen:“Bygg App Builder-programmet”. Koppla till uppmaningen till modulen Commerce.

Delad betalnings-POC: AI-fråga för Experience Cloud UI-tillägg

Syfte: AI-fråga om att generera det valfria SDK-tillägget Experience Cloud Admin UI.

Varför det behövs: Demonstrationsrutan i orchestrator-prompten är avsiktligt grov - det är koncepttest, inte produktion. I det här avsnittet visas utvecklare nästa steg: bädda in den delade kontrollpanelen för betalningar i Commerce Admin Shell med hjälp av SDK för användargränssnittet för administratörer. Den saknades helt och hållet i de ursprungliga uppmaningarna.

Täckning:

Användning av självstudiekursen: Valfritt"Gå vidare" eller"Produktionssökväg". Kan hoppas över om kursen bara fokuserar på koden.

Delad betalnings-POC: testnings- och verifieringsguide

Syfte: Stegvis testguide som täcker alla komponenter i rätt verifieringsordning.

Därför behövs det: Att skapa komponenterna är halva arbetet. Utvecklare behöver en tydlig verifieringssökväg som börjar på den lägsta nivån (databaskolumner, REST-slutpunkter) och som bygger på hela flödet från början till slut. De ursprungliga prompterna hade en installationschecklista, men inget explicit testflöde.

Täckning:

Användning i självstudiekursen: “Testing” eller “Verification”. Även värdefull som felsökningsreferens.

Delad betalnings-POC: nästa steg efter konceptbeviset

Syfte: Färdkarta för att utveckla PoC till produktionsfärdiga mönster.

Varför det behövs: En PoC-självstudiekurs riskerar att lämna utvecklare med"vad nu?" känsla. Det här dokumentet mappar de naturliga framstegen från demo till produktion: ersätta demokontrollpanelen med ett Experience Cloud-tillägg, koppla ihop en verklig ERP, lägga till API Mesh, utöka App Builder arbetsflöde och checklista för produktionsdistribution.

Nyckelinnehåll:

Använd självstudiekursen: Avsnittet Nästa steg. Det är också användbart som samtalsstart för omfång i ett verkligt projekt.

Föreslagna självstudiekurser

En vanlig struktur för läsare är följande:

Viktiga anteckningar för författare till självstudiekurser

Vid antagande om Luma-tema: Varje byggprompt genererar kod för en ren Luma-installation. I självstudiekursen ska detta tydligt anges längst upp: utvecklare med anpassade utcheckningar måste anpassa LayoutProcessorPlugin-inmatningsbanorna och eventuellt RequireJS-konfigurationen. Seriens introduktions- och build-prompter innehåller anpassade hänvisningar för detta.

I PHP-modulen: I självstudiekursen anges inte PHP-koden som en klipp ut och klistra in-hämtning. AI-prompten genererar den. Detta är avsiktligt - det lär ut hur man använder AI för att skapa Commerce-tillägg, inte bara kopiera och klistra in mallplattan. Den genererade koden som visas i en ren miljö bör dock matcha arbetskoden i app/code/Client/SplitPayment/ exakt.

På tröskelvärdet 100 USD: Detta är ett hårdkodat PoC-värde. I självstudiekursen bör du komma ihåg att riktiga butiker kommer att vilja konfigurera detta via Commerce Admin-konfigurationen i stället för en kompileringskonstant.

Vid butikskreditberoende: Det delade betalningsflödet som skapat kräver Magento_CustomerBalance (den inbyggda butikskreditmodulen).

Relaterade POC-resurser för delad betalning