DocumentatieCommerceVideo's en zelfstudies

Een gesplitste betalingsconcepttest maken: volledige demo voor App Builder

Laatst bijgewerkt: 28 april 2026

Gemaakt voor:

  • Intermediate
  • Developer
  • Leader
  • User

Dit is de volledige doorlichting van het op Adobe Commerce en Adobe App Builder gebouwde gesplitste betalingsbewijs van het concept. In de demo wordt ervan uitgegaan dat u al AI-gereedschappen hebt gebruikt en wordt u gevraagd de in-process Commerce-extensie en de App Builder-app te produceren. In deze video ziet u wat er gebeurt nadat de code is samengevoegd, die is geïmplementeerd op een Adobe Commerce Cloud-website met behulp van het native Luma-thema en het App Builder-project live is.

Een winkelier betaalt met deelcontant geld en een deel Store Credit . Commerce is eigenaar van synchrone uitchecken en de API’s die de winkel nodig heeft; App Builder handelt organisatie, workflows van operatoren en I/O-gebeurtenisconsumenten af. In de voorbeeldimplementatie wordt gebruikgemaakt van een Commerce-project (PaaS) en de native afhandeling van het Luma in plaats van een Edge Delivery Services-winkelcentrum, dat voor veel handelaren nog steeds een gemeenschappelijk pad is. Als u Adobe Commerce als dienst van de Wolk in een verschillende topologie gebruikt, blijft de code van App Builder gelijkaardig maar het storefront en het in-proceswerk zouden verschillend kijken. In deze video wordt een praktische splitsing getoond tussen code in het proces en App Builder voor nieuwe functionaliteit voor op locatie, zelfgehoste en Commerce in de cloud op Luma.

Video

https://video.tv.adobe.com/v/3484105?captions=dut&learn=on
https://video.tv.adobe.com/vc/3484105/dut.json

Voor wie is deze video?

  • Technische architecten die de uitbreidbaarheid van Commerce plannen
  • Ontwikkelaars die uitchecken en integratie implementeren
  • Implementatieteams die behoefte hebben aan een realistische splitsing tussen PHP en App Builder

Het scenario instellen op de winkel

Het demo-account heeft Store Credit en u ziet die balans bij de afhandeling. Voeg producten toe tot het ordertotaal ongeveer $80 is. Deze grootte geeft u ruimte om zowel het geslaagde acceptatiepad als een neerzetpad te tonen, vergelijkbaar met een kaartverlies, zonder dat u met de wiskunde hoeft te vechten.

Split payment wordt alleen aangeboden aan klanten met een aanmelding, omdat tijdens de sessie opslagkredieten beschikbaar moeten worden gesteld. Bij het uitchecken door gasten wordt de splitsingsoptie niet weergegeven.

  1. Voor de Payment stap, kies de cash methode (de demo anders noemt Cash on delivery aan enkel Geld).
  2. Onder de betalingsmethode wordt een betalingsgebied in gedeelten weergegeven. Het veld Contant wordt voorgevuld tot het totaal van de bestelling en de component leest Store Credit van de sessie.
  3. Voor een ~$80 kar, plaats $50 contant geld en $30 opslagkrediet zodat toont de component $50 + $30 = $80.
  4. Wanneer de bedragen geldig zijn, plaatst u de bestelling.

De gebruikersinterface activeert een aanroep van een nieuwe Commerce REST API voor de splitsing. Uitchecken blijft synchroon: Commerce past winkelkrediet toe, slaat gesplitste regels op de bestelling op en geeft een I/O-gebeurtenis die App Builder later gebruikt. De succespagina is direct voor de klant.

De bestelling in de Commerce-beheerder bekijken

Open de nieuwe volgorde in Sales > Orders . In het gebied Payment information wordt de splitsing weergegeven, bijvoorbeeld $50 cash en $30 store credit. De status is in afwachting wanneer het geld nog niet wordt verzameld; de opslagkredieten worden reeds genomen wanneer de orde wordt gecreeerd.

Comments kan tekst bevatten die door App Builder is toegevoegd. De Payment orchestrator action in App Builder heeft de I/O-gebeurtenis ontvangen, de gesplitste hoeveelheden gecontroleerd en de geverifieerde REST-gebeurtenis gebruikt om opmerkingen toe te voegen. Commerce behandelt dat zoals elke andere vraag van het REST en te hoeven niet om de schrijver te kennen.

