A customer's card gets replaced by their bank. A renewal fails. You open the contract, click into the payment method, and email them a link to update it. Two clicks, no support ticket.

Now the same store imports 400 subscribers from another platform, or takes a phone order from a wholesale buyer who wants to be billed for the balance later. There is no card on file. You need the customer to put one there.

Look for that button and you will not find it.

What the admin actually does

The action exists, and the Shopify Help Center is unusually precise about where it lives. Under editing a customer's subscription payment information, the instruction reads: "For the relevant saved card, click ⋯ > Send link to update card."

For the relevant saved card. The action hangs off a card that already exists. The contract-level version in the Shopify Subscriptions app offers the same three choices and the same precondition — email a link to update, "Replace card," or "Delete card." Every one of them operates on a saved payment method.

Under it sits the API this button calls. customerPaymentMethodSendUpdateEmail takes exactly one required argument: customerPaymentMethodId: ID!. Its own documentation describes the use case as a card that "is expiring or has been declined." It cannot represent the absence of a card, because the thing it identifies is the card.

So the merchant with no card on file is left with the manual path: type the customer's card number into Shopify yourself. On draft orders that step reads "Enter the customer's billing and credit card information," and Shopify's own help page attaches two conditions to it. Manual credit card payment on a draft order is available "only through Shopify Payments" and requires a completed Shopify Payments verification. And if you take payments through another provider, Shopify tells you to "check with your provider whether handling customer information in this way affects PCI compliance requirements."

The other native option, sending a draft order invoice, is documented as producing a payment rather than a saved card. The Help Center describes invoices as "secure checkout links for customers to complete payment online," and nothing on that page describes the invoice flow as vaulting a payment method you can bill again later.

What shipped on September 3, 2026

paymentInstrumentSendAddEmail is the mutation for the case the button doesn't cover. Shopify's reference describes it as sending "a secure link to add a new payment instrument (e.g., credit card) for a specific resource such as a subscription, order, or draft order," for exactly the situation above — "after a payment method was revoked or when setting up payment for a new subscription contract."

Two design decisions matter more than the feature itself.

The link is scoped to one resource. You name the resource in a required mandate argument, and the changelog states the consequence plainly: the link "scopes the customer to that specific resource, so they don't need to sign in to their account," and "a link sent for one contract can't be used against another." No sign-in is the operative half. Shopify's documented route for a customer to manage their own payment methods is the customer account — the Help Center describes customers signing in to their account to "manage their payment methods and shipping address." This link skips that.

The resource types are fixed at three. PaymentInstrumentMandateResourceType has exactly the values SUBSCRIPTIONS, ORDERS, and DRAFT_ORDERS. There is no customer-level option — you cannot ask a customer to put a card on file in the abstract, only against something that already exists in your store.

It is not in the stable API version yet

The changelog says the mutation "is available in the GraphQL Admin API as of version 2026-10." That sentence is accurate and reads as available now. It isn't, in the sense that matters for production.

Open the reference at the /latest/ path and the page returns "This API version is not supported." /latest/ resolves to 2026-07, and the mutation does not exist there. The 2026-10 page renders fine, labelled release candidate.

Shopify's versioning policy defines that label without hedging. A release candidate "may include backwards-incompatible changes, so not recommended for production." New versions ship "at 5pm UTC on the first day of the quarter," which puts 2026-10 into stable on October 1, 2026.

So there is a window — roughly September 3 to October 1 — where the capability is documented, testable, and not something a responsible app will run against your live store. If you asked your subscription vendor about this in September and got "it's not in a stable version yet," that was the correct answer, not a brush-off.

The resourceId trap

This is the detail most likely to cost someone an afternoon.

Almost every Shopify Admin API mutation identifies a record with a Global ID — gid://shopify/Customer/544365967. The sibling mutation does: customerPaymentMethodId: ID!, and its documented example passes gid://shopify/CustomerPaymentMethod/b7cc6e3267aace169e516ed48be72dff.

The new one does not. PaymentInstrumentMandateInput declares resourceId: String! — a string, not an ID. The changelog spells out what happens if you reach for the familiar format: it "takes the numeric ID of that subscription contract, order, or draft order, not the GID. A GID comes back as a not found userError."

A not-found error, not a type error. Pass a perfectly valid GID for a contract that exists and Shopify tells you the resource doesn't exist. Two sibling mutations, both about payment methods, both emailing a link, using opposite identifier conventions — and the failure mode points at the wrong problem.

Shopify is at least consistent with itself in this corner of the product. The subscription contract CSV documents customer_payment_method_id as "a unique alphanumeric code. For example, 24e8c839c47ef47d30ad28346d130e74" — the bare token again, no GID wrapper.

Four of the six email fields do nothing

The optional email argument takes an EmailInput. The schema on the reference page lists six fields: bcc, body, customMessage, from, subject, to.

The mutation reads two of them. The argument description states it directly: "Only the 'from' and 'bcc' fields are accepted for input." from overrides the sender, defaulting to your store's customer contact email; bcc copies other addresses.

The catch is that Shopify's own auto-generated example on that page populates all six, including "body": "<your-body>", "subject": "<your-subject>", and "to": "<your-to>". Copy that example, fill in a subject line and body, and the call succeeds, returns an empty userErrors array, and sends the default email. Nothing tells you the copy you wrote was discarded.

For merchants that means one thing: you do not get to write this email. Whatever your app's interface implies, the only customer-visible lever is the sender address.

Permissions are tighter than the button's

The reference page for the new mutation carries a longer access requirement than its sibling. customerPaymentMethodSendUpdateEmail requires write_customers. paymentInstrumentSendAddEmail requires write_customers and — quoting the page — "The user must have permission to create and edit customers, and read access to the mandate resource."

