DEV Community: Zelpex

Taking Stablecoins at Checkout While the GENIUS Act Rules Are Written

Andrii B. — Sat, 03 Oct 2026 18:20:50 +0000

A store owner who hears that Washington is writing stablecoin rules may well start with the wrong question: "Will I need a licence to accept them?" Based on the law as passed, almost certainly not. The GENIUS Act is aimed at the companies that issue stablecoins and the companies that sit between those coins and the public. A shop taking payment for its own goods is neither.

The question worth asking is a different one. The Act decides which stablecoins those intermediaries may offer to people in the United States, and when. Your checkout runs through one of those intermediaries. So the law does not regulate you, but it will shape the list of coins you can accept, and the rules that settle that list are being written now.

What the Act regulates, and who it leaves alone

The GENIUS Act became law on 18 July 2025. It does two main things.

It says who may issue a payment stablecoin in the US. Only a "permitted payment stablecoin issuer" may: a subsidiary of an insured bank approved to issue, a federally qualified issuer, or a state-qualified one. State regimes are open only to issuers with under $10 billion outstanding. Permitted issuers must hold reserves of at least one to one in cash, insured deposits, short Treasury bills and similar assets, publish the composition of those reserves every month, have it examined by a registered public accounting firm, and must not pay holders "any form of interest or yield".

It says what intermediaries may offer. The law calls them digital asset service providers: businesses that, for compensation or profit, exchange digital assets for money or for other digital assets, transfer them to third parties, hold them in custody, or take part in financial services related to issuing them. Exchanges, custodians, wallet providers that hold keys for you and crypto payment processors will typically fit that description.

Merchants do not appear in the definition, or anywhere else in the definitions section. A store that takes USDC for a pair of boots, through a processor that converts it, is not exchanging or transferring digital assets for others as a business. The processor is. The exchange behind the conversion is. The line becomes less clear if you start running your own on-chain treasury: paying suppliers in stablecoins, converting for other businesses, holding coins for customers. If your plans go that far, that is a question for a lawyer, not for a blog post.

The two dates that matter

The Act takes effect on the earlier of two dates: 18 months after enactment, or 120 days after the federal regulators issue final implementing rules. Treasury's August 2026 proposal says the effective date is expected to be 18 January 2027.

From the effective date, issuing a payment stablecoin in the US without being a permitted issuer becomes unlawful. From the same day, a service provider may not offer, sell or "otherwise make available" in the US a stablecoin from a foreign issuer unless that issuer has the technical ability to comply with, and will comply with, US lawful orders. The Act defines a lawful order as one that requires an issuer to seize, freeze, burn or block the transfer of its coins.

From 18 July 2028, three years after enactment, the wider rule applies. A service provider may not offer or sell a payment stablecoin to a person in the United States unless it was issued by a permitted issuer, or by a foreign issuer from a country whose regime Treasury has found comparable and that is registered with the OCC. Knowingly taking part in unlawful issuance carries fines of up to $1 million per violation and up to five years in prison.

So January 2027 is when issuers need to be inside the system. July 2028 is when the providers your customers pay through must stop offering the coins that are not.

What Treasury's August 2026 proposal adds

On 17 August 2026 Treasury published a proposed rule on section 3 of the Act, the part about issuing, offering and selling. It was printed in the Federal Register on 18 August, and comments close on 19 October 2026. It sits alongside earlier proposals from the OCC in February, on how the issuers it supervises are licensed and run, and from FinCEN and OFAC in April, on issuers' anti-money-laundering and sanctions programmes.

For a merchant, three parts of the August proposal are worth knowing.

"In the United States" is about where the customer is. An individual counts as located in the US if physically present there, unless they are a non-resident only passing through. For a business it is where it is organised or has its principal place of business. A European store selling to American customers therefore sits inside the rule's reach through its provider, even though the store itself is outside it.

"Offer" is read broadly. The proposal's examples include advertising a stablecoin as available to people in the US and even replying to an unsolicited enquiry from someone in the US by saying you are willing to sell. Providers will take this seriously, and conservative supported-coin lists are the likely result.

Merchant acceptance is on Treasury's radar. When the proposal describes activity that creates demand in the US for a foreign-issued stablecoin, it lists "merchant-enablement activity in the United States" and U.S.-facing wallet and platform integrations. It then asks commenters whether "facilitating U.S. merchant acceptance" should count as directed selling. That question is about issuers and providers, not shops, but it tells you where Treasury thinks the pressure point is: the checkout button.

None of this is final. The proposal asks 87 questions, including whether to grant temporary safe harbours after July 2028, and the answers could move.

What changes for your choice of coin and provider

