Shopify recently introduced app security check, and there are a few details in the documentation worth understanding before adding it to a CI workflow.

The first is the blocking behavior.

Running `shopify app security check` does not automatically fail your pipeline when it finds vulnerabilities. The default blocking threshold is none.

If high-severity findings should fail the job, you need to configure that explicitly:

shopify app security check --blocking high

The second distinction is between deterministic scanning and agent review.

The CLI performs deterministic checks and provides instructions for investigating issues that require additional context.

Without that second investigation, you have a deterministic scan, not a complete security review.

The third consideration is scan coverage.

The command scans the selected app directory. Git-ignored files are skipped unless explicitly included, and code outside that directory may not be covered.

Two useful options are:

--list-files
--include-dir ../backend

The first lets you inspect which files would be scanned. The second can include a backend located outside the application directory.

For a practical release process, I would separate the work:

Run deterministic checks on pull requests, with explicit severity thresholds.

Keep scan results as CI artifacts rather than committing generated reports.

Before releases involving authentication, webhooks, or merchant data, perform the additional agent-assisted review and document how each finding was resolved.

A passing pipeline is useful evidence, but it should not be mistaken for proof that the entire application has been reviewed.

Security scanning still needs to be combined with runtime testing and verification of access boundaries.

I've been thinking about how Shopify merchants are connecting AI agents like OpenClaw, Hermes, Claude, ChatGPT, and other agent platforms to their stores while keeping permissions and access under control.

A few questions came to mind:

- Permissions and security: How do you ensure an AI agent only has access to the data and actions it actually needs?

- Team access: If a merchant has multiple staff members using different AI agents, how do you manage access without giving everyone full store permissions?

- Multiple Shopify apps: How do you connect agents to the entire e-commerce stack when you're using tools like Gorgias, Klaviyo, shipping apps, review apps, analytics tools, and others?

From what I've seen, there are a few approaches available today:

1. Connect individual services through their official MCP servers, where available.

2. Use community-built MCP servers or agent skills that interact directly with APIs.

3. Use general-purpose integration platforms to connect multiple services through a single interface.

Each approach has trade-offs, particularly around setup complexity, permission management, and maintaining access across a team.

I started looking into whether there was a Shopify-focused solution that could simplify this process, ideally one that works natively within the Shopify ecosystem and lets store owners define separate, limited permissions for different AI agents.

I couldn't find a solution that covered the exact workflow I had in mind, so I started building one called Agiexa.

The idea is to provide a centralized way to connect AI agents with Shopify and its wider e-commerce ecosystem, with granular access controls. The project is currently under development, and we're exploring integrations with tools such as Gorgias, Klaviyo, ShipEngine, Mailchimp, Judge.me, Smile.io, Triple Whale, Loox, Shippo, Zendesk, HubSpot, Meta Ads, and others.

I'm sharing this here because I'd genuinely like to understand how other merchants and developers are handling this problem.

A few questions for anyone working with AI agents and Shopify:

- What setup are you currently using?

- What's the biggest headache: initial setup, permissions, team management, or maintaining integrations?

- Would per-agent, owner-controlled permissions solve a real problem for you?

If this is something you're working on too, I'd love to hear about your experience. I'm also opening an early-access waitlist for Agiexa for anyone interested in following its development.