The changelog mentions the create-and-edit-customers permission but not the read access to the mandate resource. Both conditions are staff-level, so a store that restricts which staff can edit customers has staff who will see this fail. And if your app doesn't already request write_customers, adopting the mutation means a new scope prompt you have to approve.

What it does not fix

The migration case — the one that sends most merchants looking for this button — is still blocked upstream.

To import subscription contracts into Shopify Subscriptions you need a CSV, and the column specification states that "all columns must be added to the CSV file to import correctly, and all fields are required unless otherwise noted." customer_payment_method_id is one of those columns and is not marked optional. You cannot import a contract and then ask for the card, because the import will not accept a contract without one.

The same page adds a second wall: "If your third-party subscription app isn't Shopify Checkout integrated, then you can't import your contracts."

The new mutation helps where a resource can exist first and be paid for second — a contract your app creates through the API, a draft order you build for a wholesale buyer, an order whose payment method was revoked. It does not help you carry a spreadsheet of subscribers across from a platform whose tokens don't travel.

The first-party app hasn't picked it up

Shopify Subscriptions is unusual among apps in that you can check this yourself. Its App Store listing names the source at github.com/Shopify/subscriptions-reference-app.

Source: Shopify App Store (Shopify Subscriptions), retrieved September 17, 2026

The repository implements the old mutation in the obvious places — a CustomerPaymentMethodSendUpdateEmailMutation file, a SendPaymentMethodUpdateEmailService, a modal component for the flow. A search for paymentInstrumentSendAddEmail across the checked-out repository returns nothing at all. The most recent commit on the public repository is dated January 2, 2026, so this is evidence about the published reference app rather than proof about the app running in your admin — but it is the only first-party implementation anyone outside Shopify can read, and the new mutation is not in it.

Worth noting while you are there: the reference app pins api_version = "unstable". Shopify's versioning page describes unstable as being for "early testing only," where "features can be added or removed at any time with no guarantee of release."

The app itself is free, rated 3.7 from 818 reviews, and developed by Shopify.

What to ask the app you already run

The mutation is an Admin API capability. Nothing about it creates a button in your admin, so whether you can use it depends entirely on the app managing the resource.

Source: Shopify App Store (Appstle℠ Subscriptions App), retrieved September 17, 2026

It also helps to know what you are currently paying for. The two largest third-party subscription apps both sell a version of this capability, and both put it behind the first paid tier.

Appstle℠ Subscriptions App, from Appstle Inc., carries the Built for Shopify badge and is rated 5.0 from 8,721 reviews. Its FREE plan lists a "Shopify Native Customer Portal" and caps you at "Upto $500 in subscriptions per month." Its STARTER plan, $10/month or $96/year, is where "Manual Subscription Creation" and "Customer Portal Passwordless Login" appear.

Seal Subscriptions App is Built for Shopify and rated 4.9 from 3,086 reviews. Its free plan allows "Unlimited revenue, 50 subscriptions." Its SUPERSALE plan, $5.95/month or $57.12/year, is the tier that lists "Passwordless customer portal," and the listing's own feature copy advertises that customers "can easily access subscriptions (abonnements) with magic links."

Shopify Subscriptions is free, and as shown above has no equivalent action in its documented admin flow.

So the pattern is consistent: creating a contract by hand, and letting a customer supply payment details without a password, are paid features today. A native, resource-scoped, no-sign-in link changes what those features are worth — but only once an app calls it.

Whether any of these apps has adopted paymentInstrumentSendAddEmail is not stated on their App Store listings, and for a mutation this new that is the expected answer rather than a mark against them. Three questions get you a real one:

Which API version does the app target? Anything on 2026-07 or earlier cannot call this mutation at all — Shopify's own note is that those apps "are unaffected and see no change in behavior." This is a yes-or-no gate, not a feature negotiation.

Does the app already hold write_customers? If not, adoption means a scope change and a fresh approval from you. That is worth knowing before it appears as a permissions prompt you weren't expecting.

When you send a request-a-card email today, what is actually sending it? If the answer is the app's own email and its own hosted portal — the passwordless login and magic links both listings advertise — then you have a flow that works now, and one whose behaviour on migration is a separate question worth asking. If the answer is Shopify, expect the customer to receive Shopify's default copy, because from and bcc are the only fields the mutation reads.

Where this actually lands

Shopify closed a real gap here, and closed it carefully. A link that cannot be used against any resource other than the one it was sent for is a tighter design than a general-purpose portal login, and the three resource types cover the cases merchants keep hitting.

What it shipped as is an API, one quarter ahead of stable, with an identifier convention that contradicts the rest of the schema and an input object that accepts four fields it throws away. None of that is fatal. All of it means the gap between "Shopify supports this" and "you can do this in your admin" is wider than the changelog makes it sound.

Check your API version. Then ask your app.

Sources

• New paymentInstrumentSendAddEmail mutation emails customers a link to add a payment method for a subscription, order, or draft order — Shopify developer changelog, September 3, 2026
• paymentInstrumentSendAddEmail, PaymentInstrumentMandateInput, PaymentInstrumentMandateResourceType — GraphQL Admin API 2026-10
• customerPaymentMethodSendUpdateEmail — GraphQL Admin API 2026-07
• About Shopify API versioning — shopify.dev
• Managing customers, Managing subscription contracts, Shopify Subscriptions, Getting paid for draft orders, Draft orders and invoices, Importing and exporting a contract CSV — Shopify Help Center
• Shopify/subscriptions-reference-app — GitHub, commit 575a825 dated January 2, 2026
• Shopify Subscriptions, Appstle℠ Subscriptions App, Seal Subscriptions App — Shopify App Store, retrieved September 17, 2026