DEV Community: Jack Petersen

The Shopify Scripts deprecation is 16 days away. Here's a triage playbook.

Jack Petersen — Sun, 14 Jun 2026 15:12:07 +0000

If you're a Shopify merchant (or running migrations for one) and your Scripts haven't moved to Functions yet, this post is for you. The June 30, 2026 deadline isn't moving. You have a little over two weeks. Here's how to triage what's left.

I'm the developer of PayLogic, a Shopify Functions app that replaces payment-customization Scripts. Most of the migration patterns described below come from reading a steady stream of merchant Scripts while building the parser, and from threads in the Shopify Plus community over the last few months. The framework here is migration-path-agnostic — useful whether you migrate yourself, hire it out, or use an app.

Disclosure: I'll mention PayLogic and a free converter I built at the bottom. The tools are interchangeable; the framework is the value.

Why this is happening, briefly

Shopify Scripts (Ruby, server-side, per-checkout) is being replaced by Shopify Functions (Rust or JS compiled to WASM, deterministic sandbox). Functions have better performance, better security, and stricter resource limits.

The deprecation has been announced since 2023. Most merchants who used Scripts have already migrated. The ones who haven't typically fall into three buckets:

They forgot. Scripts run silently and reliably. Out of sight, out of mind.
They lost the dev. The person who wrote the Scripts left the company a year ago. Nobody on the team can read the Ruby.
They thought the deadline would slip. It won't.

If you're in any of these, read on.

What actually breaks on July 1

There's no banner. No email. No grace period. At 00:00 UTC on July 1, 2026, in concrete terms:

Your Scripts stop executing. Whatever logic they ran at checkout (hide COD, hide express checkout in specific countries, rename payment methods, reorder, surcharge math, custom shipping rules) — none of it runs.
Your existing payment gateways all reappear in their default state. If you were hiding Cash on Delivery for risky customers, it shows for everyone. If you were hiding express checkout in Saudi Arabia, it appears in Saudi Arabia.
You won't find out from Shopify. You'll find out from an RTO spike, a customer report, or a fraud-rate alarm.

This isn't a "things will break loudly" deadline. It's a "things will silently misbehave starting July 1" deadline. The merchants who get blindsided are the ones who assume they'll get a warning.

Step 1 — Inventory your Scripts (today)

Shopify admin → Apps → Scripts editor. List every Script currently running. For each one, capture:

Title and trigger (Payment, Shipping, or Line Item)
Full Ruby source (copy into a doc)
Active/inactive status
Last-modified date

If you're on Plus but the Scripts editor isn't visible, verify with the Admin API:

curl -X GET "https://your-shop.myshopify.com/admin/api/2024-04/scripts.json" \
  -H "X-Shopify-Access-Token: $ADMIN_TOKEN"

Time budget: 30 minutes. If you've never opened the Scripts editor and you're not sure if you have any, this step is non-optional.

Step 2 — Categorize each Script

Read each one and put it in one of four buckets.

Bucket A — Trivial translation

Maybe 60% of Scripts I read fall here. Simple conditional logic on cart state:

if Input.cart.subtotal_price.cents > 100_00
  Output.cart.payment_gateways.each do |g|
    g.disable if g.name.include?("Cash on Delivery")
  end
end

Translates cleanly to a single payment-customization Function with one IF condition and one HIDE action. Whether you write the Function yourself or use a rule builder, the result is identical.

Bucket B — Multiple rules combined

Multiple conditions chained, or multiple actions in one Script:

unless Input.cart.customer&.tags&.include?("vip")
  if Input.cart.subtotal_price.cents > 100_00
    Output.cart.payment_gateways.each do |g|
      g.disable if g.name.include?("Cash on Delivery")
    end
  end
end

Still mechanical translation, but you need to be precise about logical operators (AND vs OR), null-safe customer access (some buyers are guests), and operator precedence. A skilled dev or a competent rule builder handles this; a panicked junior dev gets it subtly wrong.

Bucket C — Custom math or behavior Functions don't support

Payment Customization Functions intentionally do less than Scripts did. Specifically:

