DEV Community

Cover image for Building a Shopify app for the June 30 Scripts deprecation: V1.3 feature tour, pricing breakdown, and the bug that ate my Friday
Jack Petersen
Jack Petersen

Posted on • Originally published at paylogic.dev

Building a Shopify app for the June 30 Scripts deprecation: V1.3 feature tour, pricing breakdown, and the bug that ate my Friday

Shopify Scripts — the Ruby-based payment customization tool that's been around for ~8 years on Shopify Plus — shuts off June 30, 2026. Editing's already disabled since April. Come June 30, any active payment Script silently stops firing and merchant checkouts revert to default.

Estimates put 2,000-5,000 Plus merchants on Scripts for payment customization specifically. Each one has a hard migration deadline. I built PayLogic for that.

V1.3 just shipped and the product is feature-complete for the deadline. Here's the full picture: every feature, what tier it's on, and the reasoning behind the pricing.

Current state

  • 1 active install, 1 churned (paid 2 subscription charges, uninstalled within 25 min)
  • Total revenue to date: $9.98
  • Shipped 4 versions in 5 weeks: V1 → V1.1 → V1.2 → V1.3
  • Live on the App Store: apps.shopify.com/paylogic
  • Landing page + blog + free in-browser Scripts converter: paylogic.dev

The feature tour

Conditions (when does a rule fire?)