The practical effect lands on the coin list, not on your business licence. Today a crypto payment processor may accept a long list of stablecoins across many chains. By July 2028, for customers in the US, that list has to shrink to coins from permitted issuers and from foreign issuers in regimes Treasury has approved. Coins that do not qualify will be dropped for US customers, and a store that built its checkout, pricing or treasury around one of them will have to change.

Two consequences are easy to miss.

A regulated stablecoin can be frozen. Permitted issuers must be able to block, freeze and reject transactions that break the law, and foreign issuers must be able to act on US lawful orders. That is part of what makes a coin acceptable under the Act. It also means a payment you received is not beyond reach the way cash in a till is. If you hold stablecoins rather than converting them, your provider's and your issuer's freeze policies are part of your risk.

Holding a regulated stablecoin earns nothing from the issuer. The ban on interest and yield applies to issuers. If a coin was attractive to your finance team because it paid a return, check where that return actually comes from once the Act is in force.

Our position: treat the coin as configuration, not as architecture. Whatever you accept today, build so that adding or dropping a coin or a chain is a settings change and a test run, not a rewrite. Stores that hard-code one contract address into pricing, refunds and accounting are the ones that will pay for 2028.

What to ask your payment provider

Before you build on one coin, get written answers to these:

Which issuer stands behind each coin you support, and what is its status under the GENIUS Act? Permitted issuer, application pending, or foreign issuer relying on a comparability finding from Treasury.
Which of your entities is the digital asset service provider for my payments, and where is it licensed? You want to know who carries the obligation, not only which brand is on the invoice.
What happens to a coin that does not qualify by 18 July 2028? How much notice you will get, whether it is removed for US customers only or everywhere, and what happens to any balance you hold in it.
How do you decide whether a customer is located in the US? This matters most if you sell across borders.
What is your freeze and hold policy? Who can freeze funds on their way to you or in your balance, and how you would be told.
If you hold coins for me, how are they held? The Act gives customers priority over the provider's other creditors for stablecoins held on their behalf. Ask whether yours are segregated and how that is documented.

If your provider cannot answer the first question clearly, that is the answer. Keep your volume on it low until it can.

What to watch between now and 2028

Final rules. Comments on Treasury's proposal close on 19 October 2026. When the regulators publish final rules, the 120-day clock starts, and the effective date can come earlier than 18 January 2027.

Comparability decisions. Foreign-issued coins can stay available to US customers after July 2028 only if Treasury finds their home regime comparable and the issuer registers with the OCC. Until a coin's home regime has that finding, treat its US future as uncertain.

Your provider's coin list. Watch for supported-coin changes and restrictions by customer location. They will be the first sign of the rules reaching your checkout.

The store that comes through this well is the one that accepts a small number of coins from issuers with a clear path under the Act, settles most of them into its own currency, and can switch a coin off in an afternoon. That is the design we would build towards in our blockchain e-commerce and blockchain payment integration work, whichever coin a client starts with.

If you would rather work through your coin list and provider contract against the dates above, talk to us.

Dates and rules checked against Public Law 119-27, 12 U.S.C. 5901–5903, Treasury's August 2026 proposed rule and the Treasury and OCC announcements in September 2026. This is a summary for planning, not legal advice.

Originally published at zelpex.com.

Taking Over a Shopify Store: What Our First Audit Looks For

Andrii B. — Mon, 28 Sep 2026 18:54:19 +0000

Shopify's own help centre says it plainly: "Some apps add code to your online store theme that isn't automatically removed when you uninstall the app." On a store that has been through two agencies and a dozen app trials, that one sentence explains a good part of what an audit turns up.

So when a merchant asks us to take on a store someone else built, we do not start with the feature list. We start with an audit of what the storefront is actually running and where each piece came from. It is useful even if the merchant decides not to work with us afterwards, and it usually changes what the first piece of paid work should be.

Three kinds of code, and why the split matters

Everything a Shopify storefront loads comes from one of three places, and each one gets removed differently.

Theme code. Liquid, JavaScript and CSS in the theme files: layouts, sections, snippets, assets. It belongs to whoever edits the theme, and it stays until someone deletes it.

App-injected code. Modern apps ship as theme app extensions: app blocks and app embeds whose assets live on Shopify's side, not in your theme files. Shopify's documentation is explicit that "when merchants uninstall apps, blocks associated with the apps are automatically and entirely removed from online store themes." Older apps did it differently. Some registered a script tag through the Admin API, which Shopify injects into every storefront page without touching the theme. Others, or their install guides, pasted snippets straight into theme.liquid.

Orphaned leftovers. This is what the help centre sentence is about. When an app is uninstalled it loses access to the store at once, so it cannot clean up after itself. A snippet it pasted into the theme keeps rendering, and if it still calls the app's servers, it keeps making requests that nobody is reading the responses to.

