Commerce Platforms
Customers buy in many places. An order should still have one financial truth.
A purchase can start in a web checkout, continue in a chat thread, be paid in a mobile app and be placed by a software agent. Orangepill keeps the order and its payment in one lifecycle, so every channel reads the same state instead of maintaining its own.
The problem
Checkout is no longer one page.
Messaging, embedded checkouts, mobile wallets and agents each arrived with their own integration. Each one collects payment slightly differently and reports status in its own way. The order system is left to infer what happened from whichever channel spoke last.
Typical architecture today
A payment integration per channel.
- Web checkout Provider integration 1
- Mobile app Provider integration 2
- Messaging Payment links, separate status
- Agents Shared API keys
- Order system Reconciles all of the above
Where it breaks
The customer sees one order. Your systems see four.
- A customer pays a link in chat, then pays again in the app because the order still shows unpaid.
- A notification confirms an order whose payment is later reversed.
- Store credit applied in one channel is not visible in another.
- A mass payment-request campaign leaves no clear record of which requests were paid.
- An agent with a stored API key can spend without limits anyone can verify.
Orangepill model
Channels are where customers act. The runtime is where the order's money is decided.
Orchestration per journey
Each channel can have its own journey: prompts, confirmations, approvals. Journeys decide; they do not move money.
One execution per payment
Payment, refund and fulfilment-linked releases are idempotent executions under the order, however many channels touched it.
State pushed out, not pulled in
Order status, balance and settlement updates in each channel reflect lifecycle state rather than channel guesses.
Example workflow
An order started in chat and paid in an app.
- Order created In a messaging thread
- Payment requested Customer opens the app
- Payment executed Idempotent under the order
- Ledger updated Order paid; credits applied
- Channels notified Chat, app and email agree
- Fulfilment Released on confirmed payment
Capabilities used
What sits behind every channel.
Execution
One lifecycle per order payment, whichever channel started it. Channels display state; they do not own it.
Explore Execution →Wallet & Ledger
Stored value, credits and order balances derived from the ledger, so the same number appears in chat, app and checkout.
Explore Wallet & Ledger →Multi-Rail Orchestration
Lets each channel offer the payment methods that suit it while orders settle into one model.
Explore Multi-Rail Orchestration →Agent Runtime
Lets software agents place orders and pay under scoped, verifiable authority instead of holding raw credentials.
Explore Agent Runtime →Agent Runtime is in Private Preview: agent-initiated commerce works in the platform and is enabled with selected customers.
Outcome
Add a channel without adding a second source of truth.
- Launch a new channel or checkout surface without rebuilding payment logic.
- Fewer duplicate payments from customers who cannot see that they already paid.
- Notifications that reflect what actually happened to the money.
- Campaign-scale payment requests with a traceable outcome for each one.
- A path to agent-initiated purchases under bounded authority.
Bring us one order that crossed two channels.
We will trace how its payment state moves through your systems today and where one lifecycle would replace per-channel status.