The native Storefront
A complete shop on your own address: products and variants, themes, block-built pages, promotional panels, menus, a cart and a checkout.
Commerce · storefront, chat and channels
One catalogue. Every way people buy.
Open a real shop on your own address, then let the same products sell inside a conversation on your website, on WhatsApp, on Instagram and beyond. The shop prices the order, the shop signs the card, and only your customer's confirmation creates it.
17 payment gatewaysCash, collection and in-storeEight selling channelsCard data never crosses OpsIQ
Live
Card dataNever ours
Gateways17
What commerce means here
Not a checkout bolted on. A shop, a conversation and a contract.
Commerce in OpsIQ is four things that share one catalogue: a native storefront you own, a selling path through chat and social channels, a payment layer that never touches a card, and a published contract other platforms and developers build against.
Live
Selling inside a conversation
The same catalogue quoted by the server and confirmed on a signed card, across the website widget and seven messaging channels.
17 gateways, 4 offline methods
Provider-hosted checkout everywhere, plus bank transfer, cash on delivery, pay on collection and pay in store for the money that never goes online.
A contract, not an integration
Connector Contract 2.4 with 57 declared capabilities, a typed public API and conformance tooling anyone can run.
The native Storefront
A shop you own, on an address that is yours.
Not a hosted page with someone else's name in the URL. Your domain, your theme, your typography, your photography, your policies. This is the real thing, running.
Your domainYour theme
CheckoutBuilt in
40 languagesEvery page
Colour, typography, fills and gradients, shape, width, motion, hover and how the shop behaves in light and dark. Preview desktop and phone before you save.
About, Contact, a lookbook and the account area, plus custom pages with their own hero, slug and search settings. Reserved routes such as cart and checkout stay yours to keep.
Placement, trigger, backdrop, motion, width, a coupon and once-per-visitor behaviour, built from the same blocks as everything else.
Point them at pages, products, collections, policies, cart and account actions, a live modal or a safe external link, with one level of dropdown in the header.
Forty locales, with the shop opening in the currency that follows the visitor, and your price never substituted behind your back.
Starter About and policy text where those fields are empty, never over your own words, and a readiness check that keeps warning until you have replaced it.
See it for yourself, right now.
Open the live store
This is our own launch-validation shop. The shopfront, accounts, currencies, languages and checkout are the real thing. The products in it are test items, so treat it as a working demonstration rather than a catalogue.
Selling through Client Chat and social channels
The assistant can talk about the price. It can never set one.
A model that is allowed to say a number will eventually say the wrong one. So it is not allowed to. The assistant finds products and asks the server for a quote; the server prices the order, composes the confirmation card and signs it. What the shopper sees is written by the shop.
One catalogue, one quote, one signature. Three places a customer happens to be standing.
Live
How it holds
Four things a conversation cannot do.
It cannot invent a price. The quote comes from the catalogue through the server. The card carries that figure, and the gateway charges exactly what the card displays.
It cannot confirm on the customer's behalf. Confirmation is an artifact, not a sentence: the card's own button on the web, or an exact confirm command on a channel. A casual "yes" does nothing.
It cannot move a card between conversations. The signed payload carries a hash of the channel and the person; a card lifted into another thread fails to verify.
It cannot go stale. The card expires, and the price, stock and market are checked again at the moment of confirmation, not at the moment of the offer.
Geo currency beside the store total
Identity verified by an emailed code
Refusals name the missing field
The walls
Limits you set, enforced at every door.
A limit that only guards the checkout page is not a limit. Every wall below is judged on the shared placement path, so the cart, the buy-now button and a confirmation in a chat all meet the same one. You set the values in Settings, and nothing on this page hardcodes them.
01
A ceiling on cash on delivery
Goods leave before the money arrives, so you cap how much you are willing to send out that way. Above your ceiling the option simply is not offered, in the order's own currency.
02
Codes reserved when the order is placed
Licence keys, prepaid and gift-card codes are claimed inside the order's own transaction. If there are not enough, the order rolls back and nothing is charged. Two shoppers cannot buy the same code.
03
A daily limit per customer
Orders from the same email in the last day are summed in the same currency, never converted, and a new order that would cross your limit is refused before it is placed.
04
A kill switch that knows the difference
Pausing selling stops new commitments while reads, look-ups and releases keep working. Facts that are already true, such as a payment that has landed, are queued rather than executed or narrated as done.
05
An identity floor before an order exists
Where OpsIQ owns the payment, a chat customer reaches an emailed six-digit code before an order is created. An operator may require more than that and never less.
06
The assistant quotes your words or nothing
Every reason the shop-floor assistant gives for a pick has to be a phrase that already appears in that product's own text. A sentence it composed itself is dropped rather than shown.
Live
RefusedNothing charged
One placement path
The cart, the button and the conversation meet the same gates.
An order can start in three places. It only becomes an order in one, and that one place runs every wall you configured. Nothing is skipped because it arrived by a different route, and a refusal says what happened in a sentence the customer can act on rather than an error code.
Judged in the order's own currency
Never converted behind your back
Refused before anything is charged
Each of these walls is pinned by a mutation proof: the guard is deliberately broken in the source, a door-level test has to go red, and the file is restored and re-checked byte for byte. A guard that has never failed is unproven.
Payments
17 gateways, 4 ways to pay offline, and not one card number.
Every gateway OpsIQ ships uses the provider's own hosted checkout. Your customer types their card on the provider's page, on the provider's domain. OpsIQ holds a reference to a payment, never an instrument, and the code that draws that boundary refuses anything outside a reviewed list of fields.
Live
WebhooksWake, not prove
Ways to pay
Online, and the ways money still moves offline.
Plenty of real trade never touches a card. Each offline method carries its own conditions rather than being a free-text note at the bottom of a receipt.
Bank transfer with your own account details shown at checkout.
Cash on delivery, offered only when something is actually being delivered and the total sits under your ceiling.
Pay on collection, offered only on a collection order. Nothing leaves unpaid, so it carries no ceiling.
Pay in store, offered only when you have published somewhere a person can walk into. The goods can still be delivered.
Four further providers are deliberately not shipped. Their webhooks are signed with schemes that are not HMAC at all, and folding them into an HMAC helper would produce a verifier that could never succeed. The reason for each is written down rather than left as a gap.
Every gateway OpsIQ ships
Region is how we group them here, never a restriction. A merchant in Lagos may well want Stripe, and a merchant in Berlin may well want Paystack. Currencies marked as your account's own follow whatever your provider account is configured for.
Live
Security
Money is the one place "probably fine" is not a design.
Commerce is built around a simple rule: nothing is treated as true because something said it was. A webhook is a prompt to go and check, a customer's claim is not evidence, and a payment is confirmed only after OpsIQ asks the provider itself and the answer matches on every field.
The confirmation card
A card is an artifact, not a sentence.
The card a customer confirms carries a signed payload: a nonce, the workspace, the conversation, the product, the quantity, the unit price, the currency, an expiry and the exact amount each gateway would take. It is signed with an HMAC over that payload using a key derived for your workspace alone, and verified with a constant-time comparison.
Three surfaces may confirm and every look-alike is refused by name: a chat message, free text, a model tool call, a page refresh, a replayed request, an inferred intention.
No signing key means no card. The path fails closed rather than falling back to an unsigned offer.
Confirming twice buys once. The offer is claimed atomically, and a second confirmation returns the first result rather than a second order.
Live
Every gateway is provider-hosted. A boundary class allows only a reviewed set of payment reference fields and refuses instrument fragments by name: card number, CVV, expiry, track data, PIN block, IBAN, sort code and more. A provider token is not a card, and is useless anywhere else.
Forged, replayed, stale and out of order are four different attacks, so they get four different answers rather than one boolean. Signatures are compared in constant time, and a webhook whose scheme does not authenticate the whole body is treated as a prompt to look the payment up, never as proof.
An operation carries an idempotency key bound to the workspace, the transaction and the exact parameters, claimed atomically. The store answers with four outcomes, not two: fresh, replay, still running, and conflict. A broken store throws rather than reporting fresh, because that is how an outage becomes a duplicate charge.
A reservation is a compare-and-swap against the exact count it read, taken inside the order's own transaction. Digital codes are claimed the same way, and a shortfall rolls the whole order back before anything is charged rather than promising a code that is not there.
Where OpsIQ owns the payment, a chat order needs an emailed six-digit code first. The code is stored only as a salted hash, attempts are counted before the comparison, the window is bounded, and burning it is a single atomic update so parallel confirmations cannot all pass.
Commerce is covered by four layers of tests and by a mutation-proof harness. The harness breaks a guard in the source, requires a named door-level test to go red, then restores the file and checks the bytes match. A guard nobody has ever seen fail is unproven.
These describe technical controls in the platform. They are not a compliance certification, and nothing here should be read as one. If you need a formal attestation for your own audit, talk to us about what your acquirer or auditor is asking for.
Running the shop
The unglamorous half, which is most of retail.
Selling is the easy part. What follows is the work: the customer who wants their order history, the parcel that ships in two pieces, the refund that was half paid in credit, the shopper who needs a size, the cart that was left at the door.
Customer accounts
Sign-in with a password, order history, addresses, downloads and tracking in one place. Someone who ordered through a chat months ago can claim the same account with their email and find every one of those orders waiting.
Store credit as a real ledger
Credit is an append-only ledger and the balance is always derived from it, never a number somebody edited. It is kept per currency and never converted, and spending it is atomic inside the order's transaction.
Gift cards and licence codes
Sell from a shelf of encrypted codes: gift cards, prepaid cards, licence keys and scratch cards. A code is claimed when the order is placed and revealed after payment, so the same code can never go to two people.
Tips that stay honest
A percentage tip is worked out on the server against the goods after discount, never on shipping or tax, and it is never taxed itself. A tip can never exceed the order it sits on, on either the cart or the buy-now path.
Split shipments
Send part of an order now and the rest when it lands. Each shipment carries its own carrier and tracking, and the arithmetic will not let you ship more of a line than the order actually holds. The customer sees each piece on their account page.
Refunds that remember how it was paid
An order paid half in credit and half by card is refunded proportionally back to both. Refunding is transactional and idempotent, so pressing the button twice returns the money once.
Abandoned-cart reminders, capped
Only somebody who typed their own email at your checkout is ever written to, at most twice per cart, ever. The cap is claimed in the database before the message goes out, and one click stops it permanently with no sign-in.
Industry kits
Seven starting points, for fashion, food, cosmetics, books, downloads, services and prepaid goods. A kit is a preview before it is an action, and each one is checked by its own verifier rather than trusted because it is in the box.
The onboarding drafter
Answer one question about what you sell and OpsIQ drafts the shop: a fitting kit, your store copy and a handful of products. Everything it makes arrives as a draft. You read it, change it, and decide what gets published.
The shop-floor assistant
A "help me choose" panel that can recommend from your catalogue and nothing else. Every reason it gives has to be a phrase already written on that product, and any sentence it composes for itself is thrown away rather than shown.
Size guide
Arithmetic against the chart you published for that product, and nothing more. Where there is no chart there is no answer, so a model cannot turn a missing size guide into a confident recommendation.
Launch readiness and a maturity register
Readiness asks the questions a shopper would: is there anything to buy, can they pay, can it reach them, will anybody be told, can you be contacted. Maturity is computed from your own settings and records, never declared.
Live
Press it twiceRefunds once
Money that is already yours
Credit is a history, not a field.
The reason store credit is a ledger rather than a number on a customer record is that a number can be wrong and nobody can tell. A history can be read back, added to, and never quietly adjusted. The balance is the sum of what happened.
Granted on a refund settlement or as goodwill by you, and spent at checkout inside the order's own transaction.
Held per currency and never converted, so a euro credit stays a euro credit rather than drifting with a rate.
The credit email comes from the signed-in session, never from the request, so nobody can spend a balance by naming somebody else's address.
Gift cards are a different mechanism and worth keeping straight. You sell them from a stock of codes, and a code is delivered after payment. Store credit is the ledger above. Today a gift-card code is not redeemed into a credit balance, so plan your offer around selling the code rather than around a redeemable wallet.
Store Intelligence
Numbers that admit when they cannot answer.
Unique visitors, product views, cart additions, checkout starts, abandons and completions, conversion, confirmed orders, revenue, acquisition, devices and places, top products and recovery. Conversion is built only from explicitly tagged public-store events, so it counts what actually happened rather than what looked close enough.
Currencies are never silently combined. Revenue is reported by currency, because adding them up quietly is how a number becomes fiction.
A dash is not zero. Where the range cannot answer the conversion question you get a dash and a reason, not a confident nought.
Data-quality warnings surface rather than hiding, so you know when a figure is thin before you act on it.
The same snapshot is available over the API as a privacy-safe aggregate carrying no customer identities.
Live
ConversionTagged events only
Commerce connectors
Already selling somewhere else? Bring it into the conversation.
A connector does not get to sell because of its name. It declares which of its own operations answer OpsIQ's canonical commerce roles, and what it declares is exactly what it may do. Declare nothing and it disappears from the selling settings on its own. There is no list to be added to.
Search it, explain it, never sell it
The assistant can find products and describe them accurately, but there is no executable order and no checkout. Every package stays here until its own typed quote and order actions pass the deeper contract, because a platform's reputation is not evidence that its integration can take money.
- Magento 2
- PrestaShop
- OpenCart
- osCommerce
- Stripe catalogue
- Squarespace
- Webflow
- Wix
Your platform issues the checkout
The connector returns a real checkout address minted by the merchant platform itself, along with the canonical quote. The address has to be HTTPS, its host has to match what the package declared, and the quote is short-lived. A product link or a cart URL assembled locally is not a checkout capability.
- Shopify
- BigCommerce
- Square
The order is created on your platform
The deepest mode. OpsIQ refreshes the quote immediately before executing, supplies the idempotency key, and after any unknown outcome asks a recovery lookup before it retries anything. The create action has to run your platform's own pricing, stock and order logic. A raw database insert is refused outright.
- WooCommerce
- WHMCS
- Botble
- OpsIQ SaaS Bridge
Declaration is the whole contract
A connector says what it can do. Nothing else counts.
OpsIQ never guesses a capability from an action's name, a platform's reputation or a vendor's marketing. A package ships a role map naming which of its own operations answer each canonical role, and that file is inside the signed package. Remove a role, or uninstall the connector, and a proposal that was already on screen stops being valid rather than leaving stale authority behind.
Declared, then verified. A mapped operation must actually exist in the package's own action manifest, or the claim is rejected rather than failing silently in front of a customer.
A read role cannot point at something destructive, and a write role cannot map to a generic record insert, which would bypass the platform's own pricing, stock locking and confirmation.
Every write declares a recovery lookup. The dangerous timeout is the one after your platform may already have created the order, and without a lookup the only options are to retry blind or lose it.
Three tools, not eighteen. The assistant calls one tool per verb with your connector as a parameter, so a shop with six connectors still has three tools and one set of rules.
Live
Uninstall itOffers expire
WooCommerce
Talks to the WooCommerce REST API on your own WordPress. Orders, refunds and order notes, products with variations and attributes, customers, coupons, tax rates, shipping zones and methods, sales and product reports. It is one of the connectors that can create a real order from a conversation, with a recovery lookup behind it.
Shopify
Works over the Shopify Admin API. Orders, transactions including capture and void, refunds, fulfilment orders and tracking, products, variants, inventory levels and locations, customers, draft orders, discounts, gift cards and abandoned checkouts. In chat it quotes and then hands the customer to Shopify's own checkout.
WHMCS
The reference implementation of the commerce contract, and the deepest integration here. Invoices, transactions, credit and quotes, orders, client records and contacts, services with suspend, upgrade and price changes, domains with registration, transfer, renewal and nameservers, tickets and products. It can create a real order, and prices per client because WHMCS taxes by the client's own profile.
BigCommerce
Orders with products, messages, statuses and shipping addresses, payment capture, void and refund quoting, shipments, catalogue products and variants, categories and brands, customers and customer groups, coupons, gift certificates, carts, price lists and channels. Quotes in chat, then hands over to the BigCommerce checkout.
Magento 2 and PrestaShop
Deep read-and-write integrations for the shop itself: orders, invoices, credit memos and shipments on Magento; orders, states, invoices, credit slips, carriers and tracking on PrestaShop, across both its classic web service and the newer admin API. In a conversation both stay at catalogue level today.
OpenCart and osCommerce
Orders and order history, returns, products, stock and price, categories, customers and addresses, coupons and reports on OpenCart. osCommerce bridges both its legacy install and the newer REST interface, including order status, cancellation and refund. Both are catalogue-level in chat.
Stripe
Customers, charges and refunds, payment intents and payment methods, subscriptions and subscription items, invoices and credit notes, products and prices, coupons and promotion codes, disputes, payouts and balance reporting. It also carries the three obligations of a payment package, so it can be the gateway as well as a catalogue.
Square
Customers, orders, payments and refunds, catalogue items and locations, plus customer self-service for a shopper's own profile and orders. In chat it quotes and then issues a Square payment link. It is one of two gateways certified inside an existing connector rather than shipped as a separate package.
Botble
A hotel and booking integration rather than retail. Room catalogue, a quote for a stay, native booking checkout, bookings with status and cancellation, payments, guests, and self-service so a guest can see and cancel their own booking. It can create a real booking from a conversation.
Paystack and the gateway packages
A gateway package is a narrower thing than a store connector, and deliberately so. It declares what currencies, countries, methods and environment it is configured for, verifies the provider's own webhook signature scheme, and maps that provider's event names onto canonical ones. It never decides that a payment succeeded.
The OpsIQ SaaS Bridge
Connects an OpsIQ-hosted billing platform as a commerce source: catalogue, quotes, customers, orders, invoices, payment methods and payment recording, with reconciliation on a schedule so a dropped webhook cannot quietly lose revenue.
Scheduled reconciliation
Any connector whose platform can list completed sales declares that it reconciles, and OpsIQ re-reads that list on a schedule through the same idempotent writer. A webhook that never arrived is found on the next pass. A package that could reconcile and does not fails conformance.
For developers
A contract you can read, and tools that tell you when you are wrong.
Commerce is not a set of integrations we happen to have written. It is a published contract with a version number, machine-checked schemas, conformance commands you run yourself and a signing step. Whatever you build sits beside what we built, under the same rules.
Live
Three ways in
Build a connector, a gateway, or just call the API.
A connector. Contract 2.4, 57 declared capabilities, seven package profiles, JSON schemas for every manifest, and a commerce role map whose vocabulary is closed. Packages are signed over a hash of every file, so an edited package stops verifying.
A payment gateway. Implement the storefront payment driver: its slug, an environment check, create a checkout, look a payment up, refund, normalise a webhook, and supply fixtures. Admission is fail-closed and needs seven fixtures and six passing checks, including amount mismatch, currency mismatch and webhook replay.
The public API. Typed commerce actions for products, orders, refunds, the storefront shape and catalogue, pages, launch readiness and an analytics snapshot, under least-privilege scopes. Quotes can be created over the API; confirmation never can.
Discovery that is generated, not written. The documentation, the OpenAPI document and the Postman collection all come from the same registry the request validator uses, so they cannot drift from what the platform actually accepts.
Write roles declare a recovery lookup
A read role may not call a destructive operation
Raw record writes are refused structurally
Before you open the doors
A readiness check that asks what a shopper would ask.
Most launch checklists score you. This one asks the five questions that decide whether a stranger can actually buy from you today, and every answer comes with the thing to go and do rather than a percentage.
Is there anything to buy? A published product with a price, a currency and stock that means something.
Can they pay? A gateway connected, or an offline method whose conditions are actually satisfied.
Can the goods reach them? Delivery zones or somewhere to collect from for physical items, protected files or codes for digital ones.
Will anybody be told? A receipt that sends, and a route by which you find out an order exists.
Can you be reached? Real contact details and policy pages with your own words in them, not the starter text.
Blockers stop the launch
Warnings keep warning
Maturity is measured, never declared
Live
Starter textKeeps warning
FAQ
Before you start selling.
Straight answers about the store, the money and what the assistant is and is not allowed to do.
A real store. Products with variants, options, media and fulfilment rules, a theme you tune, pages built from blocks, promotional panels, menus, a cart, a checkout, customer accounts, order tracking and downloads, on your own address. You can open the live demonstration store from this page and use it.
OpsIQ ships 17 certified gateways spanning Africa, Europe, the Americas, Asia-Pacific, global providers and crypto, plus 4 offline methods: bank transfer, cash on delivery, pay on collection and pay in store. If yours is not there, you can build it: the payment driver is a fixed interface and admission is a fail-closed certification run rather than a code review. A further 4 providers are deliberately not shipped, each with its reason written down.
No. Every gateway uses provider-hosted checkout, so the card is entered on the provider's own page and OpsIQ only ever holds a reference to a payment. The boundary is enforced in code: only a reviewed list of payment reference fields is accepted, and instrument fragments such as a card number, CVV, expiry or track data are refused by name. This is a technical control and not a compliance certification.
No. The assistant can search your catalogue and ask the server for a quote, but the server prices the order and signs the confirmation card. Confirmation is the card's own button on the web or an exact confirm command on a channel. Nothing the model writes can create an order, and the shop-floor assistant's own prose is discarded rather than filtered.
The website chat widget, WhatsApp, Facebook Messenger, Instagram direct messages, Telegram, LINE, SMS and X direct messages. You choose which of them are open under your commerce settings, and a channel you have not ticked cannot sell no matter how the conversation goes.
No. Connect the store you have and it becomes part of the conversation. What a connector may do is set by the roles it declares: some can only search the catalogue, some can quote and hand the customer to their own checkout, and some can create a real order on your platform using your platform's own pricing and stock logic.
Pause all selling in your commerce settings. Catalogue browsing, look-ups and releases keep working, while proposing and confirming stop on every channel at once. Facts that are already true, such as a payment that has landed, are queued rather than executed or reported as done.
Yes, and each carries its own conditions. Cash on delivery appears only when something is genuinely being delivered and the total is under the ceiling you set. Pay on collection appears only on a collection order. Pay in store appears only when you have published somewhere a person can walk into.
Commerce is part of the OpsIQ platform rather than a separate per-seat product. Exact inclusions vary by plan, so see pricing for each tier, and there is a free way to start.