The split matters because the fix is different for each. Theme code gets reviewed. An app embed gets switched off in the theme editor. A leftover gets deleted, but only once you have proved it is a leftover.

Step one: compare what the theme references with what the page loads

The first pass is two lists and a diff. The first list is what the theme files ask for: pull the live theme with Shopify CLI, commit it untouched, and collect every external script it references.

shopify theme pull --live --path ./live-theme --store your-store.myshopify.com
cd live-theme && git init && git add -A && git commit -m "Live theme as found"
grep -rhoE 'src="https?://[^"/]+' layout sections snippets templates \
  | sort | uniq -c | sort -rn

The second list is what a real page load actually fetches. On the live storefront, with the cookie banner accepted the way a customer would, the browser's Resource Timing API gives it to you in a few lines:

const hosts = performance.getEntriesByType("resource")
  .filter((e) => e.initiatorType === "script")
  .map((e) => new URL(e.name).host);
console.table(hosts.reduce((acc, h) => ({ ...acc, [h]: (acc[h] || 0) + 1 }), {}));

Run it on the home page, a collection, a product and the cart, because apps scope themselves differently. Every host in the second list but not the first came from outside the theme files: an app embed or a script tag. Every host in the first list with no installed app behind it is a candidate leftover. Theme Check (shopify theme check) is worth running on the same pull for a quick read on the Liquid quality you are inheriting.

Step two: tie every script to an app, a person or nobody

Now the lists get owners. For each host we want one of three answers: an installed app that uses it, a person on the merchant's team who asked for it (an analytics tag, a chat widget), or nobody.

The installed apps list in the admin is the starting point, and the App embeds panel in the theme editor shows which embeds are switched on. Snippets named after an app that no longer appears in the admin are the classic leftover, usually rendered from theme.liquid so they run on every page. Search the pulled theme for the app's name and its script host, and read the app developer's uninstall instructions where they exist, because the developer knows where their code went better than anyone.

While the apps list is open, check billing too. Shopify notes that uninstalling an app does not cancel charges an app bills outside Shopify, so a store can still be paying for something it removed a year ago.

Nothing should be deleted at this stage. Removal belongs on a duplicate theme, one leftover at a time, once every script has an answer.

Why the slow store is often carrying scripts nobody uses

App scripts rarely know which page they are needed on. A review widget that matters on product pages loads on the home page, the blog and the cart as well. Add three or four apps nobody uses any more, each with its own script and its own third-party requests, and the store is slower on every page for features that do not exist.

Shopify's web performance report is the honest place to see this, because it uses real visitor data for loading speed, interactivity and visual stability, split by desktop and mobile. It also marks events such as app installs and theme updates as numbered lines on the graph, so you can often line up the week the store got slower with the app that arrived that week. For server-side Liquid cost, shopify theme profile profiles the rendering of a given page.

This is also why we are sceptical of a speed app as the first fix. An app that optimises scripts is one more script. Removing four that do nothing is usually the larger and cheaper win.

Two deadlines that make the audit urgent now

Two Shopify changes turn leftover scripts from untidy into broken.

Script tags are being switched off. Shopify's developer changelog says that from 1 October 2026 the scriptTagCreate and scriptTagUpdate mutations return an error, and on 1 March 2027 Shopify will stop injecting script tags into storefronts at all. Any app on the store that still depends on a script tag has until then to move to an app embed, or to a web pixel if it only tracks analytics. The audit tells you which of your apps that is, so you can ask the vendor now instead of finding a missing feature in March.

The Order status page has already changed. Script tags stopped running on the Order status page on 28 August 2025 for Plus stores and on 26 August 2026 for every other plan. On an inherited store, the conversion tracking someone pasted into that page years ago may have gone quiet with no error anywhere. If the marketing team's purchase numbers dropped in late August, check this before you check the ad accounts.

Step three: put the theme in Git before anyone changes it

The last step is the one that makes every later change safe, and it comes before any cleanup. On an inherited store the theme has usually been edited directly in the admin code editor, by several people, with no record of who changed what. A bad deploy on a store like that is an archaeology exercise.

Shopify's GitHub integration fixes most of this. It connects a theme to a branch, pulls every commit on that branch into the theme, and commits changes made through the admin back to the branch, batching edits made within about ten seconds into one commit. Shopify's own version control guidance recommends connecting your main branch and publishing that theme, and using other branches for campaigns and temporary customisations.

The order matters. The live theme goes in exactly as found, ugly parts included, as the first commit. Cleanups follow as separate commits on a branch, reviewed and merged. Merchandisers keep using the theme editor as before, and their changes land in the repository as commits too, so nothing they do gets overwritten by a deploy. From then on, a bad change is one revert.

What the audit answers

