Shopify

Card deposit endpoint now requires mTLS certificate

Shopify's card-deposit endpoint now requires a Shopify-issued mTLS client certificate. Apps that store cardholder data with the customerPaymentMethodCreditCardCreate and customerPaymentMethodCreditCardUpdate GraphQL Admin API mutations must first deposit that data at Shopify's /sessions card-deposit endpoint to receive a session identifier. That deposit call must present a Shopify-issued certificate by October 15, 2026. This is a required change: after enforcement begins, deposit requests will be required to have a valid certificate. If your app deposits cardholder data, you must update. What changed The card-deposit endpoint at https://checkout-mtls.pci.shopifyinc.com/sessions is unchanged. What's new is that every request to it must present a Shopify-issued mTLS client certificate. Previously, requests to this endpoint did not require a client certificate. The GraphQL Admin API vault mutations are unchanged. You continue to call customerPaymentMethodCreditCardCreate and customerPaymentMethodCreditCardUpdate with the session identifier returned by the deposit call, and your GraphQL Admin API OAuth flow is unaffected. customerPaymentMethodRemoteCreate is out of scope. It imports references to payment methods already held at external gateways and deposits no cardholder data to Shopify. Who's affected This applies to apps that deposit cardholder data to Shopify through customerPaymentMethodCreditCardCreate or customerPaymentMethodCreditCardUpdate. Apps that only call customerPaymentMethodRemoteCreate to import payment methods from external gateways such as Stripe, Braintree, Authorize.Net, Adyen, or PayPal are not affected and need to take no action. Why this matters All cardholder-data traffic reaching the deposit endpoint must be attributable to an authenticated caller. Requiring a client certificate lets Shopify verify who is depositing card data ahead of Black Friday and Cyber Monday 2026, and is the prerequisite for rejecting unauthenticated deposit traffic. What to do If your app deposits cardholder data, migrate before October 15, 2026: Confirm whether your app calls customerPaymentMethodCreditCardCreate or customerPaymentMethodCreditCardUpdate. If it only calls customerPaymentMethodRemoteCreate, no action is required. Request a Shopify-issued client certificate at shopify-mtls-partnerships@shopify.com. Include your API client ID and technical point of contact. First certificates are signed manually by Shopify and take a few days, so start early. Present the certificate on your /sessions deposit call, and continue passing the returned session identifier to the vault mutations unchanged. Confirm your deposit traffic now arrives with a valid certificate. Shopify validates the cutover on our side. After your first certificate, rotate it self-serve with Shopify's Certificate Signing Service before the 1-year TTL expires . No Shopify involvement is needed. A missed rotation stops your deposits, so monitor certificate expiry as part of your standard observability. Apps that haven't migrated by October 15, 2026 lose the ability to deposit new cardholder data once the certificate requirement is enforced. Related docs customerPaymentMethodCreditCardCreate reference customerPaymentMethodCreditCardUpdate reference

`productId`, `title`,`variantSku`, and `variantTitle` fields added to `ExchangeLineItem`

Storefront API `@inContext` supports `channelId`

As of Storefront API version 2026-10, the @inContext directive accepts an optional channelId argument. Use channelId to apply a specific sales channel’s context to an entire query, including channel-specific product availability and pricing. Example: query Product($handle: String!, $channelId: ID!) @inContext(channelId: $channelId) { product(handle: $handle) { id title availableForSale priceRange { minVariantPrice { amount currencyCode } } } } Why it's changing The existing @inContext directive lets you set buyer context such as country and language. With channelId, you can now: Target a specific channel (for example, a marketplace or custom sales channel) when fetching products, prices, and availability. Build channel-aware storefronts that show the correct catalog, pricing, and merchandising rules for each channel. Reduce custom logic in your app by relying on the API to apply channel-specific behavior. Requirements Access requirement: You can only pass the ID of a channel created by the API client making the request. Fallback behavior: If you omit channelId, the Storefront API uses the first channel owned by that API client. Pass channelId explicitly when your app owns multiple channels or needs to select a specific channel. Learn more about contextual queries.