No surcharges (you can't ADD an amount via PaymentCustomization)
No payment-method creation (hide / rename / reorder existing only)
No modification of cart line items at the payment step
No reading shop-level metafields or external data without an explicit input query

If your Script does any of these, the Function platform can't replicate it as-is. You need:

A workflow rebuild (often the right call — many surcharge Scripts existed to compensate for behaviors Shopify now supports natively)
A different Shopify primitive (Cart Validation Function, Discount Function, or Delivery Customization Function depending on what the Script does)

Bucket D — Touches data Functions can't access

Functions run in a deterministic sandbox with a strict input query. If your Script reads things like:

A third-party API at checkout
Shop metafields not part of the Function input
Customer order history via the Admin API
Live shipping-rate quotes from a carrier

…you can't replicate it directly. Workarounds:

Cache the relevant data into a metafield via a webhook (Function reads metafield instead of fetching live)
Move the logic to a webhook-driven order workflow (different latency/UX profile)
Build a custom backend that hooks into the order lifecycle

Bucket D is the hardest. If most of your Scripts are here, 16 days might not be enough. Plan accordingly.

Step 3 — Pick a migration path per bucket

For Bucket A

Three paths in order of effort:

A1: Use a payment-customization app. Apps with Scripts importers translate Ruby to visual rules automatically. For Bucket A logic, the import is one click. Cost: $2–$10/mo, ongoing.

A2: Write the Function yourself. Shopify's Functions docs walk through it. Install Shopify CLI, scaffold a Function, write the logic in Rust or TypeScript, deploy. Cost: a few hours, zero ongoing.

A3: Hire it out. Agencies bill $500–$2,000 for a Bucket A migration. Reasonable if you don't have dev capacity.

For 1–3 simple rules, A2 is fine. For more — or if you'll need to edit rules later without a dev — A1 wins because you get a UI.

For Bucket B

Same three paths, but the cost of A2 doubles (more time, easier to get wrong). I'd skew toward A1 here unless you have a strong Shopify dev on staff.

For Bucket C

Workflow rebuild. Talk to a Shopify Plus partner agency. Don't expect to migrate as-is — the platform won't let you, so the rebuild is the work.

For Bucket D

Same. Find an agency that does Functions + custom backend. There aren't many. Reach out today.

Step 4 — Test in a draft order (every time)

Before you flip anything live, test in a draft order. This is the step most merchants skip and the one that produces the "wait, it broke" tickets in July.

The discipline:

List the 5 most common checkout scenarios in your store: new customer + low cart, returning customer + high cart, international shipping, COD-eligible region, VIP customer. Whatever maps to your business.
After implementing the migration, place a draft order for each scenario. Use the Shopify draft-order tool, set the customer, set the cart, place it without charging.
Verify the checkout behavior matches what the Script used to do.
If anything's different, fix and re-test.

Critical gotcha: if you have OTHER customizations layered on top of your Scripts (checkout.liquid edits, Shopify Flow workflows, third-party payment apps), the post-migration behavior may combine differently than expected. Test the combined behavior, not just the migrated rule in isolation.

Step 5 — Schedule the cutover

You want the migrated Function live BEFORE June 30, not on June 30. Specifically:

Deploy the migrated Function (or app) at least 5 days before the deadline.
Disable the old Script when the new system is live. Don't run both — Scripts win as long as enabled.
Test the live behavior in production with a real test order.
Monitor checkout for 48 hours after cutover. Anomaly? Roll back to Scripts (still works until June 30) and fix.

If you wait until June 29 to flip the switch, you have no rollback window. Don't.

What if you genuinely can't make the deadline

Realistic backup plans:

Plan 1: Disable Scripts proactively, accept temporary degradation. Better to know your COD-hiding logic isn't running than to be surprised on July 1. Disable July 1 morning, manually. Customers see default behavior until the migration ships. You'll know exactly what you're sacrificing.

Plan 2: Ship a minimum viable Function for the highest-stakes Script. If your Scripts span 5 use cases but only 1 of them (hiding COD on risky orders, say) actually moves business KPIs, migrate just that one. Let the other 4 lapse. Backfill later.

Plan 3: Use an app for an emergency import. Most payment-customization apps have a Scripts importer. Install one. Click import. You'll have a passable migration in under an hour. Might not perfectly replicate every nuance, but it'll restore ~90% of the behavior. Refine later.

Don't pretend you'll be fine. Pick a backup plan now.

Final 16-day calendar

If you're reading this with the deadline 16 days out, here's the cadence:

When	What
Today (weekend)	Open the Scripts editor, inventory everything, categorize into four buckets.
Monday–Tuesday	Pick a migration path per bucket. Start the work for Buckets A and B.
Wednesday–Friday	Test in draft orders. Identify gotchas. Fix and re-test.
Following Monday (June 22)	Deploy to production. Disable old Scripts. Monitor.
June 22–25	Buffer days for the inevitable surprises.
June 29	Final verification. Place a real-money test order, confirm the migrated behavior, breathe.
June 30	No action needed. You're done.

A pitch (skip if not interested)

I built PayLogic as a payment-customization Functions app specifically for the 60–70% of merchants in Buckets A and B above. The Scripts importer pastes Ruby into a textarea, parses it, shows you the visual rules it detects, and one-clicks them live.

There's a free standalone in-browser converter at paylogic.dev/scripts-converter if you want to see what your Scripts translate to without installing anything. No signup, no email capture.

The app costs $1.99–$9.99/mo depending on the feature set. The cheapest tier covers basic hide/rename/reorder; the most expensive includes a risk-composite rule and a customer-prior-risk rule (the latter reads Shopify's native order-risk signal from a customer's previous orders to auto-hide COD for known-risky returning shoppers — particularly useful for COD-heavy markets fighting return-to-origin losses).

If PayLogic doesn't fit your use case, the converter is still free and the framework above is migration-path-agnostic. Use whatever ships you by June 30.

One last thing

If you're an agency: the merchants you've handled are unlikely to all migrate before the deadline. Some will miss it. Some will be silently broken on July 1 and not notice for weeks. Reach out to them now, even if your last engagement was a year ago. The deadline is your reason to re-establish contact, and most agencies aren't doing it.

Good luck. The next 16 days matter.

What I learned writing a Shopify Scripts Functions parser

Jack Petersen — Tue, 02 Jun 2026 18:56:06 +0000

Shopify is killing Scripts on June 30, 2026. That's 28 days from when I'm writing this. After that, every Shopify store running Ruby Scripts to customize their checkout — hide payment methods, rename gateways, apply discount rules, route shipping — will see those Scripts stop executing.

Most stores still haven't migrated.

I built PayLogic, a Shopify Functions-based payment-customization app that's now live on the Shopify App Store (disclosure up front — I'm not pretending to be a disinterested observer). To help merchants migrate to it, I needed an importer that could take a Ruby Script as input and produce equivalent rule definitions. I figured: how hard could parsing a small Ruby DSL be?

