Storefront and ordering

The problem

A client needs fifteen laptops. They email their MSP, who opens the distributor portal, copies part numbers into a spreadsheet, adds a margin, and emails a quote back. The client replies with a change. Two more rounds later the order is placed by hand, the client has no way to see where it is, and when the invoice arrives nobody can reconcile it against a price that was agreed in an email thread. Meanwhile the MSP’s actual buy price is sitting one careless forward away from the client.

What Solidlio does about it

Solidlio gives each MSP a storefront its clients browse and buy from directly. One pricing engine computes the price — the MSP’s markup, then that client’s own contract, discount and volume rules — and the same engine runs on the product list, the product page, the cart and the checkout, so the number a buyer sees is the number they are charged. The MSP’s cost and margin are removed from the payload before it leaves the server, not hidden in the UI. Buyers pay by card through Stripe Connect or place the order on account; either way the order lands with the MSP for approval and is tracked to delivery in the client’s own portal.

Capabilities

Built for MSPs and their clients

costCents, marginPercent and vendor markup are stripped from every product payload below the MSP technician rank, and a buyer’s order history and spend are pinned to their own organization regardless of what the request asks for — a sibling client’s order is a 404, not a permission error.

How it works

1. Browse — the client opens Shop in their portal and filters by brand, category or availability. Every price shown is that client’s price in that client’s currency.
2. Add to cart — the cart stores only what and how many. It asks the pricing engine for the price on every read, so it never displays a figure the checkout would disagree with.
3. Choose a path — pay by card now, place the order on account, or convert the cart into a quote request for a negotiated price.
4. Place the order — the server prices every line again, computes tax from the buying organization’s jurisdiction, records the FX rates used, and writes the order plus its ledger row in one transaction. A client-supplied price is rejected by the schema.
5. Pay — for a card order the buyer confirms with Stripe Elements. The order is marked paid only when Stripe’s webhook confirms it, never on the client’s say-so.
6. Approve and fulfil — the MSP approves the order (a settled card order advances itself), then moves it through Processing, Shipped and Delivered, attaching carrier and tracking as it goes.
7. Bill — net-terms orders are invoiced automatically once delivered, once, with the order carrying the invoice it produced so a re-run cannot bill it twice.

Money safety

• Prices are computed server-side, always. The checkout schema is strict: a request carrying unitPriceCents or totalCents is rejected rather than trusted.
• A double-click cannot produce two charges.
• Settlement is webhook-driven. Checkout leaves the transaction PROCESSING; only payment_intent.succeeded marks it settled, and a redelivery of that event is a guarded no-op.
• A failed card leg never fakes a payment. If the intent cannot be created, the order stays placed and uncharged, and the buyer is told so by name and order number.
• Tax is held, not guessed. An order whose jurisdiction is not configured is written with zero tax, flagged, and excluded from automatic invoicing until a human reviews it.
• Stale exchange rates stop the sale. A rate not confirmed within 48 hours makes the line unpriceable, and checkout refuses it rather than charging at a rate of unknown age. Every order snapshots the rates it used.

Multi-currency

Buyers are quoted and charged in their own currency — the organization’s override, else its account default, else the seller’s. CAD, USD and EUR are supported. Cost is converted before markup, with an optional FX buffer applied only on cross-currency sales, and reference prices (list, MSRP) are converted too so a page never mixes currencies. The order records both its currency and the rate table used.

Editions

The storefront itself is not plan-gated: browsing, the cart, checkout and order history are available to every client organization of an MSP on any plan. What the MSP’s plan changes is how much of the catalogue it controls.

Integrations

Stripe Connect — destination charges settle to the MSP’s connected account, with the platform fee and card-acquiring cost taken as the application fee. Disputes route back to the originating transaction.

Distributor catalogues — the products a client browses come from the platform catalogue that distributor feeds populate, filtered by the MSP’s vendor preferences.

Icecat — product pages render the gallery, grouped specifications, identifiers and datasheets cached from Icecat enrichment. Enrichment is triggered by MSP staff, never by a buyer.