Search web development e commerce and you get two genres of result. One is the step-by-step guide, ten sections long, walking you through building options, core features, tech stack, design, and performance. The other is the agency service page, which lists the integrations the shop supports: ERP, CRM, payment gateway, shipping carrier, marketplace sync, each one a checkmark in a grid. They name more or less the same set of things, and none of them tells you what building any of it actually involves.

The top organic result for this search, Innowise’s step-by-step ecommerce guide, is better than most and still shows the pattern. It gives payment security real treatment, walking through SSL and TLS, tokenization, 3D Secure, and PCI DSS in context. But inventory sync, tax calculation, and shipping logistics show up in a features list and never get returned to, while cart-abandonment recovery, subscription billing, and marketplace architecture don’t appear at all. Spiral Scout’s ecommerce development page is the closest thing here to a direct competitor, a development shop selling the same service we sell, and it stops in the same place. Shopify, Magento, BigCommerce, headless and PWA, ERP and CRM and POS integration, multi-channel and marketplace sync, conversion-focused checkout are all named, and the page never says what building any of them involves. Payment processing shows up there only inside a price range.

The part these pages skip is what comes after the catalog and the cart. Most of the remaining work on a store is about what happens when a card is charged but the confirmation never arrives, when the warehouse’s stock count and the storefront’s disagree, or when a webhook fires twice. That’s the engineering you’re actually paying for when you hire against this phrase, and it’s worth knowing its shape before you hire anyone. If you haven’t yet settled whether you need a custom build at all, that decision comes first, and we wrote it up separately in website ecommerce development.

Strip a working store down and you find four systems that each hold a piece of the truth about an order.

The payment processor knows whether money moved. A tax engine knows what the order owed given where it shipped and what was in it. Inventory, which might live in an ERP or at a 3PL or in a warehouse management system, knows what’s physically on a shelf. And then there’s the store’s own order record, which is the thing your customer service team looks at and the thing your customer gets an email about.

Each of those runs on its own clock and can be down while the others are up. The word integration makes that sound like a wiring problem, as though the job were finding the right connector and plugging it in, when most of the work is deciding what your store believes when two of these systems disagree and making sure a customer never sees the disagreement. Everything below is a version of that problem.

Authenticating a payment request is the easy part, and any developer can get a test charge working in an afternoon. That’s the part demos show.

The hard part is a request that might have already succeeded. Your server sends a charge, the connection times out, and now you know nothing: the charge may have gone through with the response lost on the way back, or it may never have landed at all. Retry blindly and you can charge the customer twice, but sit on it and you may end up telling a paying customer their order failed.

Stripe’s answer to this, documented in their own API reference, is idempotency keys. You attach a unique key to the request, and Stripe saves the first result it produces for that key and returns that saved result on any retry carrying the same key, so the retry hands you the original charge back instead of creating a second one. Keys are retained for 24 hours by default, which is the window you get to recover in.

On your side that’s more than passing an extra parameter. The key has to be generated and written down before the request goes out, tied to the checkout attempt rather than regenerated on each try, or the retry carries a fresh key and you’re back to double charging. Webhooks need the same discipline in reverse, because processors deliver at-least-once and you should assume any given event will arrive twice: handlers get written so that running one a second time changes nothing, usually by recording the event id and ignoring repeats. And you want a scheduled job that walks recent orders, asks the processor what it thinks happened to each one, and surfaces anything where the two records don’t line up. None of that tends to show up in a quote, and it’s what keeps a bad network moment from turning into somebody in support issuing refunds by hand on Monday.

Overselling almost never comes from bad arithmetic; it comes from timing. Between the moment a customer adds the last unit to their cart and the moment their payment confirms, there’s a window where the item is neither sold nor safely available, and two shoppers can sit in that window at once. Whether your store handles that correctly depends on a decision someone has to make deliberately: do you reserve stock when the cart is created, with a timer that releases it, or do you decrement only on a confirmed order and accept that a small number of orders will need to be caught after the fact? Both answers are defensible, and the oversell comes from never having picked one.

The second source is the feed itself. Your ERP or 3PL updates on its own schedule, and that schedule is often a nightly file or an hourly pull instead of a live signal, so the number on your product page is a photograph of what was true some minutes or hours ago. That’s fine as long as everyone designing the storefront knows it, and it stops being fine when someone builds a low-stock badge, a back-in-stock notification, or an allocation rule on top of a number they think is live.