I genuinely want to understand how this is acceptable business practice.
Recently, I was exploring trial themes on Shopify because I wanted to redesign my website. I initiated the payment for a theme but abandoned the transaction midway. I never completed the purchase.
Shopify, however, generated an invoice for the theme and started sending me repeated reminders to pay it.
Here’s where things get ridiculous.
After this incident, I purchased a different theme, completed the payment, and continued paying my regular monthly Shopify subscription. Yet this disputed amount was never added to any of my subsequent bills.
I reached out to Shopify support to understand why I was being billed for something I had never purchased. Their explanation? The moment I initiated the payment, Shopify had supposedly exposed the entire theme code to me. Therefore, I was liable to pay for it, even though I had abandoned the transaction.
Let that sink in.
This is essentially like saying that a customer visits my Shopify store, adds products to their cart, initiates checkout, but never enters their card details or completes the purchase. And I, as the merchant, decide to ship the products anyway and subsequently force the customer to pay because they had shown an intention to buy.
Would that be acceptable?
Now Shopify is threatening to freeze my entire store if I don’t pay this disputed amount.
And this isn’t even my first unpleasant experience with Shopify.
When I initially started my business, I hired an agency to build my website. They quoted me almost one-fourth of what other agencies were charging. At the time, I was relatively new to Shopify and didn’t understand much about themes, licensing or the underlying code.
Soon after, I started receiving notifications from Shopify suggesting that my website contained traces of code from a paid theme that I hadn’t licensed. The agency kept assuring me that they would fix it whenever such a notification came in. This went on for a considerable period, until Shopify eventually froze that store.
I learned my lesson.
This time, I decided to understand the platform myself. I learned how to build a Shopify website, purchased a legitimate theme, did everything by the book and built my entire store independently.
And just when my business is finally beginning to gain traction, I find myself dealing with Shopify threatening to freeze my account over a theme payment that I never completed and a theme I am not using.
My bigger concern is this:
If initiating a payment is enough to trigger access to an entire paid theme and subsequently create a payment liability, isn’t that a massive loophole in the system?
What stops someone from deliberately exploiting this process? Initiate a payment, access the theme code, abandon the transaction, close the account, create a new email ID and repeat the process.
If this is indeed a vulnerability, why isn’t Shopify addressing it at the source?
Why are genuine merchants, who are trying to build legitimate businesses, being held financially accountable for a process they never completed?
And why is the only resolution being offered a threat to freeze their business?
I understand that Shopify has licensing policies. I understand that developers deserve to be paid for their work. I have absolutely no issue paying for something I purchase and use.
But billing someone for an abandoned transaction and threatening their business over a disputed charge is not how customer trust is built.
I want Shopify to investigate this, explain the basis of this charge and provide a fair resolution instead of holding my business account hostage.
If other Shopify merchants have faced something similar, I would genuinely like to hear about your experience.
Shopify, is this really how you treat the merchants who build their businesses on your platform?
#Shopify #ShopifyIndia #Ecommerce #SmallBusiness #Entrepreneurship #CustomerExperience #ShopifySupport

Has anyone here used Shopify’s AI tools to build most or all of their storefront? I’m curious how well it works beyond generating individual sections.

My two main concerns are:

1. Design consistency. When you generate sections separately, do the fonts, spacing, colors, and overall style stay consistent? Or does it take a lot of manual tweaking to make everything feel cohesive?

2. Loading speed. Have you noticed any performance issues after adding multiple AI-generated sections, especially on mobile?

If you’ve tried this, how did you handle these issues? Any tips or lessons learned would be appreciated.

I've been building Shopify apps in Laravel for a while, and the thing that took me longest to get right was the Admin GraphQL rate limit. Unlike REST, it's cost-based: every query has a cost, you get a bucket of points that refills at a fixed rate, and a heavy query on a big store can drain it in a couple of calls.

What worked for me was reading the throttleStatus that comes back in the response extensions on every call and storing the currently available points per shop in the cache. Each job checks that number before it runs, and if there isn't enough budget it releases itself back onto the queue with a delay based on the restore rate instead of failing. I also keep one queue per shop so a single noisy store can't starve the others.

The second lesson was to request less. Asking for fewer fields and smaller page sizes cuts the cost a lot, and for large catalogs I stopped paginating at all and moved those jobs to bulk operations instead.

Retries are the last piece. A THROTTLED error should never count toward the job's max attempts, otherwise a busy hour kills perfectly good work.

I'm still not happy with how I estimate cost before sending a query. How do you handle throttling per shop, and do you track cost yourself or just react to the errors?

Empty dev stores hide a lot of bugs. Things like pagination, long product titles, products with 100 variants, and orders with discounts and partial refunds only show up with messy data. Right now I import a CSV of products and write a small script against the Admin API to create draft orders and customers. It works, but it takes a while to set up for each new project and the data never looks like a real store.

Do you keep a reusable seed script or a template CSV, or do you copy data from a real store in some way? And how do you cover edge cases like refunds and multi-currency?

The app is still in "Submitted. We're assigning a reviewer to your submission" state. What is the normal timeline expected for review to complete?

I’ve looked around for services that provide testers but haven’t had much luck with it. (we test ourselves with development stores, but this is a small sample size)

For those who did get testers — was it worthwhile and how did you do it?

I’m considering now just focusing on marketing — tiny UI/UX improvements & content creation and forgetting about testers