Updated App Store requirements: 4.1.2 Use a unique name for your app

Your app's name is what merchants use to discover, identify, and remember your app. We've added requirement 4.1.2, "Use a unique name for your app," to reduce merchant confusion over identical and copycat app names in Shopify’s App Store. We know that changing an app name isn't easy — it affects your brand, your discoverability, and your existing merchants. That's why this requirement establishes the standard now, while enforcement will roll out gradually. Affected apps will be audited in waves and given a designated timeframe to achieve compliance. What's changing This requirement gives Shopify the ability to act on app name violations. Non-compliant apps will be notified and given a defined timeframe to update their names where failure to comply may result in being delisted from the App Store. Enforcement actions will roll out gradually, so affected developers will have time to plan and make changes. What this means for you If you believe your published app violates this policy: Start considering a plan to rename your app to get ahead of enforcement actions. Ensure that your app name starts with your distinctive brand identifier and does not mislead merchants in confusing it with another app, developer, brand, or Shopify product. If you're submitting a new app: Choose a distinct name that represents your own brand. Don't impersonate other apps or mislead merchants with your app name. If your app name is being copied: At this time, we can only accept reports with a valid registered trademark. If your app trademark is being copied, you can submit a report to Shopify.

POS UI Extensions 2026-07 adds discount allocations to bundle components