Which brings up alerting, since “we’ll monitor the sync” is a sentence that commits to nothing. A sync alert earns its keep when it fires on the two things that actually hurt: the feed going stale past a threshold you picked on purpose, and a per-SKU divergence between what the storefront shows and what the source system holds. The alert should carry the SKU and both numbers so the person reading it can act without opening three tabs, and it should route to someone whose job it is to resolve it. An alert that fires on every successful run gets filtered into a folder within a week, and then you have no alerting at all.

Checkout demos run on good wifi in a quiet room, while real checkout runs on a phone with one bar in a parking lot, and that’s where the interesting failures live.

A customer on a slow connection taps Place Order, sees nothing happen for four seconds, and taps again. Disabling the button in JavaScript helps, but you can’t lean on it, because the second tap may already be in flight and the customer may have reloaded the page entirely. The server-side fix is the same shape as the payments fix: the order submission endpoint is keyed on the checkout attempt, so the second request finds the order the first one created and returns it instead of starting a new one.

Then there’s the worst version, where the charge succeeds and the customer never learns it. The payment goes through server-side, the confirmation page times out, and now your customer is looking at an error screen with money gone from their account. Two things prevent that from becoming a support ticket. First, the order record gets created in a pending state before the charge is attempted, so there’s always a row to reconcile against and never a payment with no corresponding order. Second, something has to close the loop with the customer independently of that page load, which usually means the confirmation email is triggered by the payment result rather than by the browser reaching the thank-you page.

Orders stuck between charged and confirmed still happen, and the question to ask any shop is what finds them. The answer should be a job that runs on a schedule, looks for orders in an intermediate state older than some number of minutes, and either completes them or raises them to a human with enough context attached to fix it in one pass.

Sales tax is the exception to everything above, because here the right engineering decision is to buy.

The complexity is jurisdictional. Rates vary by state, county, city, and special districts that don’t follow postal boundaries, they change on schedules set by legislatures rather than by you, and what’s taxable depends on how the product is categorized, with clothing and groceries and digital goods treated differently in different places. On top of that sits economic nexus, meaning where you’re obligated to collect depends on your own sales volume in each state and changes as the business grows. That’s a full-time compliance product, and there are good ones.

Buying it doesn’t make the work disappear, though, which is the part the guides skip. The storefront still has to validate and normalize the shipping address before asking for a quote, because a bad address returns a confidently wrong rate. The calculated amount has to be stored on the order at the time of purchase instead of recalculated later for display, or a rate change will quietly rewrite the history of orders you’ve already shipped. Somebody has to decide what checkout does when the tax service is slow or unreachable, and the honest options are to fail the checkout or to fall back to a conservative stored rate and flag the order for review. Whoever runs the business should make that call, because either answer costs something and an engineer picking one quietly is how you find out months later. If you sell wholesale, exemption certificates need somewhere to live and a way to apply automatically, and refunds need the same math run backwards and reported, so your filings match what you actually collected.

You don’t have to be technical to tell a shop that installs ecommerce apps from one that can own this layer. Five questions will do it, as long as you listen to how specific the answers get.

Ask what happens when a payment request times out and gets retried, since you want to hear the words idempotency key and you want to hear where the key gets stored. Ask what the system does when the inventory feed arrives late or half-empty, because “we’d look into it” means there’s no plan. Ask who gets paged when the storefront and the warehouse disagree about stock, and what that alert actually says. Then ask them to walk you through an order that’s charged but not confirmed, from detection to resolution, and ask where the tax amount lives on the order and what checkout does when the tax provider is down.

A shop that has built this layer before answers all five in specifics, usually with a story attached about the time one of them went wrong. Answers that stay at the level of which platforms the shop is certified on tell you it hasn’t.

Write down the systems your store has to talk to and who owns each one internally, because that list is the real scope of the project and most quotes are priced without it. Then take the five questions above to whoever you’re evaluating.

If you’re still working out whether a platform covers you or you need a custom build, start with website ecommerce development, which covers that decision. If you’re already live and the problem is that no single system holds the whole picture of the business, the reporting side of this is its own body of work and we wrote it up in analytics engineering for e-commerce teams. For an example of this layer in production, Wine Spies is an online wine retailer whose checkout, inventory, and fulfillment backend we built and still run.

And if you’d rather just ask us how we’d handle one of these on your store, book an intro call.