DocumentatieCommerceVideo's en zelfstudies

Gesplitste betalingsconcepttest: volgende stappen na conceptbewijs

Laatst bijgewerkt: 28 april 2026

Gemaakt voor:

  • Intermediate
  • Developer
  • Leader
  • User

Het demo dashboard en het simulatiescript u in dit leerprogramma bouwde zijn opzettelijk ruw. Ze bestaan om het patroon te bewijzen. Deze pagina beschrijft een praktische weg van concepttest aan productie-stijl App Builder ontwikkeling.

Stap 1 — Vervang het demo-dashboard met een Experience Cloud UI-extensie

De webactie demo-dashboard dient HTML van een tekenreeks binnen een functie Node.js. Het werkt, maar het is niet het productiepatroon.

De juiste vervanging is de extensie commerce-backend-ui-1 in commerce-checkout-starter-kit — een React-toepassing die is ingesloten in de Commerce Admin Shell via de Adobe Admin UI SDK. Zie ​ Gesplitste betalingsPOC: Experience Cloud UI uitbreidingAI herinnering ​ voor de generatieherinnering.

wat verandert:

  • Operatoren melden zich aan via Commerce Admin Shell (IMS-verificatie in plaats van een gedeeld geheim)
  • De orderlijst gebruikt de IMS-tokencontext — geen demogeheim nodig
  • Acties accepteren/afwijzen vallen binnen het bereik van de IMS-identiteit van de operator
  • De gebruikersinterface is ingesloten in Commerce Admin bij de URL waarvan de Commerce-beheerders al weten

wat het zelfde blijft:

  • payment-accept en payment-decline App Builder-acties blijven ongewijzigd
  • Commerce REST-eindpunten blijven ongewijzigd
  • De PHP module is ongewijzigd

Stap 2 — Sluit een Real ERP aan

De accepteer-/afwijzingsstroom in deze concepttest wordt aangestuurd door een mens die op een knop klikt. In productie, wordt dit gedreven door uw ERP, CRM, of betalingsbewerker.

het integratiepatroon:

  1. Het ERP-systeem legt contant geld vast en roept POST /payment-accept (de App Builder-webactie-URL) aan met { orderId: <entity_id> }
  2. App Builder valideert de aanroep (token of API-sleutel voor toonder — voeg automatische middleware toe aan payment-accept)
  3. App Builder roept Commerce REST aan cash-received
  4. Commerce factureert en verzendt de bestelling

Geen PHP wijzigingen vereist. Het REST-oppervlak is er al. De App Builder-actie heeft alleen een beveiligde aanroeper nodig in plaats van een dashboardknop.

de opties van de Authentificatie voor de bezoeker ERP:

  • Adobe I/O Runtime ondersteunt require-adobe-auth: true voor IMS-tokens (als uw ERP een IMS-token kan krijgen)
  • Voor niet-Adobe-systemen: voeg een eenvoudige API-toetscontrole toe in de handeling payment-accept (controleer een koptekst op een geheim dat is opgeslagen in de omgeving van de handeling)

Stap 3 — API-net toevoegen als een brokerlaag

App Builder roept Commerce REST momenteel rechtstreeks aan met OAuth 1.0a-referenties. Voor grotere implementaties biedt Adobe API Mesh een beheerde gatewaylaag tussen App Builder en Commerce.

Voordelen:

  • Gecentraliseerd credentiebeheer — API Mesh heeft de Commerce-referenties; App Builder roept API Mesh aan
  • Transformatie aanvragen — App Builder-nuttige ladingen toewijzen aan Commerce REST-vormen zonder de App Builder-actie te wijzigen
  • Snelheidsbeperking en caching — Commerce beschermen tegen gebeurtenisverkeer op grote volumes

het patroon:

  • Vervang createCommerceClient(params, logger) aanroepen door aanroepen van het eindpunt van het API-net
  • API-net verwerkt handtekeningen van OAuth naar Commerce

Stap 4 — Verlaag de PHP-voetafdruk

De huidige PHP module behandelt vijf dingen die in-proces moeten blijven (zie ​ Gesplitste betaling POC: architectuur en ontwerpbesluiten ​). Naarmate het Adobe Commerce API-oppervlak rijpt, kunnen sommige van de volgende zaken bewegen:

