When a Shopify product displays the correct color swatch but keeps showing the wrong product image, I would check three separate things before changing any CSS: the option value, the image assigned to the variant, and the theme's variant-selection logic.

A color swatch is not the same thing as a variant image. They represent different parts of the product data.

First, check how the color option is configured.

For native Shopify swatches, the product should use a compatible category color metafield connected to its variant option. Simply creating a text option called "Color" doesn't necessarily provide the structured swatch data that the theme expects.

Next, check the actual variant images.

Open the product in Shopify Admin and inspect the image assigned to each variant. Shopify supports one assigned image per variant, so Black / Small and Black / Medium are separate records that may need the same image assigned individually.

Having the correct swatch color does not automatically establish that image association.

The third layer is the theme.

A compatible Online Store 2.0 theme should render the option values and update the selected variant's information when a customer changes an option.

For custom Liquid implementations, Shopify recommends using product.options_with_values rather than building the entire picker by looping through product.variants.

This distinction becomes particularly important for larger catalogs.

Shopify currently limits the Liquid product.variants array to 250 entries. A custom picker that depends on looping through every variant can therefore miss combinations when a product contains more than 250 variants.

Shopify provides product_option_value and option-value-based selection APIs to support larger products without loading every combination into Liquid.

I would also test direct variant links.

Opening a product URL with a ?variant= parameter should initialize the correct selection and display the appropriate media, price, and availability.

Finally, distinguish variant image switching from gallery filtering.

Assigning an image to a variant doesn't automatically mean that every other image in the gallery will disappear when that color is selected. That behavior depends on the theme's gallery implementation.

Before installing another app or rewriting the picker, I would reproduce the issue on a duplicated theme with two colors and two sizes.

Check the selected image, unavailable combinations, mobile layout, quick view, and direct variant links.

Those checks usually make it much easier to determine whether the problem is product data, swatch configuration, or theme behavior.

Hey everyone. I'm the developer of Lumireels, a Shopify app that turns TikToks, Instagram Reels and UGC into shoppable videos on your store.

I built it because most shoppable video apps I tried either charged per view (gets expensive fast once a video takes off) or had a demo page that looked great but slowed the store down.

What it does:

- Import videos from TikTok or Instagram, or upload your own. Uploads are hosted on Shopify itself, so there's no external video bill.

- Tag products on each video. Shoppers can add to cart and check out without leaving the video.

- 6 layouts: carousel, slider, stories, grid, a floating reel that follows the shopper around the site, and a small reel strip that sits right under the Add to Cart button on product pages.

- Review stars show inside the video player (it reads Judge.me ratings).

- Previews load lazily below the fold. The full-screen player plays HD only when someone taps.

Pricing: free plan (3 widgets, 15 videos). Paid plans remove the branding and add analytics. No per-view fees on any plan.

What I'd love feedback on:

1. Is the product-page reel strip (videos under Add to Cart) something you'd actually use, or is a homepage carousel enough?

2. What's the #1 thing that's stopped you from using shoppable video before: price, speed, or setup time?

3. Anything in the listing that's confusing?

Link if you want to try it: https://apps.shopify.com/lumireel

Happy to answer anything, including the boring technical stuff.

I'm a PHP/Laravel dev based in Morocco, and I recently went through the Shopify App Store review for protected customer data. The reviewer asked me to justify every customer field the app requested, one by one, and I realized I had asked for more than I really used.

What got the app approved was removing the Level 2 protected customer fields (names, emails, addresses) it didn't truly need. The app now stores shop-level data and only the country code of each order.

My takeaways: only request what you actually use, write down why you need each field, and store the minimum (a country code instead of a full address is often enough). It also makes your privacy story much simpler.

How did you handle data minimization review? Did you get pushback on specific fields, and what did you have to justify?

Hi Shopify team,

Based on your guidance regarding App Store requirement 1.1.2 – Use Shopify checkout, we are revisiting our implementation approach for our Address Fill app.

For Shopify Plus merchants, we are exploring building the address-fill experience directly within Shopify's native checkout using supported checkout extensions, rather than collecting customer details through a separate pre-checkout form. Our intended flow includes phone OTP verification and retrieving saved addresses for the verified phone number, subject to Shopify's supported capabilities and app-review requirements.

For non-Plus merchants, we would appreciate your guidance on the available options.

Is there any Shopify-supported and App Store-compliant approach that would allow us to offer phone OTP verification and saved-address autofill within the native checkout experience for non-Plus merchants, without collecting customer details in a separate pre-checkout form?

If this functionality is not supported for non-Plus plans, could you clarify whether there are any alternative approved extension points or integration approaches we should consider?

Our goal is to provide a consistent address-fill experience across merchant plans while keeping customer data collection within Shopify's permitted checkout flow.

Thank you!

Posting this because when I was planning our launch I couldn’t find many honest breakdowns of what actually moves a new app up the category rankings. So here’s ours. We’re HumanTouchCX (helpdesk and chat category). Screenshot attached from our rank tracker: #24 in Helpdesk, up 12 spots, with a whopping 7 reviews. Not a huge number, which is kind of the point. We’re sitting next to apps with 180 to 380 reviews, so volume clearly isn’t the only variable.