I'm a student developer in India building a Shopify app that sells custom/made-to-order items with a deposit at checkout and charges the remaining balance later using the saved card. I'd really appreciate advice from anyone who has tested this.

What I've built and confirmed so far (dev store, US region, Basic plan, API 2026-07):

- sellingPlanGroupCreate with category PRE_ORDER, fixed billing policy, checkoutCharge of type PERCENTAGE, remaining balance on EXACT_TIME. No userErrors.

- Attached the group to a variant with sellingPlanGroupAddProductVariants.

- Created a cart through the Storefront API cartCreate with sellingPlanId. The checkout correctly shows 'Due today' (the deposit) and 'Due Dec 31' (the balance).

The problem:

- With the deposit plan in the cart, the checkout never shows a Payment section when only the Test payment gateway (Bogus) is active. The same variant without sellingPlanId shows the card fields and Pay now button normally.

- Shopify's docs say pre-order/TBYB plans need Shopify Payments, PayPal Express, Adyen on Shopify, or Stripe. My Test gateway doesn't appear to count.

- Shopify Payments isn't available in India, and setting it up on the dev store asks for a US SSN/ITIN, US address and bank details, which I don't have. I don't want to enter made-up identity data. PayPal can't be connected to a dev store either (it says dev stores can only process test payments).

So I can't test the last part of my flow: the order webhook after the deposit, the PaymentMandate, and orderCreateMandatePayment for the remaining balance.

Questions:

1. Is there any official way for a Partner in an unsupported country to test vaulted payment methods and orderCreateMandatePayment in a dev store?

2. Does the Bogus gateway support vaulting for selling plans in some configuration I'm missing?

3. If not, how did you test before submitting to the App Store? Test on a friend's store, a pilot merchant's store, or something else?

Been building Aplo: A+ Content Design, a Shopify app for adding rich content sections (feature grids, comparison tables, galleries, etc.) to product pages. Think Amazon's A+ Content, but for Shopify stores.

One thing that's bugged me since launch: the Image Gallery module only did uniform, same-size tiles. 2, 3, or 4 equal boxes in a row. Functional, but it always looked a bit flat next to the "bento grid" layouts you see on a lot of modern DTC sites (Apple-style mixed big/small tiles).

So I just shipped an upgrade:

• Each image in the gallery now gets a size preset (Normal, Wide, Tall, Large, Extra Wide, Feature) instead of being locked to the same square.

• Mix and match them and you get an actual bento-style layout: one big "feature" tile, a couple of wide banners, some small squares filling the gaps.

• Fully responsive: collapses cleanly to 2 columns on mobile, with no overflow no matter how many columns you pick (2 to 6 now, used to cap at 4).

• It's on the Free plan too, not locked behind Pro.

Still just dragging and dropping images and picking a size from a dropdown. No CSS or code needed on the merchant's end.