potentieel beweegbaar in de toekomst:

  • De REST API voor archiefkredieten is aan het evolueren — toekomstige versies kunnen het toepassen van creditpost-order of inactieve kaarten ondersteunen
  • Naarmate meer Commerce-bewerkingen asynchroon-veilig worden, kan de drempelbeveiliging worden verplaatst naar een preorder API-netoplosser

niet beweegbaar (architecturale beperkingen):

  • Voor het manipuleren van aanhalingstekens vóór placeOrder() is altijd procescode vereist, tenzij Commerce een duidelijke haak via een API-eerste extensiepunt beschikbaar maakt
  • De REST eindpunten (/V1/split-payment/*) zijn specifiek voor deze functie; zij leven in Commerce omdat zij de Commerce-interne diensten roepen

Stap 5 — Meer workflow toevoegen aan App Builder

De huidige PoC doet één ding: let op ordetelling, dan laat goedkeuren/verwerpen toe. Natuurlijke extensies:

fraude het scoren alvorens goed te keuren:
In payment-orchestrator roept u na het opnemen van contant geld in behandeling een API voor het zoeken naar fraude op voordat het orchestratieresultaat als definitief wordt beschouwd. Als de score boven een drempelwaarde ligt, wordt automatisch afgebroken in plaats van te wachten op actie van de operator.

e-mails van het Bericht:
Als payment-accept succesvol is, activeert u een e-mail (via Adobe Campaign, SendGrid of een HTTPS API) om de klant te laten weten dat zijn contante betaling is bevestigd.

het punt van de Loyalty verleent:
Nadat cash is bevestigd, roep een loyaliteit API aan toekenningspunten. Dit is pure App Builder — geen PHP vereist.

Onderbreking behandeling:
Voeg een geplande App Builder-actie toe (met cron in app.config.yaml ) die scant naar bestellingen met split_cash_status = 'pending' ouder dan X dagen en deze automatisch decodeert.

Stap 6 — Distributie naar productie

De concepttest is geconfigureerd voor de Stage -werkruimte. Verplaatsen naar productie:

# Switch to production workspace
aio app use
# Select Production workspace

# Update .env for production
# (same credentials, but production Commerce base URL)

# Deploy
aio app deploy

Checklist voor productiereedheid:

  • [ ] DEMO_UI_SECRET set (of demo-dashboard vervangen door Experience Cloud-gebruikersinterface)
  • [ ] LOG_LEVEL=warn of error in productie (niet debug)
  • [ ] PAYMENT_THRESHOLD komt overeen met Commerce-productieconfiguratie
  • [ ] Referenties voor Commerce-integratie in .env zijn bedoeld voor een speciale productieintegratie (niet in fasen)
  • [ ] Snelle IP-lijst van gewenste personen bijgewerkt met App Builder-productieegress-IP’s (Commerce Cloud)
  • [ ] I/O-gebeurtenisregistratie bevestigd in productiewerkruimte

Evolutiediagram architectuur

PoC (this tutorial)
┌─────────────────────────────────────────────────┐
│  Commerce                 App Builder            │
│  ┌─────────────┐         ┌──────────────────┐   │
│  │  PHP Module │◄────────│ payment-orchestr │   │
│  │  REST API   │────────►│ payment-accept   │   │
│  │  Checkout UI│         │ payment-decline  │   │
│  └─────────────┘         │ demo-dashboard   │   │
└─────────────────────────────────────────────────┘

Phase 2: Experience Cloud UI
┌─────────────────────────────────────────────────┐
│  Commerce                 App Builder            │
│  ┌─────────────┐         ┌──────────────────┐   │
│  │  PHP Module │◄────────│ payment-orchestr │   │
│  │  REST API   │────────►│ payment-accept   │   │
│  │  Checkout UI│         │ payment-decline  │   │
│  │             │         │ Admin UI ext.    │   │
│  └─────────────┘         └──────────────────┘   │
└─────────────────────────────────────────────────┘

Phase 3: Real ERP + API Mesh
┌──────────────────────────────────────────────────────────┐
│  ERP  ──►  App Builder  ──►  API Mesh  ──►  Commerce     │
│            (orchestrator)   (gateway)    (PHP module      │
│            (accept)                      REST surface)    │
└──────────────────────────────────────────────────────────┘

Belangrijke verwijzingen

Gerelateerde gesplitste betalingen POC-middelen

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