By the end, every script the storefront loads has an answer to three questions: is it theme code, is it injected by an app, or is it left over from an app uninstalled long ago. Add to that the apps still on a script tag, with 1 March 2027 next to them, and any tracking that relied on the old Order status page, and you have the list the first round of work should come from.

We run that first audit at a fixed price, in one of two sizes. The standard audit looks at the site as a whole and needs no access. The larger one, which we call Max, needs access to the Shopify account and goes through everything: the theme pull, the apps list and the billing check described above, plus the integrations connected to the store. Either takes from 24 hours to two days of work. What you get is a list: the infrastructure and UI/UX problems we found, each marked critical, medium or low priority. If you came with a specific goal, it is instead the fixed set of fixes that stands between the store and that goal.

The theme ends up where our Shopify work always happens: in version control with review, in the merchant's own repository where possible, not edited directly in the admin. Building features on a theme nobody fully understands is how the next team inherits the same mess, which is why the audit comes first.

If you have inherited a store and would rather know what it is running before you change it, talk to us.

Shopify behaviour and dates checked against Shopify's help centre on uninstalling apps, theme app extensions UX guidance, the script tag deprecation changelog, the Order status page script tag timeline, the web performance reports and the GitHub integration for themes in September 2026. How we take over a store is described on our Shopify development page.

Originally published at zelpex.com.

What a Store Project Really Costs: The Problems Drive It, Not the Platform

Andrii B. — Thu, 24 Sep 2026 22:27:00 +0000

A common first question from store owners is what a project costs on Shopify compared with Adobe Commerce. It is a reasonable question with a disappointing answer: the platform is rarely what decides the bill. We compared the licences in what Adobe Commerce, Shopify and BigCommerce actually cost, and even there the licence was usually the smallest number in the total.

What decides the bill is the set of problems the store already has, most of which sit outside the storefront. That is why we won't quote a figure on the first call, and why the quote we do write is split into phases, each with its assumptions written down.

Why a price list can't answer the question

Two stores on the same platform, with the same number of products, can need very different projects. One keeps its stock in Shopify and ships from one warehouse. The other has stock mastered in an ERP, a courier with its own API, a finance team that needs every invoice to match, and a marketplace feed with its own format. The storefront work is similar. Everything around it isn't.

So our honest answer to "what does it cost" is the shape rather than a number: an integration or a focused piece of work is usually measured in weeks, a platform build in months. What moves a project from one end of that range to the other is what the rest of this piece is about.

For a sense of scale: a first integration phase usually lands between 1 and 3 weeks.

The problems that actually move the number

Two systems that both think they own the truth. Most integration bugs are not code failures. They are two systems both believing they own the price, or the stock level, or the customer record. Until someone decides which system is the record for each field, every connector built on top inherits the argument. Deciding it costs a workshop. Not deciding it costs a campaign weekend of oversold products.

Stock that lives somewhere else. If inventory is mastered in an ERP or a warehouse system, the store only knows what the last sync told it. Whether that sync needs to be near real time or can run nightly is a business decision, and it is worth making per data type: stock usually needs to be fresh because being wrong means an oversell, while financial postings are often fine overnight. Making everything real time "to be safe" is one of the quietest ways to inflate a budget.

Product data nobody has cleaned. Catalogues accumulate attributes in the wrong places: sizes in tags, materials in titles, variants split into separate products. Every migration, search project or AI channel has to deal with it. It also costs sales directly: Baymard's usability research found that 10% of the largest e-commerce sites don't keep a consistently high level of detail in their product descriptions, and test users abandoned products when they couldn't find what they needed. Cleaning data is unglamorous work that no platform does for you.

Business rules that don't fit a cart. Rentals with availability windows, marketplaces with per-vendor payouts, configurators where the price depends on a dozen inputs. These bend a platform until the workarounds cost more than building the part that is genuinely yours. The test we use is simple: list the five things a platform would force you to work around. If they are cosmetic or only affect the admin, stay on the platform. If they touch how money is calculated, how inventory behaves over time or who is party to a transaction, it is time to look at custom.

Integrations someone else built. Fixing those is a good share of what we do. We start by instrumenting the connector to find where records actually go missing, which is frequently somewhere other than where the team suspects, and the fix is sometimes small. Sometimes the honest answer is that a rewrite is cheaper than another patch. Either way, you can't price it before you look.

One example from our own work: a client came to us for a redesign. Discovery showed that half their product attributes lived in tags and titles, and cleaning the catalogue took longer than the theme work, close to two months.

How we turn problems into a quote

Discovery first, when it isn't obvious. A short discovery maps the systems, the constraints and what is genuinely in the way, and ends with a written recommendation. Sometimes that recommendation is that you don't need a build at all, which is a cheaper answer than finding out six months in.

Phases, with the assumptions written down. We quote per phase so you can see what moves the number before you commit to the whole thing. If an assumption turns out to be wrong, it is visible which part of the price it affects.