Harder than I expected.

I extracted the parser into a free standalone tool — paste a Script, see what's translatable, what's partial, what won't. Runs entirely in your browser, no signup, no upload. It's at paylogic.dev/scripts-converter if you want to play with it.

But what I want to share here is what I learned by reading a lot of real Shopify Scripts, not the tool. Some of these patterns are useful if you're migrating manually. Some of the surprises are useful if you're ever building anything that integrates with Shopify webhooks. And the war story about an eight-hour debugging session is something I wish someone had written before I had to figure it out.

The deceptively-hard parsing problems

Shopify Scripts are written in a Ruby DSL with a small surface area. From the outside this looks like the easiest possible parsing target — limited syntax, limited semantics, limited shape of business logic. A few regexes and you're done, right?

Reader, you are not done.

Two block syntaxes for the same operation

The first thing that breaks a naive parser is Ruby's two block syntaxes. These are semantically identical:

# Single-line brace form
Input.payment_gateways.delete_if { |gw| gw.name == "Cash on Delivery" }

# Multi-line do/end form
Input.payment_gateways.delete_if do |gw|
  gw.name == "Cash on Delivery"
end

In my sample of real merchant Scripts, the multi-line form is way more common. Idiomatic Ruby prefers do...end for multi-line and {...} for single-line. So a parser that only handles one form misses the majority of real Scripts.

The naive approach — regex matching for delete_if[^|]*\|... — works for the single-line form because the whole pattern is on one line. For the multi-line form, the pattern spans lines, and you have to find the matching end, which means tracking block depth.

Which gets harder because...

Modifier-if looks just like block-if

