01
Launching a first D2C store
A hosted platform with a custom theme, set up so it can grow.
Retail / Ecommerce Development
Ecommerce development for a single D2C or B2C store, from platform choice to checkout
Brands outgrow their first store, then face a choice between more apps, a headless rebuild or custom code, and every checkout change risks widening PCI DSS scope. Agnotic Technologies helps you choose the right route for one store, builds it, and keeps card data off your servers.
3 routes
Hosted, headless or custom
SAQ first
Checkout scope planned early
301 map
Replatforming without lost URLs
Trusted by global innovators
Industry Overview
What does ecommerce development involve for one store?
Ecommerce development for one store means choosing how it is built, either a customized hosted platform, headless on a SaaS commerce backend or custom code, then designing checkout so card data stays with the payment provider. Agnotic Technologies makes that choice with you, builds the store and moves your catalog, customers and URLs across.
Industry Challenges
Where do single-store builds go wrong?
The problems we are called in to fix usually trace back to one of these decisions.
The store keeps adding apps until checkout loads scripts from many vendors, and nobody can say which of them run on the payment page.
A headless rebuild starts before anyone checks whether the hosted platform could close the gap.
A custom checkout moves the card form onto the brand's own servers, taking the store from SAQ A to a much larger PCI DSS scope.
Replatforming changes every product URL without a redirect map, and organic search traffic falls after launch.
Customer accounts move but sign-in and marketing consent records do not, so returning shoppers are locked out or emailed without consent.
Accessibility is tested after launch, so checkout fails keyboard and screen reader users on day one.
Platform route
Hosted, headless or custom: which route fits your store?
Most single stores belong on the left of this table for longer than their teams expect. We move right only when a real gap forces it.
| Factor | Customize a hosted platform | Headless on a SaaS commerce backend | Custom build |
|---|---|---|---|
| Team you need | A theme developer and a store admin | Frontend engineers plus someone who owns the integrations | A product engineering team that owns the code, hosting and on-call |
| Catalog and pricing | Fits standard catalogs within the platform's variant limits | The backend's catalog model, with extra content in a CMS or PIM | Any model, including configurable or rule-based products |
| Checkout control | The platform's checkout, changed only where it allows | Platform checkout, or your own checkout calling the backend's APIs | Full control, and full responsibility for the payment integration |
| Extension limits | Apps and plugins; logic that does not fit becomes workarounds | Your own services around the backend's APIs | No platform limits, but you build every feature, including the basics |
| Hosting | Run by the platform | Storefront hosting is yours; the commerce backend is run by its vendor | All yours, from CDN to database |
| Fits when | You are launching, or your catalog and checkout are standard | A content-led brand needs a custom storefront over standard order logic | Commerce is the product, or your rules fit no platform |
Our Approach
How do we choose the right ecommerce route for your store?
How to build ecommerce for one store without regret comes down to three habits.
Start from the store you have
We list what the current store cannot do and test each gap against the hosted platform first. Many gaps close with configuration or one custom app.
Plan checkout around the SAQ
We choose the payment integration before checkout screens are designed, so the brand's design fits inside the scope you want to validate against.
Scope migration from day one
Catalog, customer, order and URL migration are planned at the start, not squeezed into the last sprint before launch.
Capabilities
What do we build for a single store?
Ecommerce services for the build itself. Store feature sets such as loyalty and subscriptions are covered on our platform pages.
Hosted platform themes and apps
Custom themes, sections and private apps that extend a hosted platform without forking it.
Headless storefronts
A Next.js storefront on a SaaS commerce backend's APIs, with content from a headless CMS.
Custom commerce services
Cart, pricing or order services for rules no platform supports, kept as small as the gap allows.
Checkout and payment integration
Hosted payment pages or provider iframe fields, wallets such as Apple Pay and Google Pay, and the order confirmation flow.
Payment page script control
A list of every script on the payment page with an owner and a reason, a Content Security Policy and alerts when a script or the page changes.
Data migration
Products, variants, customers, consent status and order history moved with checks on counts and spot samples.
Redirects and SEO continuity
A 301 map for every old URL, rebuilt sitemaps, canonical tags and structured data, and a crawl check after launch.
Accessibility and speed testing
Checkout and product pages tested against WCAG 2.2 and on mid-range phones before launch, not after.
Engineering Stack
Building blocks we choose between
Ecommerce cloud hosting is part of the same choice: a hosted platform runs it for you, while headless and custom stores need their own cloud setup on AWS, Google Cloud or Microsoft Azure, planned with our cloud consulting team.
Storefront
Hosted platform themesNext.js headless storefrontHeadless CMS
Commerce
SaaS commerce backend APIsCustom cart and order servicesPostgreSQL
Checkout
Hosted payment pagesProvider iframe fieldsApple Pay and Google PayContent Security Policy
Hosting
Platform-managed hostingCDN and edge cachingAWS, Google Cloud or Microsoft Azure
Checkout and PCI DSS
Which checkout method keeps PCI DSS scope small?
How the checkout takes card details decides which Self-Assessment Questionnaire (SAQ) a store usually validates with. Your acquirer or the card brands confirm the SAQ that applies; this is how we plan the build around it.
| Checkout integration | Usual SAQ | What the merchant maintains | Fits when |
|---|---|---|---|
| Redirect to the provider's hosted payment page | SAQ A | The redirect itself and the security of the site that sends shoppers to it | A standard checkout and the smallest scope matter most |
| Provider's payment fields embedded in an iframe | SAQ A, with the script-attack eligibility criterion | Protection of the page that hosts the iframe against script attacks, through techniques like Requirements 6.4.3 and 11.6.1 or written confirmation from the provider | You want card fields inside your own branded checkout |
| JavaScript or direct post: your page builds the form and card data goes from the browser to the processor | SAQ A-EP | Requirement 6.4.3 controls for every payment page script, plus more of PCI DSS on the servers that deliver the page | You need full control of the payment form |
| Card data passes through your own servers | SAQ D | Every applicable PCI DSS requirement on each system that stores, processes or transmits card data | Rarely worth it for one store, and almost always avoidable |
Measured Impact
What does a good store build improve?
Measures we agree before the build and check after launch.
Checkout completion
Started checkouts that finish
Tracked before and after the rebuild, by device.
Payment page scripts
Each one accounted for
Every script on the payment page has an owner and a reason.
Search traffic
After cutover
Organic visits to migrated URLs compared with the weeks before launch.
Release speed
Safe store changes
How quickly the team can ship a change to the live store.
Use Cases
When do brands bring us a store project?
Ecommerce for startups and growing brands usually starts from one of these moments.
02
Leaving an old platform version
Replatforming before support ends, with the checklist above.
03
Going headless for a content-led brand
A custom storefront over a SaaS commerce backend.
04
Branded checkout inside SAQ A
Embedded provider fields with the payment page scripts under control.
05
Merging two brand stores
One catalog and one checkout, with redirects for both old stores.
06
Rebuilding a store that outgrew its apps
Replacing a pile of plugins with a few owned features.
Integrations
What does a single store usually connect to?
Each connection is scoped on the scoping call. ERP and OMS sync is covered in depth on our retail software and OMS pages.
Checkout
Payment providerTax and shipping services
Orders
Order management system
Stores
Retail POS
Finance and stock
ERP
Customers
Email and SMS marketing
Tracking
Analytics and Search Console
What we check
Replatforming checklist: what has to move with the store?
We work through this list on every replatforming project, before the first line of the new store is written.
Catalog
- Products, variants and their IDs
- Images with their alt text
- Every product and collection URL recorded before cutover
- Reviews and questions you own the rights to
Customers
- Accounts and saved addresses
- A sign-in plan: migrated password hashes where both platforms allow it, or a reset email
- Marketing consent status kept with each customer
- Saved cards moved by the payment providers as tokens, never as card numbers
Orders
- Order history for customer accounts and service
- Open orders, returns and gift card balances settled or moved
- Subscription contracts and next billing dates
SEO and tracking
- A 301 redirect from every old URL to its new one
- Sitemaps, canonical tags and structured data rebuilt
- Search Console checked for crawl errors after launch
- Analytics and conversion tracking tested again
Compliance-First Development Services Backed by Global Standards
We build secure, scalable products designed for privacy, interoperability, and regulatory readiness from day one across every sector we serve.
General Data Protection Regulation
Implement lawful consent flows, data minimization, and secure processing for global data privacy.
Payment Card Industry (PCI DSS)
Securing payment transactions and protecting cardholder data with industry-best practices.
Our Edge
Why Global Leaders Choose Us
We combine deep technical expertise with industry-specific knowledge to deliver solutions that aren't just functional, but transformational.
Enterprise-Grade Security
We implement rigorous security protocols and compliance standards (HIPAA, GDPR, SOC2) across all industrial solutions to protect sensitive data.
High-Performance Scaling
Our architectures are built to handle massive data loads and user bases, keeping performance steady whether you're serving ten or ten million.
Accelerated Time-to-Market
Using our suite of internal tools and proven frameworks, we cut setup work so your first release reaches users sooner.
Embedded AI Integration
Beyond simple wrappers, we build deep-learning integrations and predictive analytics directly into the core of your industry-specific workflows.
Engagement Model
How does a store build work with us?
It depends on scope; we agree a fixed first release on the scoping call.
01
Scoping call
We review the current store, list the gaps and place the store on the route table above.
02
Checkout and migration plan
Payment integration, target SAQ, data to move and the redirect map are agreed.
03
Fixed-scope first release
The new store with checkout, migrated catalog and redirects, tested on staging.
04
Cutover
Final data sync, DNS switch, redirect checks and crawl monitoring.
05
Support
Store changes, script reviews and platform updates under agreed change control.
Facts and sources
PCI DSS and web standards behind checkout
Short facts we design checkout around, each linked to its primary source.
To use PCI DSS SAQ A, no single element of an ecommerce payment page can originate from the merchant's website; under SAQ A-EP, each element must come from either the merchant's website or a PCI DSS compliant service provider.
Source: PCI Security Standards Council FAQPCI SSC FAQ 1588 says the SAQ A eligibility criterion on script attacks applies to merchants whose page embeds a provider's payment page or form, such as an iframe, and not to merchants that redirect shoppers to the provider.
Source: PCI SSC FAQ 1588 (February 2025)PCI SSC removed Requirements 6.4.3, 11.6.1 and 12.3.1 from SAQ A in January 2025 but kept them in PCI DSS v4.0.1, where they became effective on 31 March 2025.
Source: PCI SSC blog, 30 January 2025PCI SSC describes PCI DSS Requirements 6.4.3 and 11.6.1 as making sure payment page scripts are properly authorized, checked for integrity and monitored for tampering.
Source: PCI SSC, Coffee with the Council, 26 March 2025The W3C Payment Request API standardizes a browser interface that lets merchants accept one or more payment methods with minimal integration, with the browser facilitating the payment flow.
Source: W3C Payment Request API (Candidate Recommendation Draft, 22 June 2026)
Voice of success
We don't just build products; we forge lasting partnerships. See how we've helped industry leaders transform their vision into technical reality.
“I can clearly see how Agnotic has a unique way of handling end-to-end development. They are always active on quick chat and provide support quickly.”
Aaron Phelan
Founder, Benchmark
“Agnotic combines deep technical expertise with strong domain knowledge. They understand the business context, anticipate challenges, and make collaboration smooth and effective.”
John Pasmore
Founder, Latimer
“Agnotic is the best technical team we evaluated. Their engineering excellence made our work dramatically easier and allowed us to stay focused on what matters most for maternal care outcomes. They took full ownership of the technical execution, and we are always happy to continue working together.”
Kim Smith
Founder, My Lauren
Related pages
Related commerce and payments services
This page covers one store's build. These pages cover what sits around it.
Retail software development
The retail industry hub: storefront, B2B, inventory and pricing software Agnotic builds for retail teams.
Omnichannel ecommerce engine
Enterprise multi-channel commerce, including peak traffic and edge performance.
Payment gateway integration services
Tokenization, 3-D Secure, wallets and reconciliation with your payment provider.
Order management system software
Order routing, split shipments and returns after checkout.
Cloud consulting services
Ecommerce cloud hosting, landing zones and cost control for headless and custom stores.
Retail POS software
Point of sale for brands that sell in stores as well as online.
More in Retail
More Retail Solutions
Explore other production-grade engineering platforms we deliver across retail.
Frequently Asked Questions
The route (hosted, headless or custom), the custom features, the checkout integration, how much data has to move, the systems the store connects to and the design work. We explain these drivers on the scoping call instead of quoting a fixed price.
Stay hosted if the gaps close with configuration or a few apps. Go headless when the storefront experience is what sets the brand apart and the order logic is standard. Custom code is for rules no platform supports.
A redirect to the provider's hosted payment page, or the provider's payment fields embedded in an iframe with the hosting page protected against script attacks. Your acquirer or the card brands confirm which SAQ applies to your store.
The risk is never zero, but it is planned for: every old URL gets a 301 to its new home, sitemaps and structured data are rebuilt and crawl errors are watched after launch. Most traffic loss comes from skipped redirects.
Password hashes move where both platforms support it; otherwise customers get a reset email. Saved cards move between payment providers as tokens through the providers' own migration process, never as card numbers through us.
It depends on scope; we agree a fixed first release on the scoping call.
Yes. Ecommerce for startups usually starts on a hosted platform with a custom theme and a few apps. We set it up so you can go headless later without redoing URLs or data.
Industries