Fixed price where the scope is precise. A migration, a connector or a defined feature set can be fixed-priced. Ongoing product work is better on a monthly team, because pretending an evolving roadmap can be fixed-priced usually ends in an argument about what was in scope.

Start with something small. A first phase that ships something real tells you more about working with us than any reference call, and it tells us more about your systems than any discovery document.

What makes the same project cheaper

A few decisions reliably take cost out before any code is written:

Pick one system of record per field and write it down.
Decide batch or real time per flow, not globally.
Build the risky part first. Whatever is most likely to be wrong, the pricing engine, the availability calendar, the payout maths, gets built and tested against real data early.
Look for the platform-shaped answer before the custom one. If Shopify, BigCommerce, Adobe Commerce or Medusa can carry the model with reasonable extension, that is the cheaper project.

What to bring to the first call

You don't need a specification. These five things are enough to turn a conversation into an estimate:

The list of systems around the store: ERP, warehouse, PIM, couriers, marketplaces, finance.
Which system is the truth for stock and price today, even if the answer is "it depends".
Three things that currently go wrong, in the words the operations team uses.
The rules that make your business unusual: how price is derived, how availability works, who gets paid what.
What a good first phase would change for you, in one sentence.

If you would rather work through your own list with us, talk to us.

Product data figures from Baymard Institute's research on product descriptions. Zelpex's approach as described on our custom e-commerce and integration pages and in our FAQ.

Originally published at zelpex.com.

UCP, Storefront MCP and Your Catalog: Getting a Shopify Store Agent-Ready

Andrii B. — Thu, 24 Sep 2026 09:47:49 +0000

In April 2026, developers on Shopify's community forum started reporting that their shopping assistants had stopped finding products. Calls to search_shop_catalog, the Storefront MCP tool for searching a store's products, began returning Tool not found. It had been replaced by search_catalog, on a different endpoint, with a new input schema.

That is a small incident and a useful one. The layer AI agents use to shop on Shopify is still moving, and getting a store agent-ready isn't a setting you flip. It means knowing which of three layers you depend on, and which parts of your own catalogue decide whether an agent can sell anything at all.

Three layers, one catalogue

Shopify Catalog is the syndication layer. Eligible products are made discoverable to AI channels, which Shopify currently lists as ChatGPT, Google AI Mode and Gemini, Microsoft Copilot and Meta, with their title, description, options, images, price and availability. Shopify says it keeps inventory and pricing updated continuously across those channels. For most merchants this is the whole integration: nothing to build, but nothing to tune either, except the data you feed it.

Storefront MCP is the per-store interface. A Shopify store exposes an MCP server that an agent can call directly, without authentication, using JSON-RPC 2.0 over HTTP POST. This is what a custom assistant, or any agent that talks to your store rather than to a marketplace, actually uses.

The Universal Commerce Protocol (UCP) is the contract underneath. Shopify and Google co-developed it as an open standard for how agents discover products, negotiate what a merchant supports and run checkout. Merchants and agents publish profiles at /.well-known/ucp, each side declares its capabilities, and the session runs on the intersection. Checkout, orders and catalogue are separate capabilities, each versioned on its own.

The practical point for a technical lead: the first layer is Shopify's job, the second and third are contracts you may be coding against, and contracts at this stage change.

What an agent actually calls

Storefront MCP is now split across two endpoints on your store's domain:

https://{shop}.myshopify.com/api/ucp/mcp carries the UCP catalogue tools: search_catalog, lookup_catalog (up to 10 ids per call) and get_product.
https://{shop}.myshopify.com/api/mcp carries the rest: search_shop_policies_and_faqs, get_cart and update_cart.

The UCP tools expect an agent profile in every request and wrap their arguments in a catalog object. This is the shape from Shopify's documentation:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "id": 1,
  "params": {
    "name": "search_catalog",
    "arguments": {
      "meta": {
        "ucp-agent": {
          "profile": "https://shopify.dev/ucp/agent-profiles/examples/2026-08-25/valid-with-capabilities.json"
        }
      },
      "catalog": {
        "query": "organic coffee beans",
        "context": { "address_country": "US", "intent": "Customer prefers fair trade products" }
      }
    }
  }
}

If you wrote an agent against the older flat search_shop_catalog call, the April change is exactly what broke it. The fix is small; the lesson is to treat the tool list as something you discover at runtime (tools/list is part of MCP), pin behaviour behind your own adapter, and alert on Tool not found rather than on empty results.

Checkout is a state machine, not a redirect

UCP models checkout as a session that moves through states, including incomplete, requires_escalation and ready_for_complete. When the merchant needs something only a person can provide, the session escalates and returns a continue_url; the buyer follows it and, in Shopify's words, "picks up exactly where the agent left off" in an embedded checkout.

