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 (CEO) · Updated 24 Sep 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 and statutory reporting, which stay in the finance system of record; tax determination, which belongs to a service with its own liability; or the warehouse and the seller, who control the stock. Each is an interface with an owner on both sides. 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.
Netbase works with commercial and open-source AI models chosen per project, and implies no vendor partnership. 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; that argument is set out in 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 is safe to run in parallel and within a few weeks tells you 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. Delivery is remote-first from Hanoi in Agile increments with weekly reviews, using AI-assisted engineering under human review. Milestone acceptance is on 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.
-
Nobody owns the exceptions
A queue without an owner becomes a second spreadsheet.
-
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 success is 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.
Netbase publishes no measured business result from another client's workflow, so nothing here is a benchmark. 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.
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. The neighbouring workflows are listed under solutions.
Proof from delivery
OutsourcingVN publishes no delivered project record for an order management or payment reconciliation product. No approved claim in the register describes one, and this page makes none.
What the record contains is adjacent. For a founder who is not named, Netbase delivered a bilingual English and Nepali classifieds platform: requirements, design, a Laravel backend with REST APIs, OTP accounts, paid ads, search, ratings, messaging, event ticket ads, blog and forum, payments, multi-language SEO and AWS deployment. That work ran in six milestones over four months with training and six months of support. Payments there were one part of a platform rather than a reconciliation engine, and no volume, country or result is claimed. The full record with its evidence limits is the online classifieds platform with AI moderation page.
So the argument for taking this workflow on is capability and method rather than a matching track record. That is a weaker claim than a delivered reconciliation platform, and it is the accurate one.
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 ReadingCommon questions
No, and usually you should not. 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.
For custom development the client owns the intellectual property created for it. Netbase productized modules and products are licensed rather than transferred, and any used in a project are named in the proposal.
Services behind this solution
Custom product engineering for a bounded release outcome
Custom Product Engineering is for a buyer who can name the users, the release decision and the outcome a product increment should deliver. The engagement produces an accepted, working release, the evidence that it works, and a handover your team can operate. It is not a way to rent developers by the month.
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.