Dokumentation Commerce Videofilmer och självstudiekurser

Dela betalnings-POC: nästa steg efter konceptbeviset

Senast uppdaterad: 28 april 2026

Skapat för:

Intermediate
Developer
Leader
User

Den demokontrollpanel och det simuleringsskript du har skapat i den här självstudiekursen är avsiktligt grova. De finns för att bevisa mönstret. På den här sidan beskrivs en praktisk väg från konceptbevis till produktionsbaserad App Builder-utveckling.

Steg 1 - Ersätt demokontrollpanelen med ett Experience Cloud UI-tillägg

Webbåtgärden demo-dashboard skickar HTML från en sträng inuti en Node.js-funktion. Det fungerar, men det är inte produktionsmönstret.

Den rätta ersättningen är tillägget commerce-backend-ui-1 i commerce-checkout-starter-kit - ett React-program som är inbäddat i Commerce Admin Shell via Adobe Admin UI SDK. Se Delad betalnings-POC: AI-fråga för Experience Cloud UI-tillägg för att få en genereringsfråga.

Vilka ändringar:

Operatörer loggar in via Commerce Admin Shell (IMS-autentisering i stället för en delad hemlighet)
I orderlistan används IMS-tokenkontexten - ingen demohemlighet behövs
Godkänn/avböj-åtgärder omfattas av operatörens IMS-identitet
Gränssnittet är inbäddat i Commerce Admin på den URL som Commerce-administratörer redan kan

Vad är detsamma:

payment-accept och payment-decline App Builder-åtgärder ändras inte
Commerce REST-slutpunkter ändras inte
PHP-modulen är oförändrad

Steg 2 - Ansluta en verklig ERP

Godkänn/avvisa-flödet i denna PoC-fil styrs av att en person klickar på en knapp. I produktion styrs detta av ERP, CRM eller betalningsprocessor.

Integreringsmönstret:

ERP-systemet hämtar kontanter och anropar POST /payment-accept (App Builder webbåtgärds-URL) med { orderId: <entity_id> }
App Builder validerar anropet (innehavartoken eller API-nyckel - lägg till auth middleware i payment-accept)
App Builder anropar Commerce REST cash-received
Commerce fakturerar och skickar ordern

Inga PHP-ändringar krävs. REST-ytan finns redan. App Builder-åtgärden behöver bara en säker anropare istället för en kontrollpanelsknapp.

Autentiseringsalternativ för ERP-anroparen:

Adobe I/O Runtime stöder require-adobe-auth: true för IMS-tokens (om din ERP kan hämta en IMS-token)
För system som inte är Adobe: lägg till en enkel API-nyckelkontroll i payment-accept-åtgärden (kontrollera en rubrik mot en hemlighet som lagras i åtgärdens omfång)

Steg 3 - Lägg till API-nät som mäklarlager

För närvarande anropar App Builder Commerce REST direkt med OAuth 1.0a-inloggningsuppgifter. För större driftsättningar tillhandahåller Adobe API Mesh ett hanterat gatewaylager mellan App Builder och Commerce.

Fördelar:

Centraliserad hantering av autentiseringsuppgifter - API Mesh innehåller Commerce-autentiseringsuppgifter; App Builder anropar API Mesh
Begär omvandling - mappa App Builder-nyttolaster till Commerce REST-former utan att ändra App Builder-åtgärden
Hastighetsbegränsning och cachelagring - skydda Commerce från händelsetrafik i stora volymer

Mönstret:

Ersätt createCommerceClient(params, logger) anrop med anrop till API-nätslutpunkten
API Mesh hanterar OAuth-signering mot Commerce

Steg 4 - Minska PHP-avtrycket

Den aktuella PHP-modulen hanterar fem saker som måste vara pågående (se Delad betalnings-POC: arkitektur och designbeslut). När Adobe Commerce API-ytor mognar kan vissa av dessa bli flyttbara:

Potentiellt flyttbar i framtiden:

REST API för butikskrediter utvecklas - framtida versioner kan ha stöd för kreditpostorder eller inaktiva kundvagnar
I takt med att fler Commerce-åtgärder blir asynkrona kan tröskelvärdesskyddet flyttas till en API Mesh-matchare som är förbeställd

Inte flyttbar (arkitektoniska begränsningar):

Offertmanipulering innan placeOrder() alltid kräver kod i processen såvida inte Commerce visar en ren krok via en API-första tilläggspunkt
REST-slutpunkterna (/V1/split-payment/*) är specifika för den här funktionen. De bor i Commerce eftersom de anropar Commerce-interna tjänster

Steg 5 - Lägg till mer arbetsflöde i App Builder

Aktuell PoC gör en sak: lyssna efter orderplacering och aktivera sedan acceptera/avvisa. Naturliga tillägg:

Felsökning före godkännande:
I payment-orchestrator kan du, när du har registrerat kontanter som väntar, anropa ett API för bedömning av bedrägeri innan orkestreringsresultatet anses vara slutgiltigt. Om poängen ligger över ett tröskelvärde, avböj automatiskt i stället för att vänta på operatoråtgärden.

Meddelandemeddelanden:
När payment-accept lyckas utlöser du ett e-postmeddelande (via Adobe Campaign, SendGrid eller något HTTPS-API) till kunden om att deras kontantbetalning har bekräftats.

Lojalitetspunkter utmärkelser:
När kontanta medel har bekräftats kontaktar du ett lojalitets-API för att tilldela poäng. Detta är helt App Builder - ingen PHP behövs.

Timeout-hantering:
Lägg till en schemalagd App Builder-åtgärd (med cron in app.config.yaml ) som söker efter beställningar som är split_cash_status = 'pending' äldre än X dagar och automatiskt avvisar dem.

Steg 6 - Distribuera till produktion

PoC har konfigurerats för arbetsytan Stage. Flyttar till produktion:

# 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

Checklista för produktionsberedskap:

[ ] DEMO_UI_SECRET har angetts (eller demonstrationspanelen har ersatts med Experience Cloud UI)
[ ] LOG_LEVEL=warn eller error i produktion (inte debug)
[ ] PAYMENT_THRESHOLD matchar Commerce produktionskonfiguration
[ ] Commerce-integreringsautentiseringsuppgifterna i .env är avsedda för en dedikerad produktionsintegrering (inte mellanlagring)
[ ] IP tillåtelselista snabbt uppdaterat med App Builder IP-adresser (Commerce Cloud)
[ ] I/O-händelseregistrering har bekräftats på arbetsytan för produktion

Arkitekturens utvecklingsdiagram

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)    │
└──────────────────────────────────────────────────────────┘

Nyckelreferenser

Relaterade POC-resurser för delad betalning

recommendation-more-help

commerce-learn-help-home