That changes what you test. The question is not whether an agent can reach your checkout, but which of your checkout rules push a session into escalation: custom validation, required fields your storefront adds, logic that lives in a theme rather than in the platform. Every escalation is a hand-off from a conversation to a web page, and some buyers won't make it across. Walk your real checkout through the agent path and list what escalates before you promise anyone "buy inside ChatGPT".

The catalogue work that decides whether agents can sell

Most of the effort sits here, and none of it is new code.

Eligibility. Shopify Catalog only includes products with a title, at least one image and a price above zero, published to the online store, Hydrogen or a headless channel. Agentic storefronts also need an external product URL for each product, stored in the external URL standard metafield. A product that fails any of these is invisible to agents, however good it is.

Structure. Shopify's own guidance is to group genuine variants under one parent, so an agent understands one product with options rather than twelve near-duplicates, and to use the most specific category available: "men's insulated winter boots", not "footwear". It also asks for literal descriptions. Marketing copy that works on a landing page gives a language model very little to match against.

Data that lives in the wrong place. Plenty of mature stores keep real attributes in tag prefixes, metafields, metaobjects or split titles. Shopify Catalog Mapping exists for exactly this: it points the catalogue at where your data actually lives. If your size, material or compatibility data is in a tag like size:42, map it before assuming agents can see it.

B2B separation. Agentic storefronts are for direct-to-consumer sales. Shopify excludes B2B-only products it can identify through B2B catalogues, customer account requirements or password-protected storefronts, but a custom B2B implementation may need products hidden by hand, by setting them to Unlisted. A store that mixes trade and retail pricing through its own logic should check what agents are actually offered.

Stock you can promise. Shopify's line is that price and inventory "need to be accurate at the moment of the shopper's query". If stock is mastered in an ERP or WMS and synced to Shopify on a schedule, the agent sells from the last sync. On a busy day that is the difference between an order and a cancellation, and an agent-driven cancellation is a worse experience than a normal one, because the buyer never saw your store.

A readiness pass, in order

Run an eligibility report over the catalogue: no image, zero price, missing external URL, unpublished to the right channel. Fix these first; they are binary.
Map your data. List every attribute that lives in tags or metafields and set up Catalog Mapping for it.
Collapse false variants into single products with options, and tighten categories.
Decide what agents must not sell, especially trade-only items, and set them to Unlisted if Shopify can't detect them.
Measure your stock lag. How long between a change in the system that owns inventory and the same change in Shopify? If the answer is minutes, fix the sync before you invite agents in.
Walk checkout through the agent path and list every rule that escalates.
If you run your own agent, wrap the MCP calls behind an adapter, discover tools at runtime and alert on renamed or missing tools.

Shopify reports that AI-referred orders grew nearly 13x year over year. An agent buying on a shopper's behalf never sees your theme. What it sees is your catalogue data, so that is where the work goes.

If you would rather go through this against your own catalogue and integrations, talk to us.

Verified against Shopify's Storefront MCP documentation, the Shopify Engineering post on UCP, the Help Center pages on agentic storefronts and catalogue product discovery, Shopify's guide to agentic-ready product data, and the community thread on the tool rename, in September 2026.

Originally published at zelpex.com.

Magento 2.4.6 Lost Support in August: What Waiting Actually Costs

Andrii B. — Wed, 23 Sep 2026 18:19:09 +0000

If your store runs Magento 2.4.6, it stopped receiving security patches on 11 August 2026. The one exception is Adobe Commerce, the paid edition, which gets one more year. Magento Open Source, the free edition, does not.

So the decision in front of you is about exposure, not features: how long you are willing to run a checkout that nobody will fix when the next hole is found, and what it costs to stop.

Who is out of support, and until when

Adobe gives every 2.4 release three years of standard support, then stops shipping patches for it. For 2.4.6 and 2.4.7 it adds one extra year, but its lifecycle policy grants that year to "Adobe Commerce customers" only.

Version	Standard support ended / ends	Adobe Commerce only, extended to
2.4.6	11 August 2026	31 August 2027
2.4.7	31 May 2027	31 May 2028
2.4.8	31 May 2028	–
2.4.9	31 May 2029	–

There is a second clock under the first, and it catches Adobe Commerce customers too. Magento 2.4.6 runs on PHP 8.1 or 8.2. PHP 8.1 stopped receiving security fixes on 25 November 2025, and PHP 8.2 stops on 31 December 2026. So even a licence holder using the extra year will spend most of it on a language version that no longer gets security fixes of its own. The extension buys time to plan the upgrade. It is not a place to stay.

What waiting has cost other stores

The usual argument for waiting is that nothing has gone wrong yet. The last two years of Magento security history say otherwise.

