Checkout
Guest checkout
Shoppers buy without an account. The cart survives in a cookie, orders can be looked up later, and the cart merges into the account if they sign in.
RAIN Store 27 — by MrZaKaRiA IT Solutions
Self-hosted ecommerce platform. No monthly fee, no per-sale commission.
RAIN Store is a self-hosted ecommerce platform that runs your online shop on your own server, licensed once per domain, for SMEs and D2C brands. It is built by MrZaKaRiA IT Solutions on Laravel 13 and Vue 3: storefront, checkout, a 65-page admin back-office, 23 payment providers and 12 shipping carriers in one codebase. You own the build, the database and the customer list. No platform takes a cut of your orders. There is no public price list, so the next step is a scoped quote.
SCROLL
0%
Commission on your sales, and no monthly platform fee. The licence is per domain, not per order.
23
Payment providers in the build: 21 online gateways plus cash on delivery and manual bank transfer.
12
Shipping carriers with per-order booking, tracking, label download and cancellation from the admin.
11 of 50
Catalogue modules carry a GA label. 3 are beta and 36 are alpha. The admin shows you which is which.
What it is
One codebase, one server, one licence per domain.
RAIN Store is a single-tenant e-commerce platform built by MrZaKaRiA IT Solutions. A Laravel 13 REST API - 556 route declarations, 126 controllers, 93 Eloquent models, 133 migrations - sits behind a Vue 3.5 storefront and a 65-page admin back-office. 176 Vue components in total, compiled by Vite 7.
It installs on ordinary hosting. One Apache document root with PHP-FPM, SQLite for a small catalogue or MariaDB and MySQL for production. Redis and Meilisearch are optional. No Docker, no Kubernetes, no reverse proxy required.
The commercial model is a licensed build. Each build is signed with its own 256-bit HMAC secret and bound to one domain, with a term set in months or a lifetime licence. You self-host it. Your database and your uploads stay on your server. Ask for a quote and get the licence term in writing before anything is cut.
New in version 27
What changed in RAIN Store 27
Shipped on the version 27 line between July and September 2026. Each item is in the code, not on the roadmap; the roadmap items are named further down, with their status.
Payments
Real refunds, saved cards, one-click reorder
Refunds go through Stripe and PayPal from the admin, money captured without an order is recorded and refundable on a 'Money owed' page, and returning shoppers can save a card and reorder a whole past order.
Conversion
A rebuilt buy box
Recently viewed, frequently bought together, an accordion checkout, wallet payment first, and a sticky mobile call to action on a product page rebuilt for clarity.
AI
AI reports you control
Save, print, share and schedule AI answers about your shop. You choose the model — including any local Ollama model — with a local fallback and a daily token budget.
ERP
One RIVER ERP, many stores
A single RIVER ERP can now run several RAIN stores, with RIVER stock changes recorded in the store's inventory ledger.
Speed
Measured on MariaDB
Product list from 756 to 1,282 requests a second and the admin dashboard from 47.9 to 72.3 at 20 concurrent users; a product with 313 reviews went from about 188 KB to 44 KB.
Core build
What ships before you enable a single optional module.
These parts are verified in the codebase, not entries in a catalogue. Optional modules are a separate section further down, with their real maturity labels.
Storefront
Catalogue, cart and checkout
Category browsing, search, sort and pagination. Product detail with variants and colour swatches. Wishlist, guest and account checkout, order tracking. Dark mode, RTL, and English, French and Arabic storefront locales.
Money path
Payments, refunds and a revenue ledger
23 payment providers behind one contract. One signature-verified webhook ingress with database-level idempotency. Partial refunds are first-class and reconcile against a revenue ledger, with an admin page for payments captured without an order.
Fulfilment
12 carriers and a fulfilment workspace
Book, track, download labels and cancel per order. Bulk booking and A6 thermal label PDF merge. Customer-facing rates stay zone-based, so checkout never waits on a carrier API to answer.
Back-office
65 admin pages
Orders, products with bulk operations, inventory with buy cost and realised profit, customers, coupons, review moderation, staff with per-resource permissions, CMS pages, audit log, tax report, risk queue, security centre. Cmd+K command palette across admin surfaces.
Storefront editing
Drag-to-reorder homepage builder
Homepage sections behind a widget registry, each with scheduling, audience and device targeting. Links a merchant types in are URL-scheme allow-listed at save time.
Operations
22 artisan commands
Including rain:doctor, a single-shot health check across environment, storage, migrations, settings drift, missing images, AI providers and queue driver. Plus payments:reconcile, security:audit, database backup with S3 or Dropbox sync, and WebP conversion.
Payments and carriers
The rails that global platforms sell you as plugins.
Regional payment and shipping integrations are in the build. One provider contract, one signed webhook ingress, one place to configure. Cash on delivery is a real payment method here, not a workaround someone bolted on.
- 21 online gateways: Stripe, PayPal, Adyen, Square, Mollie, Klarna, Razorpay, MercadoPago, Afterpay, Sezzle, Tabby, CMI, HyperPay, PayTabs, MyFatoorah, Payssion, Revolut Merchant, Dodo, Zen, BinancePay and BTCPayServer
- Plus cash on delivery and manual bank or wire transfer as first-class methods
- 12 carriers: ATLAS Livraison, Amana, Aramex, Chronopost, DHL Express, FedEx, Fetchr, iMile, J&T Express, Naqel, SMSA and UPS
- Every carrier declares its own capabilities, so the admin hides actions that carrier does not support
- Webhooks are signature-verified with database-level idempotency, so a retried callback is not processed twice
ERP and POS
Storefront stock and warehouse stock, one number.
Orders, inventory, customers, returns and refunds sync both ways with RIVER ERP over a Standard-Webhooks-signed contract, with an audit log, a scheduled reconcile and a manual resync in the admin. This is the closed-loop manufacturing case that general platforms answer with a third-party connector app.
- Each store mints a permanent store id sent on every ERP call, so one RIVER instance can serve several RAIN storefronts
- A delivery addressed to the wrong store is rejected with a 409 rather than written to the wrong ledger
- Sync is idempotent and audited, so a failed run is visible instead of silent
- Odoo and Dolibarr client classes are in the build too, but the catalogue labels external ERP sync as alpha - treat those two as evaluation-grade
AI layer
Seven AI providers, including one that never leaves your server.
The AI layer sits behind one registry: OpenAI, Anthropic, Gemini, Groq, OpenRouter, NVIDIA NIM and local Ollama. Point it at Ollama and no product, customer or order data reaches a third party. That is the whole answer for a merchant with data-residency constraints.
- AI Commander answers admin questions in plain language, and every answer is signed with the permissions it required to produce
- A per-turn token and spend meter with a budget guard, so an AI bill cannot run away overnight
- AI Reports save Commander answers as printable, shareable, scheduled reports
- Bulk product copy, SEO text and image alt-text generation across the catalogue
- The merchant chooses the provider, the model and the spend cap - including installing any Ollama model
Engineering
The parts a developer will check first.
Counts and measurements taken from the repository in September 2026. Where a number comes from a benchmark rather than live traffic, it says so.
604 backend tests, PHPStan clean
134 backend test files holding 567 test methods, plus 14 frontend Vitest files. The 25 August 2026 working session reports the backend suite fully green at 581 tests with zero failures and PHPStan clean. CI runs Laravel Pint, PHPStan and PHPUnit on every push, with Dependabot on dependencies.
Admin dashboard p50 of 51 ms
Benchmarked on MariaDB 10.11, PHP 8.4 FPM, Apache mpm_event and Redis 7.4 with 1,500 products, 8,000 orders and 20,000 order items: dashboard p50 fell from 64 ms to 51 ms and throughput rose from 47.9 to 72.3 requests per second at 20 concurrent users. This work sits on the develop branch. Ask which branch your build is cut from.
Product listing at 1,282 rps
On the same develop-branch benchmark, /api/products throughput rose from 756 to 1,282 requests per second at 20 concurrent users, and a product page with 313 reviews dropped from a 188 KB payload to 44 KB once reviews were paginated. Rewriting month and year date filters as range predicates cut rows examined from 7,946 to 239. Single-machine benchmark, not live traffic.
Legible to AI assistants and crawlers
The storefront publishes /llms.txt, /.well-known/ai-plugin.json, /.well-known/agent.json, a sitemap index, RSS, and Schema.org Product and BreadcrumbList JSON-LD. Imagick renders a 1200x630 Open Graph card per product, category and homepage, so a shared link does not unfurl as a grey box on WhatsApp, X, LinkedIn or Slack. Discovery only - see the module caveats below on agent checkout.
One codebase, five surfaces
Storefront, admin, PWA, a Capacitor 6 iOS and Android shell with Fastlane beta and release lanes, and a visionOS Swift scaffold. Products can carry GLB and USDZ models rendered through model-viewer, giving iOS Quick Look and Android Scene Viewer AR placement from the product page.
Security that is in the build today
Admin two-factor by email OTP plus TOTP, per-route permission middleware, mutation audit logging, HMAC-signed webhooks with replay protection and SSRF guards, encrypted settings at rest, GDPR export and account-deletion endpoints, cookie consent. There is no SSO, no passkeys and no admin IP allow-list, and no SOC 2, ISO 27001 or PCI attestation.
Module catalogue
50 modules. 11 GA. Here is exactly what that means.
Modules are optional capabilities layered on the core build above. Each carries a lifecycle label you can read at /admin/modules before you switch it on. Read this before you read any module list as a feature list.
- 11 of the 50 modules carry the GA label. 3 are beta. 36 are alpha.
- GA and verified end to end with a working admin surface: returns and RMA portal, loyalty points with tier multipliers, double-sided referrals, abandoned-cart recovery over email, SMS and push, web and native push notifications, and 3D and AR product viewing.
- Alpha, in the platform's own words, means partial functionality, enable for evaluation only, not for high-volume stores. That is 36 modules.
- Alpha includes the ones a demo tends to sell hardest: B2B wholesale portal, tier pricing, subscription boxes, memberships, visual search, AI shopping assistant, live shopping, personalised homepage, virtual showroom, multi-warehouse routing, dropshipping, print-on-demand, dynamic pricing, AI inventory forecasting, and the WhatsApp and Telegram bots.
- Three modules currently labelled GA do not yet do what the label implies. Recurring subscriptions advance the charge dates but take no payment. Agentic checkout validates a request, writes an audit row and returns received - it creates no order and takes no money. Gift cards can be issued, adjusted and redeemed by an admin, but a customer cannot buy one on the storefront.
- Home screen widgets for iOS and Android are beta: the backend feeds are live, the native widget code is not written.
- Virtual try-on with face tracking is a plan, not a build. Only model-viewer 3D and AR placement is verifiable in the shipped dependencies.
- Switching a module off is real: the route middleware returns 404 and a storefront composable hides the surface, so a disabled module is not a hidden endpoint.
Straight talk
The catch, before you have to ask for it.
There are no reference customers. No named production store, no case study, no third-party review. That is why this page carries no testimonials - inventing them would be the cheapest thing on it. Every number here comes from the repository: file counts, test counts, benchmark output. Ask to see the source of any one of them on a call.
This is a young codebase. First commit 9 March 2026, 335 commits of history, frontend version 27.0.1. The newest performance and money-path work sits on the develop branch. Confirm which branch your build is cut from before you sign.
One maintainer. RAIN Store is built and maintained by MrZaKaRiA IT Solutions. That is a genuine concentration risk, and 21 gateways, 12 carriers and 7 AI providers all break independently when a third party changes an API. No SLA or support-hours commitment is published. What protects you is where it runs: on your server, on a standard Laravel and Vue stack, with your data in ordinary MariaDB. What level of source access you get is a contract question, so settle it in the quote rather than after launch.
One store per deployment. There is no shared multi-tenant admin. Two brands means two full installations. Multi-store is not started, and neither is SSO, passkeys or admin IP allow-listing.
The licence is domain-bound. Each build is tied by HMAC to one domain with a term in months or a lifetime licence, enforced through three runtime anchors that fail closed. Moving domains or letting a term lapse locks the build until it is re-issued. Remote revocation is documented as design only and is not implemented, so nothing phones home to switch you off mid-trading.
Self-hosting is real work, and migration is bespoke. You need a server, PHP-FPM, a queue worker under Supervisor, a cron scheduler, backups and TLS. And there is no importer from Shopify, WooCommerce or Magento - moving a catalogue, customers and order history is hand-written work that gets scoped and priced, not assumed away.
Related work from the same maker: RIVER ERP, the warehouse, purchasing and POS side that RAIN Store syncs with, and ERP Store. Past delivery is in the portfolio, and a direct question is welcome at contact.
How delivery works
From first call to a store you own.
Five steps. Scope, licence term and migration cost are written down before any build is cut.
01
1. Scope call
Catalogue size, payment methods, carriers, ERP or POS systems, and which modules you actually need. On this call you get told which of them are alpha, and whether RAIN Store is the wrong fit for you.
02
2. Written quote
Fixed scope, the licence term in months or lifetime, the domain the build will be bound to, and a separate line for migration. No public price list exists, so the number comes from your scope rather than a plan tier.
03
3. Build and configure
A licensed build is cut for your domain. Storefront design, payment providers, carrier accounts, tax and shipping zones, and the AI provider you choose - including a local Ollama model where data has to stay in-house.
04
4. Migration and data load
Products, variants, images, customers and order history are moved by scripts written against your export. There is no one-click importer from another platform, so this is scoped as work and priced as work.
05
5. Launch and handover
DNS cutover, a live payment test, a rain:doctor health check, then the credentials, the deployment and the database are yours. Who owns the server afterwards is agreed in writing before launch, not discovered after it.
Next step
Get a quote with the licence term in writing.
One call covers your catalogue, your payment rails, your carriers, your ERP and which modules are actually ready for your traffic. If RAIN Store is the wrong tool for your business, you will hear that on the call rather than after the invoice.
Compare
Shopify alternative with no monthly fee: an honest comparison
WooCommerce is a good answer to several of these and Shopify wins outright on others. Where an alternative ties or beats RAIN Store, the table says so.
| Capability | RAIN Store | Shopify | WooCommerce |
|---|---|---|---|
| No monthly platform fee | ✓ | — | ✓ |
| No per-sale commission taken by the platform | ✓ | Partial | ✓ |
| You host the database, uploads and customer list | ✓ | — | ✓ |
| Runs on a stack your own developers can work in (Laravel + Vue) | ✓ | — | ✓ |
| Regional gateways in the core build (CMI, HyperPay, PayTabs, MyFatoorah, Tabby) | ✓ | Partial | Partial |
| Regional carriers in the core build (ATLAS Livraison, Amana, SMSA, Naqel, iMile) | ✓ | Partial | Partial |
| Cash on delivery as a first-class payment method | ✓ | Partial | ✓ |
| Bidirectional ERP sync written by the platform vendor, not a third-party app | ✓ | — | — |
| AI admin assistant included | ✓ | Partial | — |
| AI that can run entirely on your own hardware | ✓ | — | — |
| Third-party app and plugin ecosystem | — | ✓ | ✓ |
| One-click importer from your current platform | — | ✓ | Partial |
| No server, queue worker or backups to administer | — | ✓ | Partial |
| Published price and self-serve signup | — | ✓ | ✓ |
| Independent PCI DSS or SOC 2 attestation | — | ✓ | Partial |
| Proven at scale under named public brands | — | ✓ | ✓ |
What protects you
You own the build. Here is what that is worth on a bad day.
The build runs on your server. The database, the uploads and the customer list are files you can copy tonight. Standard MariaDB or MySQL, standard Laravel migrations, standard Vue components - nothing proprietary in the storage layer, no export ticket to raise with anyone. GDPR export and account-deletion endpoints are already in the build, so a customer data request is an endpoint call rather than a project. If MrZaKaRiA IT Solutions stopped answering tomorrow, your store would keep taking orders on your own server, on a standard Laravel and Vue stack rather than a runtime only one vendor can operate. That is the honest answer to single-vendor risk. It is not a promise about the vendor, it is a property of how the thing is delivered.
Coming in is the harder direction, and pretending otherwise would cost you money later. No importer exists from Shopify, WooCommerce or Magento. Migration is hand-written scripts against your export, scoped and priced before the build starts, with a SQLite-to-MariaDB tool for growing a small install into a production database. The licence is bound by HMAC to one domain, with a term in months or a lifetime licence, and moving domains needs a re-issued build. Get the domain and the term written into the quote. Ask for the licence text at quote stage, and settle source access in it, before you sign. Treat it the way you would any other supplier contract.
Deployment scenarios
Three shapes of business this build was designed around.
These are illustrative scenarios, not customers. No RAIN Store deployment has been published as a reference. Nothing below is a quote, a named client or a measured result from a real store - each one simply shows how the shipped parts fit a buyer type, including where they do not fit.
ERP syncInventoryMade to order
Illustrative scenario - furniture or garment manufacturer
Made-to-order manufacturer with a workshop behind the shop
A manufacturer selling direct while running production on RIVER ERP. The storefront is not the hard part. The hard part is that storefront stock and workshop stock are two different numbers.
Problem
Online stock, warehouse stock and POS stock are reconciled by spreadsheet and manual re-keying. Overselling is discovered after the customer has paid. Hosted platforms answer this with a paid connector app maintained by a third party who did not write either system.
Solution
RAIN Store syncs orders, inventory, customers, returns and refunds both ways with RIVER ERP over a signed, idempotent webhook contract, with an audit log and a scheduled reconcile. Each store carries a permanent store id, so one RIVER instance can serve several storefronts and a misaddressed delivery is rejected with a 409.
Outcome
- Storefront and workshop read the same stock figure
- Sync failures land in an audit log instead of passing silently
- The connector is written by the same vendor as both systems
- Multi-warehouse routing would be alpha here, so plan around a single stock location
Shopify alternativeOwned buildMigration
Illustrative scenario - D2C brand on a hosted plan
D2C brand leaving a hosted platform over fees
A brand whose platform bill and per-sale commission grow with revenue while what the platform contributes stays flat.
Problem
A monthly plan plus a cut of every order. Customer data inside someone else's system with no clean way out. Checkout and design changes gated by what the theme and the app store permit.
Solution
A licensed RAIN Store build bound to the brand's own domain and self-hosted, with the payment providers and carriers its markets actually use configured before launch. Catalogue, customers and order history are migrated by hand-written scripts. Cost moves from a recurring percentage of revenue to a scoped project plus hosting.
Outcome
- No platform fee and no per-sale commission after cutover
- Customer list and order history sit in the brand's own database
- Migration is quoted up front, because no importer exists to hide it in
- The brand takes on a server, a queue worker, backups and TLS in exchange
White labelPer-domain licenceLaravel
Illustrative scenario - web agency or IT integrator
Agency deploying one branded instance per client
An agency that wants a platform it can brand and deploy repeatedly without rebuilding checkout, payments and fulfilment for every client.
Problem
Each new store means assembling a plugin stack whose updates conflict and whose security surface nobody owns, or reselling a SaaS plan the agency does not control and cannot extend.
Solution
One licensed build per client domain on ordinary Apache and PHP-FPM hosting. The homepage widget registry and the 34-toggle customer features switchboard cover most per-client variation without code. Where code is needed it is Laravel 13 and Vue 3 rather than a proprietary template language. Agree source access in the licence before the first client build.
Outcome
- One codebase across every client instead of a different plugin stack per store
- Per-domain licensing keeps each client's build separate
- Know the limit up front: one store per deployment, with no shared multi-tenant admin
Before you buy
What you need on your side.
Self-hosting is the trade you make for owning the build. This is the actual list, not a shortened one.
- A Linux server or VPS you control. Apache 2.4 with mod_proxy_fcgi and PHP-FPM on a single document root; an Nginx reference config is also provided.
- PHP 8.2 or newer. The README recommends 8.3 or later and the published benchmarks were run on 8.4.
- MariaDB 10.6+ or MySQL 8+ for production. SQLite is fine for a small catalogue, and a tool ships for moving up later.
- A queue worker under Supervisor and a cron entry for the scheduler. Both are required. Abandoned-cart journeys, scheduled reports and ERP reconcile all run there.
- Backups and TLS. A database backup command with Dropbox and S3 sync ships in the build; someone on your side still has to confirm it runs.
- Optional: Redis for cache, queue and session, Meilisearch for storefront full-text search, Imagick or GD for WebP and Open Graph card rendering.
- Optional integrations, each with its own account: Sentry, PostHog, Microsoft Clarity, Flagsmith, UptimeRobot, Telegram alerts and Cloudflare Turnstile.
- A decision on who owns the server long-term - your team, your host, or a written arrangement. Make it before launch.
- Note for procurement: the admin panel interface is English only today. The storefront ships English, French and Arabic with real RTL.
Clients
What clients say about working with MrZaKaRiA IT Solutions
Named clients, on the engagements they actually ran with us — build, ERP and hosting work rather than reviews of this specific product.
The web design services provided by MrZaKaRiA are top-notch. The aesthetics, functionality, and user experience of our website have significantly improved. We’ve received numerous compliments from our clients. Highly recommended!
GMAB
CEO & Founder, GMAB
MrZaKaRiA programming services are exceptional. They’ve helped us develop robust ERP solution that have streamlined our operations. Their team is knowledgeable, efficient, and a pleasure to work with.
ALFIRMA
Manager, ALFIRMA
As a startup, we needed a reliable partner for our online presence. The web design, programming, and hosting services we received were outstanding. MrZaKaRiA played a crucial role in our success. We couldn’t be happier!
SHI
CEO & Founder, SHI
We’ve been using MrZaKaRiA hosting services for over a 4 year now, and the uptime is fantastic. Our website loads quickly, and we’ve experienced no downtime. Their customer service is responsive and helpful whenever we have questions.
BANG SHOPPING
Manager, BANG SHOPPING
FAQ
RAIN Store: questions buyers ask before the first call
Straight answers, including the ones that cost a sale. Each answer stands on its own.
RAIN Store is a self-hosted Shopify alternative with no monthly platform fee and no per-sale commission. Built on Laravel 13 by MrZaKaRiA IT Solutions, it is licensed once per domain and installed on a server you control, so the database, the uploads and the customer list stay with you. No public price list exists: the quote is scoped per store at /booking. You still pay for your own hosting and your own payment gateway fees.
2
What is RAIN Store built with?
RAIN Store is built on Laravel 13 with PHP 8.2 or newer, behind a Vue 3.5 single-page storefront compiled by Vite 7. The backend declares 554 API routes across 126 controllers and 93 Eloquent models with 132 migrations. The frontend holds 176 Vue components, 65 of which are admin pages. It runs on Apache with PHP-FPM on one document root, using SQLite or MariaDB, with Redis and Meilisearch optional.
3
Which payment gateways and shipping carriers does RAIN Store support in Morocco and the Gulf?
RAIN Store ships 23 payment providers. The 21 online gateways include CMI, HyperPay, PayTabs, MyFatoorah and Tabby alongside Stripe, PayPal, Adyen and Mollie, and cash on delivery plus manual bank transfer are first-class methods. Twelve carriers are integrated, including ATLAS Livraison, Amana, SMSA, Naqel, iMile and Aramex next to DHL Express, UPS, FedEx and Chronopost, each with per-order booking, tracking, label download and cancellation.
4
How many RAIN Store modules are actually production-ready?
RAIN Store's catalogue holds 50 modules across 8 categories: 11 carry a GA label, 3 are beta and 36 are alpha. The platform defines alpha as partial functionality for evaluation only, not for high-volume stores. Three modules currently labelled GA are incomplete - recurring subscriptions take no payment, agentic checkout creates no order, and gift cards cannot be bought on the storefront. The core storefront, checkout, payments, fulfilment and admin sit outside the catalogue and are shipped.
5
Can RAIN Store sync with an ERP or POS system?
RAIN Store syncs orders, inventory, customers, returns and refunds bidirectionally with RIVER ERP over a Standard-Webhooks-signed, idempotent contract with an audit log and a scheduled reconcile. Each store mints a permanent store id, so one RIVER instance can serve several storefronts and a delivery addressed to the wrong store is rejected with a 409. 3 ERP clients ship in total, but the catalogue labels external ERP sync alpha, so treat Odoo and Dolibarr as evaluation-grade.
6
Does RAIN Store include an AI assistant, and can it run locally?
RAIN Store includes AI Commander, an admin assistant that answers questions in plain language, with every answer signed by the permissions it required and a per-turn spend meter with a budget guard. 7 providers sit behind one registry: OpenAI, Anthropic, Gemini, Groq, OpenRouter, NVIDIA NIM and local Ollama. Choosing Ollama keeps every AI call on your own hardware, so no product, customer or order data reaches a third party.
7
How does the RAIN Store licence work, and can the vendor switch my store off?
RAIN Store is sold as a licensed build. Each build carries its own 256-bit HMAC secret and a token bound to one domain, with a term set in months or a lifetime licence, enforced at runtime through three independent anchors that fail closed. Moving to a new domain or letting a term lapse requires a re-issued build. Remote revocation is documented as design only and is not implemented, so nothing phones home to disable a running store.
8
Can I migrate my WooCommerce or Shopify store to RAIN Store?
RAIN Store has no built-in importer from Shopify, WooCommerce or Magento. Migrating products, variants, images, customers and order history is hand-written work against your platform export, scoped and priced before the build starts rather than assumed into it. A SQLite-to-MariaDB tool ships for moving a small install onto MariaDB 10.6 or later. Ask for migration to appear as its own line in the quote.
RAIN Store
Own the store instead of renting it.
Bring your catalogue size, your payment rails, your carriers and your ERP. You get a scoped quote, the licence term in writing, and a straight answer on which modules are ready for your traffic and which are not. Built and maintained by MrZaKaRiA IT Solutions.