Create a split payment POC: App Builder full demo
This is the end-to-end walkthrough of the split payment proof of concept built on Adobe Commerce and Adobe App Builder. The demo assumes you have already used AI tools and a prompt to produce the in-process Commerce extension and the App Builder app; this video shows what happens after that code is merged, deployed to an Adobe Commerce Cloud website using the native Luma theme, and the App Builder project is live.
A shopper pays with part cash and part Store Credit. Commerce owns synchronous checkout and the APIs the storefront needs; App Builder handles orchestration, operator workflows, and I/O event consumers. The reference implementation uses a Commerce (PaaS) project and the Luma native checkout rather than an Edge Delivery Services storefront, which is still a common path for many merchants. If you use Adobe Commerce as a Cloud service in a different topology, the App Builder code stays similar but storefront and in-process work would look different. For on-premises, self-hosted, and Commerce in the cloud on Luma, this video shows a practical split between in-process code and App Builder for new functionality.
Video
Who is this video for?
- Technical architects planning Commerce extensibility
- Developers implementing checkout and integrations
- Implementation teams who need a realistic split between PHP and App Builder
Set up the scenario on the storefront
The demo account has Store Credit and you see that balance in checkout. Add products until the order total is about $80. That size gives you room to show both the successful accept path and a decline path, similar to a card decline, without the math fighting you.
Split payment is only offered to signed-in customers, because the session must expose store credit. Guest checkout does not show the split option.
- On the Payment step, choose the cash method (the demo renames Cash on delivery to Just Cash).
- A split payment area appears under the payment method. The cash field is prefilled to the order total, and the component reads Store Credit from the session.
- For an ~$80 cart, set $50 cash and $30 store credit so the component shows $50 + $30 = $80.
- When the amounts are valid, place the order.
The UI triggers a call to a new Commerce REST API for the split. Checkout stays synchronous: Commerce applies store credit, stores split lines on the order, and emits an I/O event that App Builder consumes later. The success page is immediate for the customer.
Review the order in the Commerce admin
In Sales > Orders, open the new order. The Payment information area shows the split, for example $50 cash and $30 store credit. The status is Pending when cash is not yet collected; store credit is already taken when the order is created.
Comments can include text that App Builder added. The Payment orchestrator action in App Builder received the I/O event, checked the split amounts, and used authenticated REST to append comments. Commerce treats that like any other REST call and does not need to know the writer.
Use the App Builder operator dashboard (ERP or back office)
A simple HTML experience runs as an App Builder web action (no Admin for this view). The dashboard calls the Commerce Order REST API and filters to Pending so you can find the $50 cash leg.
You typically integrate this pattern with an ERP or fraud tool. Two actions are demonstrated:
- Accept — Confirms that cash was received (in production, often an automated post from a cash drawer or store system).
- Decline — Simulates fraud or a failed collection step (in production, usually automated from your risk service).
Accept and complete the order
- In the App Builder app, use Accept to confirm cash.
- The app calls a new Commerce endpoint that finalizes the cash line. The core order flow (invoicing, and in this build an automated shipment) runs with native Commerce behavior. None of that path requires a human in Admin; orchestration and the endpoint live in App Builder.
Refresh the same order in Admin: status moves to Complete when the cash is accepted, with invoice and, where the product is shippable, a shipment to shorten the full lifecycle in the demo.
Decline and cancel
- Open a prebuilt order that is still in the decline scenario.
- In the App Builder app, use Decline to simulate a fraud or collection failure.
- In Admin, the order is Cancelled. The history shows a declined cash status, comments explain the result, the shopper was not charged the store-credit line as if it were a final sale, and the store-credit invoice is voided with the cancellation. A production system would also notify the customer and release any holds on inventory or service.
Order total threshold (validation before the order is created)
App Builder or Commerce configuration can support validation rules; this build blocks orders over $100 in cart value (a demo cap you can change). A value check is not the most common business rule—inventory or availability checks are more typical—but it shows that validation can run at Payment in Commerce before an order is created, while App Builder still handles follow-up automation.
- Add products until the total is above $100.
- The split UI still appears; the over-limit result only surfaces on Place order.
- The shopper sees a generic error such as Payment could not be processed. Please try again or contact support.
- The cart is unchanged so the customer can lower the total, pick another method, or contact support.
A risk score, region rule, or similar could plug in here; Commerce blocks the order, and App Builder can own notifications and case work after the fact.
Commerce on premises, Commerce in the cloud, and Adobe Commerce as a Cloud service
The walkthrough matches Adobe Commerce on an infrastructure you manage or Commerce in the cloud (PaaS) with a traditional storefront. For Adobe Commerce as a Cloud service (SaaS) with a different front end and no in-process module in this shape, the App Builder pieces are largely the same, while storefront and extension work would be different. In all cases, the same principle holds: let Commerce do what must happen inside the Commerce request, and use App Builder for the rest of the experience.