In June 2024 Adobe patched CosmicSting (CVE-2024-34102), a flaw that let attackers read files on the server, including the store's secret encryption key. Sansec, which monitors Magento stores, reported that by that autumn 5% of all Adobe Commerce and Magento stores had a payment skimmer on their checkout page: 4,275 stores, attacked by seven competing groups. Some of them had installed the patch. Patching did not invalidate keys that had already been stolen, so stores that skipped rotating the key stayed open.

In September 2025 Adobe shipped an emergency fix for SessionReaper (CVE-2025-54236), a critical flaw that could lead to remote code execution. Six weeks later, when attacks began, Sansec found 62% of Magento stores still unpatched.

Two things follow for a store deciding what to do about 2.4.6. The gap between a fix and mass exploitation is measured in weeks, not years. And on an unsupported version there is no fix to install when the next one arrives: you are in the 62% by default, with no way out except the upgrade you postponed.

The compliance side

If you take card payments, PCI DSS requirement 6.3.3 expects critical security patches to be installed within 30 days of release. Version 4.0.1 of the standard narrowed that to critical vulnerabilities only, but kept the deadline.

A store on an unsupported version cannot meet that requirement the ordinary way, because no patch will be released. That doesn't make you non-compliant overnight, and it isn't legal advice. It does mean that at your next assessment you will need to explain which compensating controls you rely on instead, and that conversation gets harder every month the version stays in place.

What the upgrade actually involves

The upgrade itself is rarely the expensive part. What makes it expensive is everything around the Magento code.

The infrastructure moves first. Magento 2.4.8 runs on PHP 8.3 or 8.4, and 2.4.9 only on PHP 8.5 with OpenSearch 3, so the hosting stack has to change along with the application. Then come extensions and integrations: Adobe's own guidance notes that Marketplace extensions and third-party integrations may be affected, and each one has to be checked, updated or replaced. A store with a handful of well-maintained extensions and a stock theme is a very different project from one with years of custom modules and a hand-built ERP sync.

That is also why the cost of waiting compounds. Adobe says plainly that regular updates take less overall effort than infrequent ones. A store that moves every release does a small upgrade each time. A store that skips two or three does all of them at once, under pressure, usually after something has already gone wrong.

Our view on the target: go to the newest release your extensions support. If everything you rely on runs on 2.4.9, that buys support until May 2029. If a critical extension isn't ready, 2.4.8 is a sound stop until May 2028, and the next step from there is smaller.

The options, honestly

Upgrade on Magento. For most stores this is the answer. It keeps your catalogue, customers, order history and integrations where they are.

Move to Mage-OS. Mage-OS is a community-maintained distribution of Magento Open Source that ships its own releases and security patches, with the aim of patching faster. It is currently based on Magento 2.4.9, so switching is itself an upgrade, not a way to stay on 2.4.6. It is worth considering if you would rather not depend on Adobe's release schedule for the free edition.

Replatform. If the upgrade estimate comes back close to the cost of moving, it is fair to ask whether Magento is still the right platform. That is a bigger decision with its own hidden costs; we compared the platforms in what Adobe Commerce, Shopify and BigCommerce actually cost.

Do nothing. A web application firewall and closer monitoring reduce risk while you plan. They buy time. They don't replace patches, and they don't help with the PHP version underneath.

Before you get an estimate

Four questions decide how big this job is:

Which edition are you on? Adobe Commerce gives you until 31 August 2027. Open Source gave you until 11 August 2026.
Which PHP version does the server run? If it is 8.1, the language itself is already out of security support.
How many extensions and custom modules does the store use, and who maintains them? This list drives the estimate more than anything else.
What sits around the store? ERP, PIM, payment and shipping integrations each need testing against the new version.

If you would rather work through this against your own store's extension list and integrations, talk to us.

Support dates verified against Adobe's software lifecycle policy and system requirements, and PHP dates against php.net, in September 2026. Incident figures from Sansec's reports on CosmicSting and SessionReaper; PCI DSS changes from the PCI Security Standards Council.

Originally published at zelpex.com.

When a Manufacturer's CRM Should Be Built, Not Bought

Andrii B. — Wed, 23 Sep 2026 17:50:28 +0000

Most manufacturers who ask whether they should build their own CRM are asking about the wrong piece of software. The part their sales team uses every day is close to a commodity, and buying it is usually right. The part their dealers, distributors and service technicians touch is where the business is genuinely different, and it is also where the licence bill grows fastest.

So the useful question is narrower: which part of the CRM should you build, and which part would you be foolish to build?

Why manufacturing sales breaks generic CRM