Het dashboard voor App Builder-operatoren (ERP of back office) gebruiken

Een eenvoudige HTML-ervaring wordt uitgevoerd als een App Builder webactie (geen Admin voor deze weergave). Het dashboard roept Commerce Order REST API en filters aan In afwachting van zodat kunt u $50 geldbeen vinden.

Dit patroon wordt meestal geïntegreerd met een ERP- of fraudeprogramma. Er worden twee acties getoond:

  • keurt goed — bevestigt dat het geld (in productie, vaak een geautomatiseerde post van een kasbak of opslagsysteem) werd ontvangen.
  • Verval — Simuleert fraude of een ontbroken inzamelingsstap (in productie, gewoonlijk geautomatiseerd van uw risicodienst).

Accepteer en voltooi de orde

  1. In App Builder app, gebruik Accepteren om geld te bevestigen.
  2. De app roept een nieuw Commerce eindpunt aan dat de cash line voltooit. De kernorderstroom (facturering, en in deze build een geautomatiseerde verzending) wordt uitgevoerd met native Commerce -gedrag. Geen van die paden vereist een mens in Admin; orkestatie en het eindpunt leven in App Builder.

Vernieuw de zelfde orde in Admin: statusbewegingen aan Volledige wanneer het geld, met factuur en, waar het product kan worden verscheept, een lading wordt goedgekeurd om de volledige levenscyclus in de demo te verkorten.

Weigeren en annuleren

  1. Open een vooraf gebouwde orde die nog in het dalingsscenario is.
  2. In App Builder app, gebruik Weigeren om een fraude of inzamelingsmislukking te simuleren.
  3. In Admin, wordt de orde geannuleerd ​. De geschiedenis toont een verminderde kasstatus, opmerkingen verklaren het resultaat, de verkoopster werd niet in rekening gebracht op de store-credit-line alsof het een eindverkoop was, en de store-credit factuur wordt geannuleerd. Een productiesysteem zou ook de klant op de hoogte stellen en eventuele voorraden in voorraad of service vrijgeven.

Totale drempel voor bestelling (validatie voordat de bestelling wordt gemaakt)

App Builder of Commerce -configuratie kan validatieregels ondersteunen. Deze bouwt ordes boven $100 in de waarde van de winkelwagentje (een demo-uiteinde dat u kunt wijzigen). Een waardecontrole is niet de meest gangbare bedrijfsregel: inventarisatie of beschikbaarheidscontroles zijn meer standaard, maar het toont aan dat validatie kan worden uitgevoerd bij Payment in Commerce voordat een bestelling wordt gemaakt, terwijl App Builder nog steeds vervolgautomatisering afhandelt.

  1. Voeg producten toe tot het totaal boven $100 is.
  2. De gespleten UI verschijnt nog; het overlimietresultaat slechts oppervlakken op orde van de Plaats.
  3. De verkoopster ziet een generische fout zoals Betaling kon niet worden verwerkt. Probeer het opnieuw of neem contact op met de technische ondersteuning.
  4. cart blijft ongewijzigd, zodat de klant het totaal kan verlagen, een andere methode kan kiezen of contact kan opnemen met de ondersteuningsafdeling.

Een risicoscore, regioregel of vergelijkbaar kan hier worden ingevoegd. Commerce blokkeert de volgorde en App Builder kan na dit feit meldingen en casewerk bezitten.

Commerce op gebouw, Commerce in de wolk, en Adobe Commerce als dienst van de Wolk

De doorloop past Adobe Commerce aan op een infrastructuur die u beheert of Commerce in the cloud (PaaS) aan op een traditionele winkelachtergrond. Voor Adobe Commerce as a Cloud service (SaaS) met een verschillend vooreind en geen module in procesvorm in deze vorm, zijn de stukken van App Builder grotendeels het zelfde, terwijl de opslag en de uitbreidingswerk verschillend zouden zijn. In alle gevallen geldt hetzelfde principe: laat Commerce doen wat er moet gebeuren binnen de Commerce request en gebruik App Builder voor de rest van de ervaring.

Gerelateerde gesplitste betalingen POC-middelen

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