Services
Order, payment, stock and sales operations designed around the way your business actually fulfils orders.
A customer sees a catalogue, cart and checkout. The business must coordinate the order, payment, stock, warehouse, invoice, delivery, CRM, customer communication, returns and refunds. A useful eCommerce workflow gives each part a clear responsibility and makes exceptions visible.
GiSoft designs and modernizes these workflows without assuming that every store needs the same states, integrations or architecture. The process should follow how the company sells physical products, digital services, subscriptions or B2B orders.
Start by agreeing when an order exists, when stock is reserved, who may approve it, when an invoice is created and what cancellation or refund means. The order state belongs in backend business logic, not in a browser screen.
For many businesses, an internal order reference created at checkout becomes the link between payment, stock reservation, ERP, invoice, shipment and support. This is often useful for recovery, but the precise sequence depends on the product and commercial process.
A return from a payment page is not definitive confirmation. The customer may close the browser, a redirect may fail, or payment may still be pending. The application should use the provider’s verified server-side confirmation or other agreed settlement signal, then update its own business payment state.
Authorisation, capture and confirmation are separate concepts. A provider may reserve funds before capture; another may report a completed payment later through a webhook. The order workflow should represent the business meaning needed by the store, such as awaiting payment, authorised, paid, rejected, cancelled, refunded or an outcome that still requires review.
Availability, reservation and stock reduction are not interchangeable. Availability answers whether an item can currently be offered. Reservation temporarily allocates units to an order under defined conditions. Stock reduction records the fulfilled or otherwise final inventory movement. The ERP or WMS may be the system of record, but the webshop still needs clear rules for what it may show and when a reservation expires or is released.
Imagine an older Symfony webshop that began with a catalogue, cart, checkout, orders and email. Over time it gained payment providers, ERP and WMS synchronisation, a courier API, invoicing and CRM updates. If the checkout controller now calls every external system directly, one slow provider can delay the customer and a partial failure becomes difficult to explain.
A controlled improvement is to retain existing order rules and put an application workflow between checkout and external services. Payment, ERP, warehouse, invoice and notification adapters then handle their own boundaries. This does not require rewriting the whole shop; it can be introduced around the area that creates the greatest operational risk.
HTTP success or a webhook receipt does not necessarily mean the complete business process has finished. A timeout also does not prove that the remote operation failed: an ERP, payment provider or invoice service may have processed the request before the response was lost.
Record the local attempt, use a stable business or request identifier where the external system supports it, and reconcile uncertain cases with the source system. Idempotency means a repeated operation should have no additional intended business effect. It relies on the application design and, where relevant, the provider’s support or a shared identifier; an identifier alone is not a guarantee.
Retries should target temporary failures and be limited. Invalid data or a missing business decision needs correction or manual review. Background jobs are usually suitable for ERP updates, invoice generation, stock synchronization and notifications, because checkout should not wait for every downstream operation.
Cancellation, refund and return are different business events. A cancellation may release a reservation before dispatch; a refund may follow settlement; a return may require a warehouse decision and accounting correction. Their rules should be explicit, including who can approve them and which system records the final state.
A database rollback cannot reverse a completed payment, sent email or ERP action. Recovery may instead require reconciliation, a compensating action, a safe retry or manual handling. Monitoring should show orders waiting too long, failed jobs, payment discrepancies, stock conflicts and cases requiring attention.
Use authorization for administrative changes, protect customer and financial data, verify payment webhooks and keep provider credentials out of code and unnecessary logs. Test the critical paths: creating an order once, handling repeated notifications, reserving and releasing stock, invoicing and recovery from failure.
GiSoft works from the existing order process, identifies the system of record and risk points, and improves the boundaries that matter most. The right design depends on the business model, stock policy and connected systems. The aim is an order operation that staff can understand and recover, not a promise that every external dependency will behave perfectly.
