TL;DR — Shopify Scripts now has a hard shutoff (April 15 for new installs, June 30 for everything else), Claude pushed chat-history memory to the free tier, and Admin API 2026-07 makes
paymentMethodIdrequired oncustomerPaymentMethodRemoteCreate. Two deprecation windows and one rising floor.
The theme
Three updates, one shape: platforms are moving their minimums and the grace period is shorter than it looks. Shopify Scripts, a Plus-era surface that has been on life support for years, finally has real dates on the calendar — and the first one is six weeks out. Admin API 2026-07 quietly makes a field required that used to be optional on one of the mutations every subscription app in the ecosystem calls. And Anthropic pushed chat-history memory down to free Claude users, which resets what "normal" feels like for anyone building an AI product on top.
The through-line is that you don't control the pacing on any of this. Scripts will silently no-op after June 30 whether your Functions port is ready or not. The paymentMethodId field will return REQUIRED_FIELD_MISSING whether you have a SetupIntent flow or not. And the user who just started remembering what Claude knows about them will expect the same from whatever you ship next. The week's work is figuring out which of your systems are on the wrong side of one of these lines and moving them before the platform moves for you.
1. Shopify Scripts Deprecation: Migrate to Functions by April 15 (original)
Overview
Shopify Scripts — the Plus-only Ruby surface for line item, shipping, and payment logic — stops executing on June 30, 2026. The harder date is April 15: after that, no new scripts can be installed at all. Existing scripts keep running through the June cutoff, and then they return as if they were never there. No error, no warning, no log line. Just a silent no-op where your 15% VIP discount used to be.
If you run a Plus store with any Script Editor logic, you have roughly two months to ship a Functions replacement, deploy it to production, and verify it on live traffic. Functions is a better surface in 2026 than Scripts ever was, but the Ruby-to-Wasm port is not copy-paste, and the edge cases are where the revenue leaks.
Technical
The target map is straightforward: line item scripts move to purchase.product-discount.run, shipping scripts to purchase.shipping-discount.run plus a filter target, and payment scripts to purchase.payment-customization.run. Scaffold with shopify app generate extension --type=function, pin api_version = "2026-04" in shopify.extension.toml, build, deploy. The function existing is not enough — a discount class created via discountAutomaticAppCreate has to point at it before it runs on the storefront.
Three gotchas the migration docs skip past. First, tag checks are not free. In Scripts you got the full tag array; in Functions you pre-declare the tags you care about via hasAnyTag(tags: ["vip"]) in the input query and get a boolean back. Any logic that branched on tag combinations becomes an explicit input boolean per combination. Second, discount stacking changed. Scripts ran in one pass with full control over prices; Functions stack with code and automatic discounts, and the platform decides allocation via FIRST or MAXIMUM. Code that relied on running last and overriding everything needs a new model. Third, payment customizations can hide and move gateways but cannot rename them. Renaming logic moves into a checkout UI extension.
Takeaway
Inventory your Scripts this week and write the input query before you touch any Rust. For each script, port the logic, deploy to a dev store, and run a parity diff — log every discount allocation from the old Script against the same carts running through the Function and compare. I have seen migrations ship with a 3% revenue gap because the Function rounded quantity-based discounts differently. Settle that before the June 30 wall, not after, because after it there is no fallback surface to roll back to.
2. Claude Memory for Free Users: The Floor Just Got Higher (original)
Overview
On March 2, Anthropic made memory from chat history available to every Claude user, including the free tier. One sentence in the release notes, much bigger in practice. Memory is the kind of feature that usually lives behind a paywall because it is expensive to run and an obvious upsell hook. Pushing it to free is a statement about where Anthropic thinks the floor for an AI assistant should sit in 2026. If you build on Claude or compete with it, the minimum viable assistant now remembers its user.
Technical
"Memory from chat history" is not a raw dump of past conversations. Claude scans your history, extracts durable facts — projects, people you mention, preferences you have stated — and curates them into a profile that grows over time. The implementation reads as two layers: a synchronous fresh-signals layer pulling from recent conversations, and a slower long-term profile that distills patterns across weeks. Both contribute context when you open a new chat. Users see a memory panel in settings, can edit or delete individual entries, can ask Claude to forget a topic, and can turn the whole thing off. Privacy controls are surfaced, not buried.
Four things matter for builders. Memory is a product feature, not an API primitive — there is no endpoint, no header, no way to read or write Claude's memory from your own code. If you build on the API, you still bring your own vector store or key-value layer. What changes is user expectation: people who use Claude.ai daily are now used to an assistant that knows them, and your product has to clear that bar. Cross-conversation context is the wedge — not having to re-explain yourself is the single biggest UX shift, and it compounds the more often someone uses the product. Memory for connected tools like Drive stays paid, and a programmatic memory API does not exist on any tier. That API gap is the one to plan around.
Takeaway
If you ship anything where users have repeated conversations with a model, audit your memory story this week. The new floor is "the model remembers me without me having to ask." If your product does not do that, it will start to feel regressive within a month. And if you build on the Claude API, treat this as one more reminder that the consumer surface is pulling ahead of the API surface — the gap between what Claude.ai does and what your app does is the gap you have to close yourself.
3. customerPaymentMethodRemoteCreate Now Requires payment_method_id (original)
Overview
Admin API 2026-07 makes paymentMethodId a required input on customerPaymentMethodRemoteCreate for Stripe, Authorize.net, and Braintree. The mutation used to accept a customer-only shape and let the gateway guess the default card to vault; now it returns userErrors with code: REQUIRED_FIELD_MISSING when the identifier is missing. This is the exact kind of change that does not show up in any roundup and quietly breaks your subscription app on the version bump. If your vaulting code has been riding the customer-only fallback, this is a breaking change with your name on it.
Technical
The old shape passed customerId and a gateway-specific remoteReference and let Shopify pick whichever card Stripe had flagged as default. In 2026-07 every gateway needs its own explicit identifier: stripePaymentMethod.paymentMethodId (pm_...), authorizeNetCustomerPaymentProfile.customerPaymentProfileId, and braintreePaymentMethod.token. For Stripe, the canonical way to get the ID is a SetupIntent: create it on the backend with usage: 'off_session', return the client secret, let the buyer confirm in Stripe Elements, catch the payment_method.attached webhook, and forward the pm_... to Shopify. If you were previously vaulting against Stripe's "customer default payment method" abstraction, you have to stop — Stripe customers can have multiple payment methods and Shopify is no longer willing to guess which one you meant.
While you are in that code path, two adjacent 2026-04 changes are worth picking up in the same sweep. subscriptionContractCreate now accepts contracts without a payment method attached, and subscriptionBillingAttemptCreate takes a paymentProcessingPolicy: ALLOW_UNPAID_ORDERS option. Together those let you create a contract before the buyer has vaulted a card and bill against it later. Migrating customerPaymentMethodRemoteCreate in isolation is fine, but if you are already in that file, model the contract-first / payment-method-second flow and save yourself a second migration in a few months.
Takeaway
Grep for customerPaymentMethodRemoteCreate this week. Anywhere you are passing customerId without paymentMethodId, fix it before the Admin API version bump. For Stripe, plumb the pm_... through from the SetupIntent confirm path. Add a unit test that asserts paymentMethodId is present in the mutation variables — this is exactly the kind of change a passing build will hide until production traffic hits it and a vault call returns null.
Original sources
- Shopify Scripts Deprecation: Migrate to Functions by April 15 — originally published 2026-02-23
- Claude Memory for Free Users: The Floor Just Got Higher — originally published 2026-03-02
- customerPaymentMethodRemoteCreate Now Requires payment_method_id — originally published 2026-03-05
