Admin GraphQL API / 2026-04

Even without a payment method,
you can now create subscription contracts

Starting from the API 2026-04 release candidate (RC), the contract creation mutation's paymentMethodId is no longer required. You can migrate contract data even when a payment method is missing or expired.

On this page
  1. What's actually changing (understand in 30 seconds)
  2. How it works: the contract migration flow
  3. Affected mutations
  4. Before vs. 2026-04 comparison
  5. Requirements and caveats
  6. 5 key points for developers
  7. 3 business use cases you can apply
  8. One-line summary for pitches

1What's actually changing

Previously, to create a subscription contract via the API,a valid payment method (paymentMethodId) was required.
Starting from the 2026-04 release candidate (RC), that field is no longer required, so you can create and migrate contract data even when a payment method is missing or expired.

Before: can't create without a payment method

paymentMethodId was a required field. Contracts with expired or missing cards couldn't be created via the API, and migrations stalled.

2026-04: can be created without a payment method

paymentMethodId becomes optional. You can create contracts even when the payment method is missing or expired, allowing migrations to complete.

2How it works: the contract migration flow

Source contract data Customer / product / cycle Payment method: expired/missing Legacy apps, external platforms, etc. Contract creation mutation subscriptionContractCreate subscriptionContractAtomicCreate paymentMethodId can be omitted On Shopify, the contract is created Re-registration of the payment method *Specific steps are not described in this article
The aim of this change is to eliminate the situation where "migrations get stuck due to the presence or absence of a payment method". It is focused on a single point: allowing you to first create the contract container, even if the payment method is missing or expired.
How to reattach a payment method after creation, and the conditions under which billing runs,are not described in this article. When implementing, check the docs at the bottom (How to build a subscription contract).

3Target mutations

This time, paymentMethodId the two contract-creation mutations below no longer require it.

Target

subscriptionContractCreate

The standard mutation for creating a subscription contract. Specifying the payment method ID is now optional.

Target

subscriptionContractAtomicCreate

A mutation that atomically creates a contract along with its lines and other components in one call. The payment method ID is also optional here.

Impacts on mutations other than these two (contract update mutations, payment method replacement mutations, etc.) are not described in this article.

4Comparison: Before vs. 2026-04

ItemBeforeAPI 2026-04(RC)
paymentMethodId Required Without specifying it, you cannot create a contract Optional You can create a contract even if omitted
Contracts with an expired/absent payment method Cannot be created Can be created
Migration use case Migration stops unless valid cards are in place You can migrate contract data as-is
Target mutations — subscriptionContractCreate / subscriptionContractAtomicCreate
Applicable version — API 2026-04 release candidate (RC)

5Usage conditions and caveats

2026-04

API version 2026-04 (RC)

This behavior is provided in the release candidate (RC) version. You need to specify 2026-04 in your request. The official GA timing and whether it will be backported to earlier versions are not described.

Impact on billing/authorization is not described

How the next billing is handled for a contract with no payment method, and when a payment method will be required, are not described in this article. Verification against the docs and behavior testing is required before production use.

65 points engineers should keep in mind

optional

1. The only change is required vs. optional

paymentMethodId is an input schema change where it went from required to optional. No new fields or new mutations have been added.

2. The main purpose is "migration"

The article explicitly scopes this to migrating contracts whose payment methods are missing or expired. It is not a feature for changing the normal flow of creating new contracts.

2 mut.

3. Scope: two mutations

subscriptionContractCreate and subscriptionContractAtomicCreate both. It also works for bulk migration scripts that use atomic creation.

RC

4. Note that this is a Release Candidate

2026-04 is a release candidate. Before adopting it in production, account for the risk of spec changes and pin the API version in your requests to 2026-04.

5. Post-contract-creation payment method handling must be designed separately

How and when to re-attach a payment method to a contract created without one, and how billing behaves in the meantime, arenot documentedin this article. Work out the re-attach procedure and billing-resumption flow against the docs (How to build subscription contracts) and hands-on verification.

7Three practical use cases

Shopify
USE CASE 1

Bulk migration from an external subscription platform to native Shopify contracts

Problem
When migrating from a legacy subscription app or external platform, some customers' cards were expired or missing. Because a payment method used to be required to create a contract, migration would stall.
Approach
On API 2026-04, use subscriptionContractAtomicCreate and omitpaymentMethodId to migrate only the contract data first.
Outcome
Contracts can be migrated regardless of whether a payment method exists, aligning customer, cycle, and product information on the Shopify side.
Technical notes
The article does not document the re-registration procedure for payment methods. The re-attach and billing-resumption flow after migration must be designed separately.
USE CASE 2

"Data rescue" for existing contracts saddled with expired cards

Problem
Contracts whose billing had stopped due to expired cards were being left out of migration and rebuild efforts, ending up dormant.
Approach
By creating contracts without a payment method, even contracts with expired cards can first be reproduced on Shopify. Then design a path that prompts customers to re-register their cards.
Outcome
Dormant contracts can be brought onto the ledger without losses, securing a target population for follow-ups aimed at revival (resumed billing).
Technical notes
Billing behavior for contracts without a payment method is not documented. How billing resumes after re-registration needs to be verified.
Contract Card registration
USE CASE 3

Phased onboarding design: "contract first, payment later"

Problem
In migration and signup flows, the constraint that "a contract can't be created until a payment method is in place" was a bottleneck on the overall schedule of migration projects.
Approach
Create the contract first to finalize the ledger, and separate payment method collection into a campaign / customer follow-up phase.
Outcome
Migration work and payment information collection can be decoupled, letting data migration finish first and keep the project moving forward.
Technical notes
The article does not describe the procedure for attaching a payment method later. Design with reference to the docs (How to build subscription contracts).

8One-line summary you can use in pitches

"Starting with API 2026-04, the payment method ID on the contract creation mutation becomes optional.
, so subscription contracts can be migrated even when the payment method is expired or absent, removing one of the biggest bottlenecks in migration projects."