Starting with API version 2026-07, the payment method identifier field becomes required in the Stripe, Authorize.net, and Braintree inputs. It was optional in the schema, but actually needed for payment processing all along. This change aligns the schema with reality.
customerPaymentMethodRemoteCreate when using the mutation
Stripe / Authorize.net / Braintree in inputs forthe payment method identifier field becomes required.Even without passing the identifier, schema validation passed. But that payment method couldn't be used for payment processing, so it was created in a non-functional state.
Without the identifier, the mutation is rejected at the validation stage. This prevents non-functional payment methods from being silently created in the first place.
Three fields become required, one per gateway. You only need to check the row for the gateway you're integrating with.
| Gateway | Input type | Field becoming required |
|---|---|---|
| Stripe | RemoteStripePaymentMethodInput |
paymentMethodId Required |
| Authorize.net | RemoteAuthorizeNetCustomerPaymentProfileInput |
customerPaymentProfileId Required |
| Braintree | RemoteBraintreePaymentMethodInput |
paymentMethodToken Required |
paymentMethodIdcustomerPaymentProfileIdpaymentMethodTokenThere was a gap where the field was "optional in the schema" but "required at runtime." This change closes that gap.
Current state customerPaymentMethodRemoteCreate If you are already passing the relevant identifier field when calling the mutation,no changes are required. You can safely bump to 2026-07 as is.
Before adopting 2026-07, update your integration to include the identifier corresponding to your gateway in the input. If you bump to 2026-07 without updating, the mutation will be rejected.
customerPaymentMethodRemoteCreate Stripe / Authorize.net / Braintree remote inputsintegrations that use the above. Effects on other creation paths, and how payment methods previously created without an identifier are handled, are not covered in this article Not specified.The requirement takes effect on requests targeting 2026-07 or later. While you're on earlier versions, behavior is unchanged (the field remains optional in the schema). The version upgrade is the inflection point.
Stripe's paymentMethodId, Authorize.net's customerPaymentProfileId, and Braintree's paymentMethodToken. You only need to check the value for the gateway you actually use.
A field that was optional in the schema becomes non-null (required). If you use code generation or type checking, regenerating the artifacts lets you catch missing values at compile time.
Any integration that doesn't pass the identifier will have its mutation rejected once it moves to 2026-07.Before adopting the version,it's safer to verify in a test environment that the required field is populated.
Previously, creation itself succeeded even without an identifier, andyou only discovered it was unusable at payment processing time— a delayed failure. With the requirement, the create request itself fails, so you catch the problem before users get stuck at checkout. This benefits both data quality and early failure detection.
customerPaymentMethodRemoteCreate Enumerate all call sites of, and add to your checklist whether the identifier is passed for Stripe/Authorize.net/Braintree respectively. Bump your test environment to 2026-07 and verify.paymentMethodId / customerPaymentProfileId / paymentMethodToken). You can mechanically pick up the call sites with grep.customerPaymentMethodRemoteCreate the payment method identifier becomes required.