Migrating from Shopify Scripts to Functions: the payment customization survival guide

If you sell on Shopify Plus and you’ve ever written a Script that hides a payment method, charges a Cash on Delivery fee, or reorders the checkout — you have a hard deadline coming up that will break your store if you ignore it.

June 30, 2026. That’s when Shopify pulls the plug on the Scripts runtime entirely.

It’s already half-broken. Since April 15, 2026, you haven’t been able to edit an existing Script. You can still see them in the admin, and the ones already deployed are still running at checkout — for now. But on June 30, the runtime shuts down, and any Script you haven’t migrated will silently stop firing. Your COD will be back on. Your high-risk customers will be allowed to “pay later.” Your B2B checkout flow will revert to showing every payment method to every customer.

If you’re reading this and thinking we have a Script doing X, what do we do? — that’s the right question. Let’s go through it.

What Shopify is replacing Scripts with

Shopify’s official replacement is called Functions. The relevant one for payment rules is the Payment Customization Function API.

The honest engineering summary: Functions are better than Scripts. They run as compiled WebAssembly at the same edge as the checkout itself, so they’re faster, they can’t time out, and they can’t crash the checkout session.

The honest merchant summary: writing one from scratch is a multi-week project involving Rust, the Shopify CLI, GraphQL metafield schemas, and a Shopify Function deployment pipeline. Not realistic for a merchant who needs to keep selling.

So your two paths are:

1. Hire a developer to build a custom Function for your store
2. Install an app that exposes payment rules through a UI and runs the Function under the hood

This guide covers path 2, because it’s what 95% of merchants are going to do — including most of the ones currently paying $200/hr to a developer to build path 1.

Step 1: catalog your existing Scripts

Before you migrate anything, find out what you’re actually running.

In Shopify admin: Settings → Apps and sales channels → Shopify Scripts. You’ll see a list of scripts. Open each one and look at the title and the top comment block.

For each Script, write down:

• The Script’s name
• What it does in one sentence (“hides Cash on Delivery for cart totals over $300”)
• The data it depends on (cart total? customer tag? product tag? shipping country?)
• Whether it’s currently active

Don’t try to read the Ruby. The intent matters more than the implementation. If you wrote it years ago and can’t remember what it does, ask the dev who wrote it, or look at the Shopify Helpdesk ticket that triggered it. (If neither — Script titles are usually descriptive enough.)

You’ll find that 90% of Scripts in the wild fall into a handful of patterns:

• Hide a payment method when cart total is above (or below) a threshold
• Hide a payment method for specific shipping countries
• Hide Cash on Delivery for customers without a trusted tag
• Hide Cash on Delivery on the first order from a new customer
• Show a wholesale-only payment method to customers tagged b2b
• Rename a payment method to include a surcharge (“Cash on Delivery — $5 handling”)
• Reorder payment methods so the cheapest-to-process one is on top

If your Scripts do something genuinely custom — a multi-step calculation, an external API call, a per-product price override — you’re in the 5%, and you’ll need a custom Function. The other 95% can be replicated in any of the payment customization apps on the App Store using rule templates.

Step 2: pick your replacement

There are about half a dozen payment customization apps on the Shopify App Store. The questions you should ask:

Is it Functions-native, or a workaround?

The older apps in this space — built before Functions existed — use a clever hack involving the carrier-service callback. They work, but they introduce checkout latency (your store has to wait for their server to respond on every page load) and they don’t carry the Built-for-Shopify badge. Avoid them if you can.

Functions-native apps run the same way Shopify’s own checkout runs — at the edge, in WebAssembly, no third-party network call. The App Store listing will say “Built for Shopify” if it’s Functions-native and meets the quality bar.

Does it cover your Script patterns?

Make sure the app’s rule templates cover whatever your Scripts do. Most apps cover cart-total, country, and tag conditions. Fewer cover first-time customer or item count. Almost none cover order risk.

What’s it going to cost?

Most apps in this category are $5-$20/month for one or two stores’ worth of rules. Some price by GMV, which we think is dumb — your payment customization rules don’t get more expensive to run as your store grows, and the app shouldn’t either.

Does it offer a free dev tier?

If you build on a Shopify Partner development store while testing, you should not be paying. Apps that don’t offer a free dev tier are leaving that cost on you for no good reason.