Starting with POS UI Extensions API version 2026-07, product bundle components in cart line item data include discount allocation details. Apps can access component-level discount allocations from bundle components on a cart line item, for example: shopify.cartLineItem.components?.[0]?.discountAllocations The same LineItem shape is also used in Cart API cart state, so apps that read line items from shopify.cart.current.value.lineItems can access component discount allocations on bundle components there as well. Previously, POS UI Extensions exposed discount allocations on the parent line item through lineItem.discountAllocations, while bundle components exposed component-level tax information but not component-level discount allocations. This made it difficult for apps to calculate component-level discount, tax, reporting, or compliance values for discounted product bundles. This change is additive. Apps using API version 2026-04 or earlier do not need to make any changes. Apps adopting API version 2026-07 can use components[].discountAllocations when working with discounted product bundles. Apps should handle the property being absent or empty when a bundle component has no discount allocations. For more information, see the [Cart Line Item API reference](https://shopify.dev/docs/api/pos-ui-extensions/2026-07-rc/target-apis/contextual-apis/cart-line-item-api#cartlineitemapi- propertydetail-cartlineitem) and the [Cart API current property](https://shopify.dev/docs/api/pos-ui-extensions/2026-07-rc/target-apis/contextual-apis/cart-api#cartapi-propertydetail-curr ent).

POS Extensions now supports a background extension target

The pos.app.ready.data target runs for the entire POS session, letting your extension observe POS events and run background logic without rendering any UI surface. Use it for event observation, data storage, and calling non-visual background APIs. What you need to do Subscribe to Shopify POS events with shopify.addEventListener(): shopify.addEventListener('transactioncomplete', (event) => { console.log('Transaction complete', event); }); Supported events Supported events include: transactioncomplete cashtrackingsessionstart cashtrackingsessioncomplete For comprehensive details and best practices, refer to the app background target documentation.

Identity verification for Shopify Partners starts today

Trust is foundational to the Shopify Partner ecosystem. Partners take actions across Shopify that can directly affect merchants, and merchants need confidence when granting access to their stores. We’re introducing identity verification for partners to help protect merchants, reduce abuse, and make it harder for bad actors to operate, while creating a better experience for legitimate partners. What changed Starting today, Shopify Partners can complete identity verification before requesting collaborator access to merchant stores. Identity verification is optional today and will become mandatory in the coming weeks before sending a new collaborator request. For this launch: Identity verification applies to sending new collaborator requests. Every user in your partner organization sending a new collaboration will need to verify their identity. Identity verification isn’t required just to access collaborator shops where a merchant has already granted access. Verification is completed through Stripe and requires a government-issued photo ID and a selfie or liveness check. We’re starting with collaborator requests because collaborator access is one of the clearest trust moments between merchants and partners. When a merchant approves a collaborator request, they’re giving a partner access to a live store. Action required If you or anyone in your partner organization sends collaborator requests, complete identity verification on the Request collaborations page in the Dev Dashboard. Identity verification is optional today, but we recommend completing it now to avoid interruption when it becomes mandatory in the coming weeks. After enforcement begins, unverified users won’t be able to send new collaborator requests until they complete verification. To prepare: Complete identity verification before sending new collaborator requests. Make sure every user in your partner organization who requests collaborator access verifies their own identity. Have a government-issued photo ID ready, along with access to a device that can complete a selfie or liveness check. Review the related docs below for more context on identity verification and collaborator access. Related docs Verifying your identity as a Shopify Partner Collaborator requests: Information shared with merchants

App Pricing: more plans, no-charge plan testing, and negative and fractional App Events

We’ve made several updates to App Pricing: Increased plan limits: You can now create up to 8 public plans (previously 4) and 15 private plans (previously 10) per app. No-charge plan testing: Test app billing flows without generating real charges: During app review, reviewers can now select any of your existing plans, so you no longer need to create a dedicated test plan. In development stores, you can install your own apps and subscribe to any plan at no cost. Mark a plan as free to let other partners and developers install your app and test that plan in their own development stores. Additional App Events support: The App Events API now accepts: Negative values, to adjust or credit previously reported event usage Fractional values, such as 1.5 Previously, event values were limited to whole numbers greater than 0. For more details, see App pricing and the App Events API reference.

Hydrogen developer preview update

The Hydrogen developer preview adds new capabilities to the toolkit and extends the ways developers can build Shopify storefronts: Storefront API caching for catalog data: Cache products, collections, and pages at the edge instead of hitting the Storefront API on every request. WebMCP tools for in-browser AI agents: Expose your storefront to in-browser AI agents so they can search the catalog, browse products, and manage the cart. Loads automatically from Shopify's CDN, no extra integration required. Customer Account API support: Build logged-in experiences like order history and profile pages with a typed client that handles login, token refresh, and logout. Same-origin predictive search: Add autocomplete search that runs through your own server instead of calling the Storefront API from the browser. Typed routes and redirects: Describe your URL structure once and reuse it for redirects, predictive-search URLs, and Shopify-standard resource mapping. ShopifyScripts for the Shopify browser runtime and unified cart route handling: Render Shopify's standard script tags and browser runtime in one place, and handle cart routes through a single registration that works the same across frameworks. To get started, visit the Hydrogen developer preview documentation. For a detailed breakdown of this release, read the full release notes.

POS UI extensions 2026-07 uses per-unit fixed-amount line item discounts

Starting with POS UI extensions API version 2026-07, FixedAmount line item discounts passed to setLineItemDiscount and bulkSetLineItemDiscounts from the Cart API must represent a per-unit discount. Why it's changing In API version 2026-04 and earlier, apps could pass a total fixed discount for the entire line item, and Shopify POS automatically converted it to a per-unit value. In API version 2026-07, this conversion no longer occurs. The value you pass is interpreted directly as the discount applied to each unit in the line item. For example, in API version 2026-07, if you pass '5.00' on a line item with quantity 2, POS applies a $5.00 discount to each unit, for a $10.00 total discount. To apply a $5.00 total discount to a line item with quantity 2, you must instead pass '2.50' as the per-unit discount. What you need to do This change only affects FixedAmount line item discounts. Percentage discounts are not affected. Apps using API version 2026-04 or earlier do not need to make any changes. Apps adopting API version 2026-07 must update their discount calculations before using the new version. If your app currently calculates discounts as a total line discount, compute the per-unit discount before calling setLineItemDiscount or bulkSetLineItemDiscounts — for example, by dividing the total discount by the line item quantity. If the total discount does not divide evenly by the line item quantity, choose a rounded per-unit value that matches your app’s intended discount behavior and ensures the final discount is consistent with your logic. For more information, see the Cart API reference.