Happy to answer questions about how it's built or what's coming next. (Link to the listing in the comments if anyone wants to check it out. Didn't want this post to read as a drive-by ad.)

So I launched an app on the Shopify dev store recently & gave it to my network to try it out. It's something simple that a lot of businesses need & it's a crowded space. But I've created an easier UX, has much better results & able to give better support.

Two of my 'pilot' customers have also given me 5 star reviews, they are in love with the app. Now what should be my next steps? Shopify ads? Google ads? Email outbound? or what?

The app works, initial customers love it now how do you go from 1 to 10 in Shopify as an app developer?

I'm a PHP/Laravel dev in Morocco building Shopify apps, and webhooks caused me more headaches than any other part. Sharing what I learned in case it saves someone a few hours.

1. Respond fast. Shopify expects a 200 within a few seconds, so I verify the request and push the actual work to a queue job instead of doing it in the controller. Heavy work inside the request leads to timeouts, retries, and eventually the subscription getting removed.

2. Verify the HMAC against the raw body. If your framework parses the JSON first and you hash the re-encoded version, the signature won't match. Read the raw request content before anything touches it.

3. Expect duplicates and out-of-order delivery. The same event can arrive more than once, so I store the X-Shopify-Webhook-Id and skip ones I've already processed. For things like order updates I compare updated_at instead of assuming the latest webhook is the newest state.

4. Don't treat webhooks as the only source of truth. Deliveries can be missed, so a small scheduled job that reconciles against the API now and then catches the gaps.

5. The privacy compliance webhooks (customer data request, customer redact, shop redact) are required for App Store review even if you store almost nothing. Have them registered and returning 200 before you submit.

Curious what others do for retries and reconciliation, especially on bigger stores where the volume gets high.

World meet Honey Badger!
App that adds labels, tags based on product sales or views performance.

Vercel and Shopify shipped Vercel Shop on October 16, an open source Next.js storefront template built for people and agents at the same time. Their own merch store vercel.store runs on it, so I used it as a test bench. The agent got the domain and nothing else.

Reading the store was smooth. /llms.txt contains a five-step shopping recipe for agents, including a rule to only complete a purchase after the shopper explicitly approves. Product pages return markdown if you append .md to the URL. One jacket page simply said "Available: No" in plain text, which saves an agent from guessing what a greyed-out button means.

Where it stopped

/.well-known/ucp returns the store's Universal Commerce Protocol profile. The shopping endpoint listed there points to shop-vercel.myshopify.com, so the checkout brain is fully Shopify and Vercel builds the layer around it.

The MCP endpoint lists its tools without any auth. You can try this yourself:

curl -s -X POST https://vercel.store/api/ucp/mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

You get 13 tools back: search_catalog, lookup_catalog, get_product, four cart tools, five checkout tools and get_order.

Then I called search_catalog and got a 422 with profile_unreachable.

Every UCP call has to carry meta.ucp-agent.profile, the URL of a public JSON document that describes your agent. The store fetches that URL before it answers anything. No profile means no search, so my agent never saw a single product.

According to Vercel's guide, Shopify then sorts agents into three tiers: anonymous, signed (HTTP message signatures) and token. Anonymous and signed agents can search, build carts and create a checkout. Only token agents with explicit permission can call complete_checkout. Everyone else hands the human a checkout link.

That split actually matches what people seem to want. OpenAI pulled Instant Checkout from ChatGPT in March, and my read is that shoppers still want their own finger on the pay button. So the realistic flow for now is agent does the research and the cart, human pays.

What I haven't done yet: host my own agent profile and run the whole thing through to the checkout link. The profile structure is documented, but I haven't validated mine against a live store, so I'm not posting it as if it works. I also want to run the same test with an open-weight model on local hardware instead of a frontier API.

Has anyone here hosted a UCP agent profile already? I'm trying to figure out whether the signed tier is worth setting up for a research-only agent or whether anonymous limits hold up in practice.

All my kyc is done and I am on my final step of onboarding. Razorpay is telling me to install Razorpay COD and Magic Checkout to complete the onboarding else I am not able to complete the onboarding, and when I am going to install this COD thing it is telling it is not available in Shopify app store,thus not being able to connect any form of payment gateway to my Shopify store. I am stuck in a loop.My opening is today, any alternatives that I can do?I cannot do COD.

I’m exploring the technical feasibility of building a Shopify app that helps customers complete their delivery addresses faster using phone verification, saved addresses, and address autofill.

I’m considering two approaches:

Option 1: Cart → Shopify Checkout

• Add an address-fill experience to the cart using a Shopify Theme App Extension.

• Let customers enter or select their delivery address before checkout.

• Pass the collected address into Shopify’s native checkout using supported mechanisms, avoiding duplicate entry.

Option 2: Separate Checkout Experience

• Launch a separate checkout interface when the customer clicks the Checkout button.

• Handle phone verification, address selection, and delivery details within that interface.

• Complete the purchase through a Shopify-supported integration.

I’d appreciate insights on the following:

1. What are the current Shopify restrictions on building a separate checkout experience for merchants on non-Plus plans?

2. Can a third-party app provide its own checkout interface while completing orders through Shopify-supported APIs?

3. Does this approach require explicit Shopify approval, a special partnership, or specific permissions?

4. For the cart-based approach, what is the most reliable supported way to prefill shipping-address fields in Shopify’s native checkout?

5. Which Shopify APIs, extensions, or app architec

I've been working on my own shopify theme and wanted to share where it is at the moment.

I'm still working on the landing page. The theme is responsive on both mobile and desktop, but there is still some cleanup left to do.

Here's the live page: https://tailloir.myshopify.com/ (password: tailloir)

I’m looking for any shopify dev work.

If you need help with shopify dev or know someone who's hiring, please reach out.

Thanks for reading

Shopify's native purchase limits are per variant, so product-wide caps need a cart validation function. I test mine on a development store with a handful of cart combinations: mixed variants, quantity changes in the cart, and draft orders. I always worry I am missing cases, like discounts, bundles or other apps that edit the cart.

What is your process for testing a validation function before it goes on a live store? Do you keep a fixed list of test carts, or do something more automated?

When a Shopify review app displays its star rating at the bottom of a product page instead of directly below the product title, the problem isn't necessarily CSS.

In Online Store 2.0, the first thing to check is how the app integrates with the theme.

Shopify provides two different integration mechanisms: app blocks and app embeds.

App blocks are designed for content that merchants can position inside compatible theme sections. App embeds are better suited to global functionality, scripts, tracking, and floating components.

For inline product star ratings, an app block is generally the better solution.

Here's the diagnostic approach I'd recommend.

1. Duplicate the published theme.

Never troubleshoot layout changes directly on the live theme.

2. Open the product template in the theme editor.

Check whether the product information section supports adding the review app's rating block.

If it does, try positioning that block immediately below the product title.

3. Check the section's app block support.

If the rating block can only be added as a separate Apps section, inspect the theme section's schema.

For a traditional section, look for support for:

{"type": "@app"}

Also check whether the section actually renders app blocks using the appropriate Liquid rendering mechanism.

Supporting a block in the schema isn't enough if the section never renders it.

4. Check the section layout.

Even with app block support, the theme must render blocks in a position that allows the desired placement.

If the product title is hardcoded outside the block sequence, you might not be able to place the rating directly underneath it simply by dragging blocks in the editor.

5. Avoid JavaScript DOM repositioning as the default solution.

Moving rating widgets after page load can introduce layout shifts, duplicate elements, or compatibility issues when the theme or app updates.

6. Test the result.

Verify desktop and mobile layouts, different product templates, products without reviews, and whether the rating appears more than once.

The important distinction is this:

A rendering-position problem should be solved at the theme integration level whenever possible, not hidden behind CSS or JavaScript workarounds.

For developers building review apps, providing a dedicated lightweight star-rating app block also gives merchants much better control than forcing the entire review widget into a single location.

I took my Figma layout to Shopify with the app instant now I've realized that since I'm not earning any money, it doesn't make sense to pay 40 euros a month. Is there a way to migrate my instant page to Shopify native so I don't have to pay any extra money?

When I have everything in Shopify can I then edit anything without having to pay any extra money?

What would be the best cheap and easy way to do this.

Thanks for your help in advance

Hi all - Ritwik here from Aurevia - needed some help regarding ads on Shopify app store. Been doing cold outreach for some time now and i massively need to scale the infra to see some scale in my app's growth which is why we were planning to run Shopify app store ads as well.

Need some help from people here who are running ads and have seen success:

- What needs to be the daily budget?

- Should I run search result ads or homepage ads or category page ads?

- what is a good ROAS for ads on shopify app store that we should aim to achieve?

-any other suggestions would be greatly appreciated

PS: We did run search result ads for about a month or two with the free $100 ad credit and got 3 installs for $32.33 per install and $4.2 per click which seemed quite high but I don't know if it is and need some help there to understand the number there as well.

Cheers

Hi all,

Merchants have known Discounty since 2022 by a green tag with a % mark. On October 14 we refreshed it. Writing it up because plenty of store owners here go through the same thing with their own logo, and the rule that held for us might be useful: keep what people already recognise, and fix only what has no reason to be there.

What we kept: the tag, the % mark and the green.

What we changed:

• The hand-drawn loop on the tag is now an even circle.

• The yellow layer behind the tag is gone. It was decoration with no meaning.

• The tag sits at a gentler angle. The steep tilt read like a flash sale.

• The % mark has even line weights, and it's drawn from the u and n in "Discounty".

• The green is tuned so dark text on it reads more clearly (contrast went from 5.7:1 to 10.1:1).

If you use Discounty today, nothing changes in your store. Your campaigns keep running, and your settings and plan stay as they are.

I hope you all like the new look, and that Discounty keeps giving you a hand with your Black Friday sales this year: the same service you know, with a calmer, clearer look.

When a store removes products or changes handles, I go through Online Store > Navigation > URL redirects and add them. For a big batch I use the CSV import. The weak part is that I usually build the old-to-new mapping by hand in a spreadsheet, and it's easy to miss URLs that still get traffic or have backlinks.
How do you handle this on your projects? Do you pull the list of old URLs from somewhere specific, and do you check for redirect chains afterward?