Step 3: install, test, deploy

The migration itself is the easy part if you’ve done steps 1 and 2 right.

1. Install the replacement app on a dev store first. Don’t migrate directly on your live store. Clone your live store into a dev store (Shopify Partner Dashboard → Stores → Create development store → Transfer settings from existing store) and test there.
2. Rebuild each Script as a rule. Open your replacement app and walk through the rule wizard for each Script you catalogued. Save each one, and place a real test order on the dev store to confirm the right payment methods show up.
3. Disable the old Script on the dev store and re-test. This catches the case where you accidentally kept depending on the Script during testing.
4. Repeat on production. With the dev store proven, install the same app on your live store, rebuild the same rules, and run end-to-end checkout tests. (Pro tip: use Shopify’s “Bogus Gateway” test orders for final live-store validation — they don’t charge a card but exercise the real checkout pipeline.)
5. Watch for 7 days. Don’t disable the old Scripts immediately. Run them both in parallel for a week. If the rule app is configured correctly, the two will produce identical checkouts and the Script becomes a no-op. After 7 days of confidence, disable the Script.

The whole process is usually 1-3 hours of work, not the multi-day project people fear when they first hear “migration.”

Step 4: catch the things Scripts couldn’t do

Here’s the part that’s actually fun.

Once you’ve moved to Functions, you have access to data that Scripts never exposed. The most valuable one for merchants in MENA, SEA, and LATAM markets is order risk signals.

If you sell COD, you already know the pain: high-risk orders become return-to-origin freight bills. The customer never picks up, the order bounces, you eat the shipping both ways. Industry-wide RTO rates on COD in those markets sit at 25-35%.

Scripts couldn’t see order risk. Functions can. Some Functions-native apps (disclosure: PayLogic is one of them) expose Shopify’s built-in order risk model as a rule condition — meaning you can write a rule like:

Hide Cash on Delivery when the customer has prior orders flagged HIGH or MEDIUM risk by Shopify.

This is the rule that pays for the app. A 5-percentage-point drop in RTO on a store doing $50k/mo of COD is more revenue back to the merchant than the app costs in five years.

If your store doesn’t sell COD, the equivalent leverage is hiding “buy now, pay later” methods on high-risk orders, or hiding wire-transfer prepayments on customers without verified order history.

Step 5: what to do if you’re past the deadline and your checkout breaks

If you’re reading this on July 1, 2026 or later and your Scripts have stopped firing — don’t panic.

1. Your checkout still works. All payment methods will be visible to all customers, but Shopify itself is still processing orders normally.
2. Install a payment customization app today. Most stores can have their rules rebuilt and live within the same business day.
3. Audit recent orders for refunds you would have prevented with the Script. (For example, COD orders that should have been blocked.) The damage is usually small if you act within a few days.

The cost of the deadline isn’t catastrophic — it’s a quiet, expensive drift away from the rules you used to enforce. Most merchants don’t notice for weeks. By then, you’ve absorbed dozens of edge-case orders your old Script would have stopped.

A word about pricing

Most Scripts in production are doing $1-50 per month of work for the merchant — they’re stopping the occasional bad order, not transforming the business. If a payment customization app costs $20/month, the math gets thin fast.

We launched PayLogic at $1.99/month for the Starter tier because we looked at what most stores actually need (1-3 rules) and what most merchants are willing to pay (less than a fancy coffee). The full unlimited tier is $4.99, and the risk-gated COD feature — the one that pays for itself many times over in COD markets — is $9.99.

Compare that to the legacy apps in the space at $9-$25/month for substantially similar feature sets, with worse architecture.

Quick checklist before you close this tab

• List your existing Scripts (admin → Apps → Shopify Scripts)
• Identify which fall into the standard patterns (most will)
• Install a Functions-native payment customization app on a dev store
• Rebuild your rules in the app
• Test with bogus gateway orders
• Deploy to production
• Run in parallel with old Scripts for 7 days
• Disable old Scripts
• Consider what new rules Functions makes possible (risk-gating!)

Whichever app you pick, do it now, not in June. The migration assistance queues at every app in this space are going to be at their longest in the last 3 weeks before the deadline, and your store deserves better than a panicked Sunday-night cutover.