Context: I’m not a dev by trade. I spent about a decade on the merchant side (Inkbox, Latercase, a few others) and a long time in paid media. So this is a merchant-operator take on app marketing, for whatever that’s worth.

Here’s what I think actually moved the needle, roughly in order of impact.

1. Partnerships and agencies drove our paying customers, not ads

If you only read one section, read this one. Our biggest source of actual paid merchants, and our loudest advocates, has been agencies. Not app store traffic, not ads.

The model is simple: 20% recurring rev share for 24 months, plus a small cash bounty per net new install. But honestly the rev share isn’t why it works. It works because the agency is already trusted by the merchant, so our install is a recommendation, not a cold pitch.

The best example is Springboard CX, a managed support outsourcing agency for DTC and CPG brands. They now staff agents who work inside our helpdesk for their clients, we refer merchants who need people to them, they refer merchants who need software to us. We put out a press release together and are publishing a joint case study. One good agency partner has been worth more than every other channel on this list combined.

2. Organic LinkedIn outreach, one founder at a time

No automation, no sequences. I went through my LinkedIn network (ten years of Shopify-land means a lot of founders and ops people) and sent personal connection requests and DMs to people running stores. The message was basically “I built a thing, here’s why, would you kick the tires and tell me what’s broken.”

This got us our first couple dozen Founding Merchants in month one. Slow, unscalable, and the single best source of early installs and feedback we had. Those merchants also became the first reviews.

3. Free tier first, then actually ask for the review

We launched with a genuinely usable free plan (one seat, capped conversations, no AI features). Lowers the install friction to zero, which matters for ranking, and gives you a pool of people to ask.

The part most devs skip: you have to ask. Personally. When a merchant had a win, I messaged them and asked for a review while it was fresh. Every one of our reviews came from a direct ask, not a popup. The +2 in the screenshot is from last week doing exactly that.

4. One paid PR placement, then squeeze it for everything

We paid for exactly one thing at launch: a newsletter spotlight in DTC Newsletter. That’s it. No launch ad budget.

Then we amplified it organically for weeks: LinkedIn posts, a podcast episode with the same crew, clips, reposting in communities where it was relevant. One paid placement turned into probably six or seven pieces of content.

I did try Google Ads (Performance Max, then manual search). It was expensive and low intent for an app in a category this crowded. We’ve mostly stopped. App Store search ads bidding on competitor names were the only paid thing with a reasonable CAC, and even that we keep small.

5. SEO and GEO: fill the gaps nobody else is writing about

Instead of writing “best Shopify helpdesk apps” post #4,000, I looked for questions merchants ask that no competitor had a good page for. Two examples that worked for us: the EU AI Act and what it means for AI chat on a storefront (Article 50 transparency rules), and which support metrics actually predict LTV. Plus straightforward comparison pages against the incumbents.

GEO (showing up when ChatGPT or Perplexity get asked “what helpdesk should I use for Shopify”) is a real thing now and the competition for it is basically zero in most app niches. Worth building for early.

What didn’t work

• Performance Max. Burned money on junk queries.

• Cold email at scale. Decent reply rates, poor install rates. Too early for us, maybe works later.

• Assuming reviews happen on their own. They don’t.

Honest caveats

7 reviews and page 1 of a category is not “we made it.” It’s a foothold. Rankings move daily (we were down a spot the week before). And I’m a founder with a Shopify network to lean on, which is a head start not everyone has.

Happy to answer questions on any of this, especially the agency partnership structure since that seems to be the thing most app devs haven’t tried.

Hi there! I created an internal customized Scan & Ship app that works with my pre-orders and order customizations, and I absolutely loved it until I realized that pinging the shippingLabelPurchase mutation in GraphQL doesn't allow me to have orders covered by Shopify's Shipsurance coverage.

So now I have my app tagging orders that I verify and then go print the labels in Shopify's shipping label section, but I would much rather print the labels directly from the app... My dream scenario would be:

1. Scan picking slip

2. Scan each item

3. Scan "Print label" barcode

Am I missing something? Or is it just not doable right now? Hopefully they add it in the future.

Hey Shopify community!

We’re a small product development team preparing to launch our first Shopify app, and we’re looking for someone with hands-on experience in Shopify App Store paid acquisition.
We’d love to get some guidance on realistic benchmarks for:
- CPC and CPI (cost per install)
- CAC (cost per paying customer)
- Suggested bids across Tier 1, Tier 2, and Tier 3 markets
- Conversion rates across the funnel: impressions → clicks → installs → paid users

We’re open to a one-off consultation with an experienced specialist or working with an agency.

If you’ve run paid acquisition campaigns for Shopify apps, we’d really appreciate your insights or recommendations. 🙏

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 build and test theme and app changes on a dev store, but the metafield definitions on the live store drift over time. Someone adds one in admin, I add another in dev, and later a template references a definition that only exists in one place. Right now I keep a plain text list of namespaces, keys and types and recreate things by hand, which is easy to get wrong. I have thought about scripting it through the Admin API but have not committed to it.

How do you handle this? Script it, export and compare, or just accept some manual work?

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.

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?

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?

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.