01
Payment provider
Payment
The provider confirms payment independently of the browser session.
Industry · Ecommerce
Ecommerce systems where the promise on the storefront survives fulfilment.
Thalenor builds Shopify and custom commerce experiences, integrations and operational workflows that connect catalogue, checkout, inventory, shipping, customer communication and after-sales service.
STOREFRONT · ORDER · FULFILMENT05
A clear answer
What does Thalenor build for ecommerce organisations?
Ecommerce is a chain of promises. The product page promises an item and delivery expectation; checkout promises a price and payment result; fulfilment promises that the correct stock will move; support promises the customer will not lose visibility when something goes wrong. Thalenor designs the storefront and the operating connections together, using established platforms where they fit and custom software where pricing, catalogue or fulfilment is genuinely distinctive.
Operating landscape
One connected operation. Six places where context can break.
The system should carry meaning across these hand-offs, not leave users to rebuild it in messages and spreadsheets.
01
Catalogue and discovery
Product structure, variants, collections, search, merchandising, content and the evidence customers need to choose.
02
Pricing and promotion
Base price, tax, discounts, bundles, customer groups, channels and approval of exceptions.
03
Checkout and payment
Address, delivery, payment, failure, retry, confirmation and fraud or review handoffs.
04
Inventory and orders
Reservation, deduction, backorder, cancellation, split fulfilment and a consistent order state across tools.
05
Fulfilment and returns
Pick, pack, label, ship, exceptions, delivery evidence, exchange, refund and restocking.
06
Customer communication
Transactional messages, support context, delivery changes, review and reorder journeys across appropriate channels.
Workflow in view
A credible product should make the work visible before it tries to make it fast.
Follow the record, the responsible role and the decision that must remain human.
ILLUSTRATIVE MODEL · FICTIONAL RECORDS
A paid order meets a stock discrepancy without leaving the customer in the dark.
Reliable commerce is clearest when the normal path breaks.
PAYMENT → EXCEPTION → RESOLUTION
ILLUSTRATIVE OPERATING MODEL · 06 STATES02
Inventory
Reservation
The last unit cannot be confirmed at the fulfilment location.
03
Operations
Exception
The order pauses and enters an owned operations queue.
04
Operator
Options
Staff can transfer stock, propose a substitute or approve a refund.
05
Customer
Customer
A specific update and choice are sent from the real order state.
06
Order system
Resolve
Order, inventory, payment and customer history reach consistent final states.
Illustrative failure path. Provider, tax, shipping and consumer obligations depend on the store and markets served.
Where design judgement matters
The hard part is rarely the screen someone asks for first.
01
Custom commerce should justify the operational burden it creates.
A mature platform is usually the right foundation for standard catalogue and checkout needs. Custom work earns its place when configuration, B2B rules, multi-party flows or integrations are central to the business model.
- APrefer platform capability over avoidable code
- BAudit app overlap and performance cost
- CKeep checkout reliability ahead of novelty
- DOwn custom logic outside fragile theme code
02
Stock is a state transition, not a number on two screens.
Availability changes through reservation, payment, cancellation, fulfilment, return and adjustment. Sync must define when stock moves, which system is authoritative and how conflicts are repaired.
- ADistinguish available, reserved and physical stock
- BUse idempotent order and payment events
- CSurface sync failures before overselling spreads
- DDefine return inspection and restock states
03
Payment failure is a designed customer journey.
A payment may be pending, duplicated, captured after the browser closes or refunded partially. The order system must reconcile provider events rather than trust the final screen the customer saw.
- AVerify server-side provider events
- BMake retries safe
- CSeparate paid, authorised and captured states
- DGive support an understandable transaction history
04
The customer experience continues inside operations.
Confirmation, dispatch, delay, return and refund communication should follow actual system events. Marketing automation cannot compensate for messages that contradict fulfilment reality.
- ATrigger updates from authoritative states
- BExplain exceptions before customers chase them
- CCarry order context into support
- DUse consent-aware reorder and review prompts
Relevant capabilities
The engineering disciplines this work usually touches.
Boundaries built into the product
Responsible software states what it will not decide.
A disclaimer cannot compensate for a workflow that hides uncertainty or lets sensitive actions happen without ownership.
01
Order authority
Define the durable order record and make external updates repeatable without duplication.
02
Price authority
Promotion, tax and channel pricing need an explicit source and effective period.
03
Payment security
Use established payment providers and minimise the card or financial data handled directly.
04
Customer consent
Transactional communication and marketing communication have different purposes and controls.
05
Automation fallbacks
Oversells, address failures, damaged goods and refund disputes require visible human queues.
Decision guide
How to decide between Shopify, a headless storefront and custom commerce.
The choice should follow catalogue complexity, checkout needs, operating integrations and the team that will own the system—not a preference for a fashionable architecture.
For most product businesses, begin with a strong platform implementation and reserve custom engineering for the workflows that genuinely differentiate or constrain growth.
01
Use a platform for standard commerce
Reliable checkout, taxes, promotions and an ecosystem usually outweigh the value of owning commodity code.
02
Customise at the business boundary
Distinctive B2B pricing, configuration or fulfilment may belong in a connected service rather than a heavily modified storefront.
03
Consider headless only with a reason
Multiple channels, unusual content or interaction needs may justify it. Otherwise it adds deployment, preview and integration responsibilities.
04
Audit the operating chain
Inventory, accounting, shipping, customer support and returns often decide the architecture more than the homepage.
05
Calculate app dependency
Each plugin adds cost, data access, performance and failure risk. Consolidate overlapping responsibilities.
06
Plan migration as a search and operations project
Products, redirects, customers, orders, integrations and staff processes must move coherently.
Practical questions about ecommerce software.
Shopify or another established platform is right for most standard commerce. Custom work is justified when product configuration, B2B pricing, marketplace logic or operational integration cannot be represented safely.
Map the order after checkout.
Tell us what you sell, where stock lives and how fulfilment breaks today. The right commerce architecture begins with that operational truth.