PayLogic ships 16 rule templates. The conditions you can build rules around:

  • Cart total ≥ or ≤ a threshold
  • Item count threshold
  • Shipping country (one or many)
  • Cart currency (one or many)
  • Shipping method title contains a keyword
  • First-time customer (no prior orders)
  • Returning customer (≥ N prior orders)
  • Early customer (≤ N prior orders)
  • Big spender (lifetime amount-spent threshold)
  • Customer has any of these tags
  • Customer is missing all of these tags
  • Product in cart has any of these tags
  • Risk composite (heuristic combining first-time + cart total + flagged shipping countries — fully merchant-configurable)
  • Customer prior risk (uses Shopify's order risk model — more on this below)

Actions (what does the rule do?)

  • Hide a payment method at checkout
  • Rename a payment method ("Cash on Delivery" → "Pay at door — $5 handling fee")
  • Reorder payment methods (move Shop Pay to position 1 for repeat customers, etc.)

Plus

  • Multi-condition rules with AND/OR logic
  • One-click Shopify Scripts importer — reads your existing Ruby, converts the common patterns to PayLogic rules
  • Checkout UI extension that displays a merchant-authored message when a method is hidden
  • Auto tag-cache backfill on install (so tag rules work immediately, no manual setup)
  • Rule versioning with one-click rollback (last 50 snapshots, Plus tier only)

Tier breakdown

Starter — $1.99/mo (3 active rules)
Cart total, country, currency, item count, shipping method, first-time/returning/early customer rules. Hide/rename/reorder actions. Scripts importer. Email support.

Standard — $4.99/mo (unlimited rules)
Everything in Starter, plus custom customer-tag and product-tag rules (read any tag from your Shopify admin, not a hardcoded list), plus the big-spender lifetime-value rule.

Plus — $9.99/mo (unlimited rules + advanced)
Everything in Standard, plus the risk composite rule, plus the customer prior-risk rule, plus rule versioning with one-click rollback, plus priority support with a same-business-day reply target.

Free Development — free
Full feature parity for Shopify Partner development stores. Agencies can test PayLogic on every client project at zero cost.

The differentiator that earns the Plus upgrade

The customer prior-risk rule exposes Shopify's native order risk signal: "hide Cash on Delivery for customers whose past orders Shopify flagged HIGH or MEDIUM risk."

Scripts couldn't see this data. Functions can. For COD-heavy markets (MENA, SEA, LATAM) where return-to-origin rates sit at 25-35%, this single rule typically cuts RTO 5-15 percentage points. On a store doing $50k/mo of COD volume, that's $7-9k/year of recovered freight. The app pays for itself in roughly a week.

This is the rule that exists because the platform changed.

Why $1.99 when competitors charge $9-25

Most apps in the Shopify payment customization space price at $9-$25/mo with no free tier. I priced PayLogic far below that on purpose.

The math: most payment Scripts in production do $1-50/month of value for the merchant — they stop the occasional bad order, not transform the business. If the app costs $20/mo, the value gap is thin and most merchants churn within a month.

I'd rather be the obvious "yes" pick at the entry tier and earn the upgrade to $9.99 Plus via the risk rule. The Free Dev plan is bait for agencies who'd otherwise have to budget the app on every client install.

Am I leaving money on the table? Maybe. I'll know once I have ~50 paid installs to look at the conversion mix.

The bug that ate my Friday

V1.3 (the custom-tag rules) shipped Thursday. I tested it on the dev store. Cash on Delivery wouldn't hide for the tagged customer. Spent ~8 hours debugging this.

Surface symptom: the rule's condition (customer_has_any_tag: ["myopia-tier-2"]) evaluated to false even though the customer clearly had the tag in Shopify admin.

The actual cause was a 4-layer onion:

  1. The Function reads tags from a metafield (paylogic.tags-cache), not the live tag field. We cache via webhook.
  2. The customers/update webhook payload contains a tags field. I trusted it.
  3. Shopify redacts PCD-gated fields in webhook payloads independently of Admin API access. The tags field is redacted even when PCD Level 1 is approved. So payload.tags was always empty.
  4. The handler wrote {"tags":[]} to the cache every time. Worse: every metafield write itself fires a customers/update webhook → which writes empty again → permanent feedback loop.

Fix: ignore payload.tags entirely. Use the customer ID from the payload to query Admin GraphQL for the real tags. The Admin API respects PCD properly (returns real tags when granted, errors when not).

If you're building a Shopify app that touches PCD fields, you almost certainly need to know this.

Architecture (for the curious)

  • Built on Shopify Functions (Rust → WASM), runs at Shopify's edge with sub-50ms p95 latency
  • No carrier-service callback hacks — fully Functions-native
  • Webhook-cached tag system: the Function reads tags from a metafield kept fresh by customers/update and products/update webhook handlers (so tag-based rules match against any tag with no scope or latency penalties)
  • Rule config stored in payment customization metafields; full version history kept in Prisma on the app backend
  • Free Scripts → Rules converter on paylogic.dev runs the same parser as the in-app importer, so what merchants see in the converter is exactly what they'd get on install

What's next

The product is done for V1. Bottleneck now is distribution, not features.

  • Product Hunt launch in ~10 days (the converter tool is the marquee asset)
  • Cold email to 50-100 Scripts-using Plus merchants sourced via BuiltWith
  • This post
  • Long-form blog content for SEO (already 2 posts up: Scripts migration guide and "5 ways to hide Cash on Delivery compared")

13-month window until the deadline. The product is ready; distribution is the actual job for the next year.

If you're on Shopify Plus and use Scripts, the free converter at paylogic.dev/scripts-converter/ might save you 10 minutes. Genuinely useful feedback if it misses patterns your scripts use.

If you're building a Shopify app or pricing indie SaaS, happy to swap notes — pricing strategy, Shopify Functions, distribution tactics, all of it.

Top comments (2)

Collapse
 
tokidigital profile image
mamoru kubokawa

The pricing logic is sound for the Scripts-replacement framing — but the risk rule breaks your own frame, and I think that's where you're underpriced.

Your anchor is "most Scripts did $1-50/mo of value, so price low or churn." True for hide/rename/reorder. But the prior-risk rule isn't replacing a Script — Scripts couldn't see that signal. By your own number, 5-15pp RTO reduction = $7-9k/year on a $50k/mo COD store. A merchant getting quantified $7k/year of recovered freight won't blink at $9.99 — they'd rationally pay $49-99/mo for that one rule. So the $1.99 entry is a fine acquisition wedge, but I'd pull the risk rule out of the flat ladder and price it against the value it creates (a COD-volume tier?). You're not leaving money at the entry tier — you're leaving it at Plus.

(Also: the PCD-redacted-tags feedback-loop writeup is a real public service — zero Google results until someone documents that footgun.)

On "distribution is the job for the next year" — same wall everyone in this corner of dev.to is hitting. Leading the PH launch with the free converter is the right instinct. What's your read: will cold email to BuiltWith-sourced Scripts merchants outperform the PH spike, or is PH mostly for the converter's reach?

Collapse
 
jackpetersencode profile image
Jack Petersen

This is a great pricing critique, and you're right — the money's at Plus, not the entry tier.

Where I'll push back a little: the prior-risk rule's $7-9k/year is a ceiling, not a floor. It only fires for returning customers who already have risk-flagged order history — it reads Shopify's order-risk signal off prior orders via a metafield I populate on the risk-assessment webhook. So a store doing $50k/mo COD but mostly first-time buyers (which describes a lot of COD-heavy MENA/SEA traffic) gets far less from prior-risk specifically; they fall back on the composite heuristic rule, which is a weaker signal. The realized value is real but conditional on repeat-COD volume — and that conditionality is exactly what makes a clean value-metered tier hard to draw. I can't anchor a price to $7k when only the top quartile of risk-rule users actually capture it.

That said, the mechanism exists. Shopify supports usage-based billing, so a "COD Pro" tier metered on COD order volume (or per-order above a threshold) is technically straightforward. The honest reason it isn't built: at zero installs I'd be optimizing a revenue axis with no volume flowing through it. A legible 3-tier ladder removes friction from "should I even try this" and sails through Built-for-Shopify review; a metered tier adds a "why did my bill change this month" support load I can't absorb solo on day one. So you've correctly identified the v2 move — once there's enough risk-rule usage to see real COD distributions, pulling it into a value-priced tier is the obvious expansion. Filing it.

(And thanks on the PCD writeup — that one cost me ~8 hours and four layers of "but the code looks right." If it saves one person that, worth the post.)

On distribution: my read is cold email beats PH for installs, but they're not really competing for the same thing. PH is a spike of makers and other founders — great for the converter's reach (devs will share a free in-browser tool) and for backlinks/social proof, close to useless for direct merchant conversion. The PH crowd isn't the buyer.

Cold email to BuiltWith-sourced stores is higher-intent, but the targeting's leakier than it looks — BuiltWith can tell me "Shopify Plus," not reliably "uses Scripts," since Scripts run server-side in the checkout sandbox and leave no client footprint to detect. So "Plus store" becomes a noisy proxy and the intent dilutes fast.

The channel that beats both: merchants who've already raised their hand — forum/Reddit/X threads where someone's actively asking "how do I migrate my payment Scripts before June 30." Exact problem, exact moment, no targeting guesswork. So for conversion it's reactive > cold > PH. I'm running PH mostly for the converter and the SEO tail, not expecting it to move install count much.

Are you building in this corner too, or just sharp on pricing? Either way — genuinely useful comment, the kind that's worth more than the post it's under.