Ruby has modifier if, which trails an expression and conditionally evaluates it:

gw.name = "Credit Card" if gw.name == "Bogus Gateway"

This is one statement. There's no end.

It's syntactically near-identical to block if, which opens a scope that requires an end:

if gw.name == "Bogus Gateway"
  gw.name = "Credit Card"
end

If your block-depth counter sees if and increments depth, you over-count modifier-ifs and never find the matching end for your outer block. Distinguishing block-if from modifier-if without writing a full Ruby tokenizer required a heuristic: check whether if/unless appears at the start of a stripped line. If so, it's block-opening. If it's mid-line after an expression, it's a modifier.

This isn't bulletproof — a Script could have if true; do_thing; end on one line — but in the wild I haven't seen merchant Scripts that complex.

Compound conditions

Real merchant conditions tend to compose:

if Input.customer.orders_count >= 5 && Input.customer.total_spent >= Money.new(cents: 100000)
  Input.payment_gateways.delete_if { |gw| gw.name == "Cash on Delivery" }
end

So I split the condition expression on top-level && and ||, then parse each side as its own predicate. For AND/OR mixed cases, I bail with a warning — Functions rules support uniform AND or OR via match_mode, but parenthesized mixing requires more sophisticated AST work that I haven't done.

`unless` is negation, sometimes invertible

unless cond is if !cond. For simple predicates with clean inverses, this maps cleanly:

# Original:
unless Input.customer.tags.include?("VIP")
  Input.payment_gateways.delete_if { |gw| gw.name == "Premium Card" }
end

# Becomes:
# "Hide Premium Card when customer is NOT tagged VIP"

For some conditions there's no clean inverse — for example, "cart total ≥ X" inverts to "cart total < X," but boundary handling matters (≤ vs <), and I'd rather warn than approximate. So my parser has a small invertSingleCondition function that handles tag presence/absence, order-count thresholds, and first-time/returning customer flipping, and warns on anything it can't invert cleanly.

Three actions, three patterns

The three Script actions for payment customization map to three Ruby patterns:

# HIDE: delete_if
Input.payment_gateways.delete_if { |gw| gw.name == "X" }

# RENAME: map with conditional assignment
Output.payment_gateways = Input.payment_gateways.map do |gw|
  gw.name = "Credit Card" if gw.name == "Bogus Gateway"
  gw
end

# MOVE: partition into preferred + rest, then concat
preferred, rest = Input.payment_gateways.partition { |gw| gw.name == "Shop Pay" }
Output.payment_gateways = preferred + rest

Detecting which is happening requires recognizing the structure, not just the method name. map can do other things; in payment Scripts it's specifically the conditional gw.name = inside the block that means "rename." partition only counts as "move" if followed by a concat assignment. Etc.

The good news: in practice, merchants reuse these patterns almost verbatim because they're the canonical Shopify-documented ways to do each operation. So pattern recognition is reasonable. The parser detects all three.

The PCD-redacted-payload trap that took 8 hours

This one isn't about parsing, but it's the most expensive bug I hit while building this app, and it's relevant for anyone building Shopify webhooks.

PayLogic listens for customers/update webhooks to maintain a tag cache (so the payment customization Function can read customer tags at checkout without a round-trip). The webhook payload has a tags field. So I read it, wrote it to a metafield, and shipped.

The bug: the metafield was getting written with empty tags, even for customers who clearly had tags in Shopify admin.

Four hours of debugging:

Hour 1: assumed my webhook handler was buggy. Logged the payload. Tags showed as []. So the handler was getting empty tags. Confused.
Hour 2: assumed it was a serialization issue between Prisma and the JSON metafield value. Wasn't.
Hour 3: assumed Shopify's webhook delivery was buggy. Tested with a different webhook topic — customer fields were similarly empty.
Hour 4: hit on the actual answer. Shopify's Protected Customer Data (PCD) policy redacts customer fields from webhook payloads independently of whether your app has Admin API access to those same fields. Your app might have read_customers scope and full Admin API access, but webhook payloads strip PCD-protected fields by default.

The fix: ignore payload.tags entirely. On webhook receipt, take the customer ID from the payload, query Admin GraphQL with that ID, get the real customer record with the real tags.

// Wrong:
await writeTagCache(payload.customer.id, payload.customer.tags);

