Skapa en delad betalning POC: App Builder fulldemo

Det här är den kompletta genomgången av koncepttestet som bygger på Adobe Commerce och Adobe App Builder. Demon förutsätter att du redan har använt AI-verktyg och en uppmaning att skapa det pågående Commerce-tillägget och App Builder-appen. Den här videon visar vad som händer efter att koden har slagits samman, distribuerats till en Adobe Commerce Cloud-webbplats med det inbyggda Luma-temat och App Builder-projektet är live.

En kund betalar med delvis kontanter och delar Store Credit. Commerce äger synkron utcheckning och de API:er som butiken behöver; App Builder hanterar orkestrering, operatorarbetsflöden och I/O-händelsekonsumenter. Referensimplementeringen använder ett Commerce-projekt (PaaS) och den inbyggda Luma-utcheckningen i stället för en Edge Delivery Services-butik, som fortfarande är en gemensam väg för många handlare. Om du använder Adobe Commerce som en molntjänst i en annan topologi förblir App Builder-koden densamma, men butiken och pågående arbete ser annorlunda ut. För lokala, självhanterade och Commerce i molnet på Luma visar den här videon en praktisk uppdelning mellan kod i processen och App Builder för nya funktioner.

Video

Vem är den här videon till?

  • Teknikarkitekter som planerar Commerce utbyggbarhet
  • Utvecklare som implementerar utcheckning och integreringar
  • Implementeringsteam som behöver en realistisk delning mellan PHP och App Builder

Ställ in scenariot på butiken

Demonskontot har Store Credit och du ser balansen i kassan. Lägg till produkter tills ordersumman är cirka 80 dollar. Med den storleken får du utrymme att visa både den lyckade sökvägen för godkännande och en avböjningsväg, som liknar en kortansökan, utan att matematiken strider mot dig.

Split payment erbjuds endast inloggade kunder eftersom sessionen måste visa butikskrediter. Gästutcheckning visar inte delningsalternativet.

  1. I steget Payment väljer du kassametod (demonstrationen byter namn från Cash on delivery till Endast kontanter).
  2. Ett delat betalningsområde visas under betalningsmetoden. Kassafältet är förifyllt till ordersumman och komponenten läser Store Credit från sessionen.
  3. För en kundvagn på ~ 80 dollar anger du $50 kontanter och $30 butikskredit så att komponenten visar $50 + $30 = $80.
  4. När beloppen är giltiga lägger du ordern.

Gränssnittet utlöser ett anrop till ett nytt Commerce REST API för delningen. Utcheckningen förblir synkron: Commerce tillämpar butikskrediter, lagrar delade rader på ordern och genererar en I/O-händelse som App Builder förbrukar senare. Framgångssidan är omedelbar för kunden.

Granska beställningen i Commerce-administratören

Öppna den nya ordningen i Sales > Orders. Området Payment information visar delningen, till exempel $50 kontanter och $30 butikskredit. Statusen är Väntande när kontanter ännu inte har samlats in. Butikskrediten tas redan när ordern skapas.

Comments kan innehålla text som App Builder har lagt till. Payment orchestrator action i App Builder har tagit emot I/O-händelsen, kontrollerat de delade beloppen och använt autentiserad REST för att lägga till kommentarer. Commerce behandlar det som vilket REST-anrop som helst och behöver inte känna till skrivaren.

Använda App Builder kontrollpanel (ERP eller back office)

En enkel HTML-upplevelse körs som en App Builder-webbåtgärd (ingen Admin för den här vyn). Kontrollpanelen anropar REST-API:t Commerce Order och filter till Väntande så att du kan hitta kontantbenet på 50 USD.

Du integrerar vanligtvis mönstret med ett ERP- eller bedrägeriverktyg. Två åtgärder visas:

  • Acceptera - Bekräftar att kontanter mottogs (i produktion, ofta en automatiserad post från en kassalåda eller ett butikssystem).
  • Avböj - Simulerar bedrägeri eller ett misslyckat insamlingssteg (i produktion, oftast automatiserat från din risktjänst).

Acceptera och slutför beställningen

  1. Använd Acceptera för att bekräfta kontanter i appen App Builder.
  2. Appen anropar en ny Commerce-slutpunkt som slutför kassaraden. Kärnorderflödet (fakturering och i det här bygget en automatiserad leverans) körs med det inbyggda Commerce-beteendet. Ingen av dessa sökvägar kräver en människa i Admin. Orchestration och slutpunkten finns i App Builder.

Uppdatera samma order i Admin: statusen ändras till Fullständig när kontanterna accepteras, med faktura och, där produkten kan skickas, en leverans för att korta ned hela livscykeln i demon.

Avböj och avbryt

  1. Öppna en fördefinierad order som fortfarande befinner sig i avböjningsscenariot.
  2. I appen App Builder använder du Avböj för att simulera ett bedrägeri eller ett samlingsfel.
  3. I Admin är beställningen Avbruten. Historien visar att kunden har avböjt kassastatus, kommentarer förklarar resultatet, att kunden inte debiterades butikskreditraden som om den vore en slutförsäljning och att butikskreditfakturan annulleras med annulleringen. Ett produktionssystem skulle också meddela kunden och frisläppa eventuella förvaringsmöjligheter för lager eller tjänster.

Total ordertröskel (validering innan ordern skapas)

App Builder- eller Commerce-konfigurationen kan ha stöd för valideringsregler. Den här versionen blockerar beställningar över $100 i kundvagnsvärde (en demoände som du kan ändra). En värdekontroll är inte den vanligaste affärsregeln - inventerings- eller tillgänglighetskontroller är vanligare - men den visar att validering kan köras Payment i Commerce innan en order skapas, medan App Builder fortfarande hanterar uppföljningsautomatisering.

  1. Lägg till produkter tills summan överstiger $100.
  2. Delningen UI visas fortfarande. Övergränssresultatet ger bara ytor på Monteringsordning.
  3. Köparen ser ett allmänt fel som Betalningen kunde inte bearbetas. Försök igen eller kontakta supporten.
  4. cart är oförändrad så att kunden kan sänka summan, välja en annan metod eller kontakta supporten.

En riskpoäng, regionregel eller liknande kan kopplas in här. Commerce blockerar ordningen och App Builder kan äga meddelanden och ärendearbete efter uppgiften.

Commerce lokalt, Commerce i molnet och Adobe Commerce som en molntjänst

Genomgången matchar Adobe Commerce i en infrastruktur som du hanterar eller Commerce in the cloud (PaaS) med en traditionell butik. För Adobe Commerce as a Cloud service (SaaS) med en annan front end och ingen in-process-modul i den här formen är App Builder-delarna i stort sett desamma, medan storefront- och tilläggsarbetet skulle vara annorlunda. I samtliga fall gäller samma princip: låt Commerce göra det som måste hända i Commerce-begäran och använd App Builder för resten av upplevelsen.

Relaterade POC-resurser för delad betalning

recommendation-more-help
commerce-learn-help-home