A CRM is designed around a contact, a deal and a pipeline. Manufacturing sales rarely looks like that. The customer is a distributor with negotiated contract pricing. The order is a spare part identified by a code that was superseded two revisions ago. The delivery date depends on a production slot the ERP knows about and the CRM does not. And the person asking is often a technician on a plant floor, not a buyer in an office.

None of that data belongs to the CRM. Price, availability and lead time live in the ERP, and they have to stay there. Every CRM project for a manufacturer therefore turns into the same work: showing people outside the ERP an honest answer from inside it, without exposing how complicated it is to produce. That is true whether you buy the CRM or build it, and it is the part of the budget people tend to underestimate.

What buying actually costs

The vendors built for this are not cheap, and they price per person. Salesforce's industry product for manufacturers, Manufacturing Cloud, lists at $275 per user per month for its Sales or Service "Core" editions, $425 for the Advanced edition, and $650 to $700 for the "Max" editions that bundle its AI agents, all on annual contracts. HubSpot's Sales Hub is the lighter alternative at $90 per seat per month on Professional (billed annually) and $150 on Enterprise, plus a mandatory one-off onboarding fee of $1,500 or $3,500.

Seats for your own staff are only half the bill. The other half is everyone outside the company who needs to log in.

Salesforce prices its partner portal, Partner Relationship Management, at $25 per member per month, with a more capable tier at $50 and login-based pricing available for users who rarely sign in. Run the list prices for a hypothetical mid-size manufacturer: 15 internal users on Manufacturing Cloud Sales Core and 300 dealer accounts on the partner portal.

Line	Calculation	Per year, list price
Internal users	15 × $275 × 12	$49,500
Dealer portal members	300 × $25 × 12	$90,000
Total licences		$139,500

The dealers cost almost twice as much as the sales team, before a single integration is built. List prices get discounted and login-based licences cut the portal line for dealers who sign in rarely, so treat the table as the shape of the bill rather than a quote. The shape is the point: in manufacturing, the external audience is usually larger than the internal one, and per-member pricing scales with it every year.

The quoting trap

Quoting is usually where a packaged CRM starts to fit badly. Prices come from rules, not a table: the customer's contract, the volume, the configuration, which options are compatible with which, and what the ERP says a variant actually costs to make.

The standard answer used to be Salesforce CPQ, and it is no longer sold to new customers. Existing customers keep it, with support and renewals but no new features, while new buyers are pointed at its successor, Revenue Cloud Advanced. Salesforce is careful to call this end of sale, not end of life. For a manufacturer choosing today, though, it means the configure-price-quote layer most comparison articles describe is not the one you would be buying, and a quoting project is a separate licence and a separate implementation on top of the CRM.

This is the first place building starts to make sense. If your pricing logic is yours alone, encoding it in a quoting tool you own is often cheaper and clearer than bending a generic rules engine around it.

Where building earns its place

We would split the system in three and treat each part differently.

The internal CRM: buy it. Accounts, pipeline, activity history, service cases, reporting. This is well-solved software. Building it means rebuilding permissions, audit trails, email sync and mobile access that a vendor already maintains, and your team would be maintaining them for ever.

The ERP: leave it alone. It is the system of record for price, stock and lead time. Neither the CRM nor anything you build should hold a second copy of those numbers that can drift.

The dealer portal and quoting rules: build them when they are where you compete. This is the software your customers actually use. It carries your contract pricing, your supersession chains for spare parts, your serial-number history for service, and your availability promises. A custom portal is priced once to build and then maintained, not charged per dealer per month, and it can read the ERP directly instead of through a CRM in the middle.

The split is not free. A custom portal needs an owner, a hosting bill, security updates and someone who understands it when the person who built it has moved on. If you have no one to own software, the per-member licence is the price of not needing them, and it can be worth paying.

The test

Before deciding, answer four questions honestly.

How many people outside the company need to log in? If it is a handful, a vendor portal is fine. If it is hundreds of dealers or technicians, price the per-member line over five years before anything else.
Is your pricing a table or a set of rules? A price list fits any CRM. Contract pricing, configuration rules and ERP-derived costs are where packaged quoting gets expensive and awkward.
Where does the true answer on availability live? If it is the ERP, whatever customers see has to read from it, and that integration is the real project either way.
Who will own the software in three years? Building only works if the answer is a named person or a partner, not "IT".

If the answers are "few", "a table", "the ERP" and "nobody", buy the whole thing and keep the configuration shallow. If they are "hundreds", "rules", "the ERP" and "we can", buy the CRM, build the portal, and let the ERP stay the source of truth.

If you would rather work this through against your own dealer network and pricing rules, talk to us.

Prices verified against Salesforce Manufacturing Cloud, Salesforce Partner Relationship Management and HubSpot Sales Hub pricing pages, and Salesforce's CPQ end-of-sale page, in September 2026. All figures are list prices in US dollars.

Originally published at zelpex.com.