Order and payment operations, from capture to a reconciled month
An order and the payment for it are two state machines that have to agree at the end of the month. This page describes that workflow the way the people inside it experience it, shows where the two states drift apart, and marks the part a bounded software project should take on first.
Submit a project See the related serviceReviewed by David Nguyen (CEO) · Updated 14 Oct 2026
Who is in this workflow?
- The channel owner runs the storefront or sales desk where the order is captured, and is measured on conversion rather than on what follows.
- Fulfilment commits stock that a warehouse, a supplier or a seller physically controls.
- Finance needs every movement to reconcile: order to invoice, invoice to settlement, settlement to ledger, refund to credit note.
- Customer service absorbs the gap, because most of the queue is a question about an order state or a charge nobody can explain.
- The engineer who owns the integrations maintains the processor, tax and finance connections, each failing in its own quiet way.
How the workflow runs today
Follow one order. It is captured on a channel with its own identifier. Stock is reserved against a record somebody else owns, so the reservation is a request as much as a fact. An authorisation is taken at the processor, which runs its own state machine: authorised, captured in part or in full, failed, disputed, settled. Delivery happens, sometimes in more than one shipment, and an invoice follows for what was delivered. At month end someone opens the settlement file, the order export and the ledger and makes the three agree.
Between those steps sit a spreadsheet, a shared mailbox and one person who remembers how the exceptions were handled last time.
Where the workflow breaks
-
Order state and payment state drift apart
The order says shipped, the processor says authorised but not captured, and neither is wrong on its own terms. The drift is invisible until someone reconciles.
-
Partial capture and partial shipment share no vocabulary
A two-line order shipped in two parts produces one payment record with no agreed way to split it, so a person decides.
-
Refunds are handled by hand
Someone decides an amount, issues it in the processor console, and may or may not write it back to the order.
-
Chargebacks arrive with a deadline and no evidence pack
The delivery record, the accepted terms and the message history sit in three systems.
-
Reconciliation is a spreadsheet nobody owns
It works because one person knows the exceptions, so when they are away the month closes late.
-
Retries create duplicates
A timeout or a replayed webhook produces a second charge, found by hand.
The target flow
-
One order record with one identifier
Every channel writes to the same order object, and that identifier is what the customer, the processor reference and the invoice all carry.
-
Payment as an explicit state, not a flag
Authorised, captured, partially captured, refunded, disputed and settled are modelled states with recorded transitions and timestamps.
-
Reservation with an expiry
Stock is held for a defined period against a named source of truth, and released automatically rather than from memory.
-
Every money movement is an event
Captures, refunds, credit notes and adjustments are appended, never overwritten, so an order can be replayed.
-
Idempotency everywhere it touches money
Each request carries a key, so a retry cannot create a second charge and a replayed webhook cannot create a second record.
-
Reconciliation as a daily job
Settlement lines are matched against payment events automatically, and only the residue reaches a person, in an exception queue with an owner and an age.
System boundary
A project of this shape owns the order record, the payment state machine, the reservation, the event log of money movements, the reconciliation job with its exception queue, and the reporting on top.
It does not own the processor, whose state machine is given, the general ledger, tax determination, or the stock a warehouse or seller controls. Where the record behind stock and supplier data is the problem, that is ERP and back-office operations; the inbound question volume about order state is customer support automation.
Data and integrations
The objects to design are the order and its lines, the reservation, the payment intent and its transitions, the capture, the refund, the invoice, the credit note, the settlement line and the ledger entry. If a settlement line cannot be joined to a payment event by a stored reference, no reporting will fix the month end.
The usual connections are the sales channels, the processors, a tax service, the stock or ERP system, the finance system and an identity directory. For each, agree who owns it, what an error means and what a duplicate looks like. Webhooks need signature verification, ordering that cannot be assumed, and a replay path.
Card data is regulated personal data, so decide early what the system may store and what stays with the processor. Netbase security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request.
What AI changes here
This workflow is arithmetic before it is intelligence, so the honest scope for AI is narrow.
Whether a step needs rules or a model is worked through in the business workflow transformation guide; an AI Workflow Blueprint settles it for one workflow before a build. Netbase works with commercial and open-source AI models chosen per project,. What AI does not fix: a missing processor reference, a reservation never released, and a tax rule nobody has written down.
-
Unmatched settlement lines
A model can propose a match for the residue deterministic rules miss. A person accepts or rejects, and the decision is recorded.
-
Remittance advice that arrives as a document
Extraction turns a scan into fields a human confirms; see document and approval workflows.
-
Refund and dispute reasons
Classifying the free text behind returns tells you what to fix upstream.
Delivery modules
- Order capture and one order model across channels, with the identifier scheme.
- Payment state machine with idempotency keys, webhook verification and replay.
- Reservation and release against the stock source of truth.
- Refunds, partial captures and credit notes, with write-back to the order.
- Dispute handling with an evidence pack assembled from the record.
- Reconciliation job, matching rules and an exception workbench with owners and ageing.
- Reporting, a finance export, and an audit trail over every money movement.
These are built as Custom Product Engineering milestones with written acceptance criteria; other engagement shapes are listed under services.
Rollout
Start with a read-only reconciliation against your existing systems. It runs safely in parallel and within a few weeks shows the real size of the drift. That number is the business case, and it is yours rather than a benchmark.
Then take one channel and one processor, run the new payment state beside the old one, and compare daily until they stop disagreeing. Move the close onto the new record only after a full period has run in parallel.
Netbase follows one delivery lifecycle: discovery and strategic alignment; team assembly and architecture planning; agile execution with outcome-based milestones; modular components; training and rollout; ongoing support. The parallel period is the rollout step; milestone acceptance follows the project delivery page.
Risks
-
The processor is the constraint
What can be captured, refunded or reversed is its rule, not a design choice. Read the contract before the architecture.
-
History is migrated without its payment state
Old orders arrive with amounts but no transitions, so the first reconciliation on migrated data fails for reasons that are not defects.
-
Finance is consulted at the end
They own the definition of correct here, so they belong in discovery.
How is success measured?
Take a baseline before the build, then track: settlement lines matched without a person; the age of the unmatched queue; days to close the period; orders whose payment state disagrees with their fulfilment state; and disputes answered inside the window with a complete evidence pack. How evidence is labelled is explained on the methodology page.
Where this workflow holds
It holds wherever money and delivery are recorded separately and have to be matched: retail and e-commerce, subscriptions where renewals add a second clock, marketplaces where the money is split between parties, ticketing, and services billed against milestones. Print commerce adds artwork approval between payment and production; the print order and fulfilment guide and the printing and packaging page cover that variant.
It does not hold where one system already owns order, payment and ledger and is working, nor where the real problem is the physical evidence that a delivery happened, which is dispatch and delivery tracking. Neighbouring workflows are under solutions.
Proof from delivery
Three delivered Netbase builds carry parts of this workflow.
- Points-plus-cash checkout. For a Dubai-based loyalty and rewards technology company, Netbase delivered a headless multi-store reward shop platform with a hybrid points-plus-cash checkout, payment gateways and a multi-vendor module with fulfilment routing. See the loyalty reward shop platform record; the loyalty and rewards platform guide covers redemption design.
- Split money between parties. For RB Marketplace, Netbase built a multi-vendor marketplace with cart, coupons and checkout, vendor order fulfilment, commission deductions and payout requests. See the RB Marketplace record.
- Payments inside a wider platform. A bilingual English and Nepali classifieds platform for an unnamed founder included payments and paid ads, delivered in six milestones over four months. See the online classifieds platform.
Each record covers part of the money flow described above. Reconciliation, the payment state model and the exception workbench are scoped in discovery and built with the same milestone method. No volume or result is claimed.
Netbase delivered a bilingual classifieds marketplace, in English and Nepali, with paid ads, search, messaging, payments and an AI filter that flags offensive content into an administrator review queue. The client is not named, and no traffic, accuracy or commercial result is claimed.
Keep Reading
Confidentiality covers the engagement; no client is named and no result is claimed.
Keep Reading
This record sets out what was delivered on each side, what deliberately stayed in the web panel, and what the project documents do not support.
Keep ReadingCommon questions
No. The project models the state your processor reports and reconciles against it. Changing processor is a separate decision, made easier once the state is modelled.
Yes, and it is the common first milestone. A read-only matching job changes no behaviour and produces the evidence for whatever comes next.
Yes, if commission and payout are modelled as money movements on the order rather than a separate spreadsheet. The RB Marketplace build above is that pattern.
You do. Intellectual property created in custom development belongs to the client; a Netbase productized module, where one saves time, stays licensed and is named in the proposal before work starts.
Yes. Every service on this site is delivered remotely from Hanoi, and Netbase has worked with clients in 80 countries. Delivery communication is in English, with weekly reviews and a named project manager.
Netbase takes on projects in any industry where the work can be delivered remotely and accepted by milestones. The industry pages describe the approach sector by sector, and the Work records show delivered projects.
Talk to Huy Nguyen (David), Founder and CEO of Netbase JSC: message him on WhatsApp at +84 937 869 689 or email project@netbasejsc.com. You can also send your brief through the project request form. Say which workflow or system the project concerns and what has to stay unchanged; the first step is a discovery conversation, and scope and milestones are agreed after it.
Services behind this solution
Custom product engineering for a bounded release outcome
One defined release of your product, built to named outcomes and handed over with acceptance evidence.
Learn More
Scope this workflow
Bring one month of settlement files, the order export for the same month, your channels and processors, and the exceptions your team handles by hand. Name the part you want moved first, then submit a project brief. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.