// Right:
const customer = await admin.graphql(
  `query GetCustomer($id: ID!) { customer(id: $id) { id tags } }`,
  { variables: { id: `gid://shopify/Customer/${payload.customer.id}` } }
);
await writeTagCache(
  customer.data.customer.id,
  customer.data.customer.tags
);

It's a one-line conceptual fix that took me hours to find because the failure mode — payload looks valid, just empty arrays for the PCD fields — doesn't look like a permissions error. There's no helpful "field redacted" indicator. The fields just look like the customer has no tags.

If you're building Shopify webhooks: never trust PCD-protected fields in webhook payloads. Always re-query Admin GraphQL with the entity ID. That's the lesson.

What patterns merchants actually use

Reading real Scripts showed me what merchants actually do, which is narrower than the universe of what Scripts could do. A handful of patterns cover the bulk:

Hide COD over a threshold — by far the most common single pattern:

if Input.cart.subtotal_price >= Money.new(cents: 30000)
  Input.payment_gateways.delete_if { |gw| gw.name == "Cash on Delivery" }
end

Hide multiple methods for first-time customers:

if Input.customer.orders_count.zero?
  Input.payment_gateways.delete_if { |gw|
    ["Cash on Delivery", "Bank Deposit"].include?(gw.name)
  }
end

Country-gated hides (very common in international stores):

if Input.cart.shipping_address.country_code == "BR"
  Input.payment_gateways.delete_if { |gw| gw.name == "PayPal" }
end

Tag-driven hides (B2B / wholesale flows):

if Input.customer && Input.customer.tags.include?("wholesale")
  Input.payment_gateways.delete_if { |gw|
    ["Credit Card", "Shop Pay"].include?(gw.name)
  }
end

Renames for friendlier labels (less common, but recurring):

Output.payment_gateways = Input.payment_gateways.map do |gw|
  gw.name = "Pay on Delivery" if gw.name == "Cash on Delivery"
  gw
end

These five patterns cover maybe 80% of the payment-customization Scripts I've seen. If you're migrating manually, prioritize these in your Function and don't get distracted optimizing for edge cases that may never appear.

What doesn't translate

Some Script patterns don't have a clean Functions equivalent, and the parser flags them as warnings rather than silently dropping them:

Stateful logic like "this discount can only be applied once per customer per session." Functions are stateless — they evaluate the current cart and return operations. Per-customer or per-session state has to live in your app's database, not in the Function.
External HTTP calls for fraud checks, inventory lookups, etc. Functions can't make outbound HTTP. Pre-compute the data into a metafield via webhooks, then read the metafield from the Function input.
Tax line modifications. Functions can't modify tax lines directly. Discount lines yes, tax lines no.
Substring matching on payment names (gw.name.downcase.include?("cash")). Functions match exact names. The parser translates these to approximate exact-name matches with a warning.
Deeply nested compound logic that doesn't fit a single AND or OR pass. A && (B || C) requires manual rule decomposition.

For these, the converter outputs a warning explaining what was skipped so the merchant knows what they'd need to rebuild manually. I chose this over silently translating to "close enough" rules. Close-enough silently-modified payment logic is exactly the wrong thing to ship at checkout.

The takeaway

Three things I'd tell my past self:

The deadline (June 30, 2026) is real and tight. If you're a merchant or building for merchants, don't underestimate how many stores haven't started.
Most Scripts ARE mechanically translatable. The patterns above cover most of what real merchants do.
What doesn't translate is worse than you'd guess. Stateful, external-API, and tax-line-modifying Scripts are common enough to matter, and silently-wrong translation is worse than no translation. Be explicit about limits.

The converter is at paylogic.dev/scripts-converter — no signup, runs entirely client-side. Try it on your own Script if you have one running.

If you're another Shopify Functions / app dev who's been parsing Scripts (or running into PCD quirks, or anything else in this space) — I'd love to compare notes. The "real Scripts in the wild" data set is small enough right now that anything you've seen is useful.

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 — Tue, 26 May 2026 14:36:05 +0000

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:

The Function reads tags from a metafield (paylogic.tags-cache), not the live tag field. We cache via webhook.
The customers/update webhook payload contains a tags field. I trusted it.
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.
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.