Hit “Reply” below to ask your questions now and return when they’ll be answered from 1pm ET on August 8th. Don’t miss out on this chance to connect with our experts and engage with fellow developers.
What to know:
You can already start building extensions for customer accounts into your app and apply to be one of our exclusive launch partners for the upcoming release of customer account extensions to Shopify merchants in December.
This AMA is an opportunity to interact with the team who are building new customer accounts to get any questions answered on both the product itself and the launch partner program.
In advance of the session, dive into our developer documentation to join the developer preview and start creating unique, powerful customizations for customer accounts.
Rules of engagement:
We’ll do our best to follow up on every question during the event.
You must be logged into your account on Community to participate.
Assume positive intent with one another and be kind. Some users may be new and learning how to engage with the Community.
Be authentic and honest with your questions and answers.
Do not ask for or share store admin login details or passwords.
Like posts and threads that are of interest or helpful to you.
Be constructive with criticism, not offensive.
Share your experiences and insights whenever you can to support others.
Abuse, harassment, and spam content won’t be tolerated.
Excited that Shopify is offering this awesome opportunity! We’ve already published a few checkout and customer account extensions that have been used by merchants for some time now and we’re very impressed at how seamless the experience has been.
Quick question from the application, it mentions we should provide “all extension IDs for our app”.
Can you clarify where we can find these extension IDs? I just want to make sure we’re providing the correct answer but there’s not a link to the docs or any explanation on how to find these IDs in the application doc.
We’ve been investigating impersonation and SSO possibilities for B2B merchants. Since a customer can only be assigned to one company at a time, in order to enable impersonation, we need to provide an interface to customers where they can reassign themselves between Companies based on some permissions. This can largely be handled through customer UI extensions and customer metafields, no problem.
However, when it comes to SSO on non headless stores, what are the options? Can we use the new customer account APIs for this? A use case would be that a user hits a URL that should log them into the Shopify store seamlessly - no code verification via email. The URL can be hosted on a server side application.
I’ve seen single sign on mentioned a few times on articles related to the new customer accounts API, but I can’t really see how it can bypass the email code authentication part.
We’ve run into this roadblock too and have yet to find a solution. Our use case is providing a seamless login experience after a new customer submits a registration form. Typically the registration forms in question contain a mix of standard fields and custom fields (with custom field values saved to customer metafields).
With new customer accounts, it seems like the only way for a customer to be authenticated is through the native login form and OTP flow which is currently email-only. I suspect SMS OTP is coming at some point down the road but that is just a hunch…
Even if we can’t automate the full auth process, it would be nice to have a way to programmatically trigger the OTP email so customers are not forced to submit the login form on their own if they wish to log in to the account they just created.
How can we get the correct quantity rules and price rules for a variant given that we have the company and the location?
As a location can have multiple catalogs and there can be conflicting rules for a variant which is present in both catalogs. For example:
Catalog 1 → variant1 → min: 10 increment: 15
Catalog2 → variant1 → min: 1 increment: 5
How do we know as an app which quantity rules should be taken into consideration? (same question for price rules)
When will apps people to inject a link into the top nav or into the user menu? For example, a Subscriptions tab like what the Shopify Subscriptions app has.
Are there any plans to let app developers customize the “Buy again” button on the order detail page?
Currently, the button is redirecting to the cart with a permalink, which only contains the variant IDs and quantity, all line item properties are lost.
This is already a huge issue for our merchants, their customers are re-ordering, and they are getting a product without the custom info provided previously.
Possible suggestions include;
Fix the Buy again button to also restore the full line item properties.
Allow apps to hook into the buy again event.
Allow merchants to replace the button with a custom logic from an app.
A bit of an more advanced question but here it goes.
We’ve published a Checkout Extension and Customer Account Extension under the same single extension, just specifying different targets in the toml file.
It’s been working just great for months now, but we realize now that there’s a single API version field on the toml file that will apply to both the Customer Extension targets and the Checkout Extension targets.
Since there are 2 distinct API versions for Customer Extensions vs Checkout Extensions, but only one api_version field per published extension - are you recommending that app developers create a separate extension per type of extension?
Just seems a bit messy, we’d like to share code between extensions as much as possible, and different versions across these two major extension options might get complicated in the future.
Case and point the Drop Zone component was released for Customer Account Extensions yesterday, but it doesn’t appear to be available for Checkout Extensions at the moment.
These kinds of differences between components/APIs across extensions will be very tricky to keep track of.
Please let us know your thoughts and how you think us App Developers should approach this!
How “complete” do the customer extensions have to be by the deadline date of Aug 31, 2024? I see in the form that we require customer extension IDs as well as a screencast. Some devs have suggested to me to screen cast figma prototypes while others are focused on fully functional extensions. I am curious if the extension readiness by Aug 31st, plays a role in the selection process
What will be the eligibility and evaluation criteria to be a Launch Partner?
What exactly does it mean to be a Launch Partner Program and what benefits we can get?
What upcoming features or improvements can we expect to see in Shopify’s New Customer Accounts (apart from the roadmap), and how can developers prepare for them (does Shopify plan to bring order edit natively) ?
What were the core objectives when designing the New Customer Accounts feature for Shopify merchants?
How does the New Customer Accounts feature enhance the overall customer experience compared to the previous version?
Can you share insights into the development process and any major technical challenges you encountered?
What metrics or feedback are you using to measure the success of the New Customer Accounts feature since its launch and how frequently you expect people to visit these page?
What advice would you give to developers looking to leverage New Customer Accounts in their own apps or integrations?
What kind of innovations or trends do you foresee in customer account management on e-commerce platforms, and how is Shopify positioning itself in that landscape?
What are some common misconceptions developers might have about New Customer Accounts, and how can they better utilize its capabilities?
What are some of the biggest opportunities you see for developers to add value to the New Customer Accounts experience?
Some of our clients thinks that it is limited in terms of customisations (moving sections around mainly or changing cards into disclosures for example) so how can we address that?
Brief description of what your app does in new customer accounts
Specify Extension IDs
Links to End to end demo
How much of this do you want to see built and ready for new customer accounts rather than demonstrating and explaining how we see it working and solving the merchant and customer pain points? For example, we can reference current extensions we have but this may evolve as we try to solve the problem a bit better for our merchants.
Is this AMA some kind of zoom call, or we will just receive reply to our messages in this thread ?
Questions relating to Launch Partner Program
Are there any specific metrics which the app or developer should meet ?
By when / what specific date should the app/feature be working ?
Is there any preferences between existin vs new apps ?
For existing apps, it will have existing working feature, and this new feature being developed may b a small feature compared to overall features of the existing app .. is that ok ?
For new apps, should it pass shopify review by some specific time ?
Question regarding the Customer Accounts Launch Partner Program - For new apps we won’t be able to publish it on the Shopify App Store as a public app since the CA extensibility is still in developer preview, but the form asks for the app listing URL, so how exactly are we to submit the app? Is there a way for us to share the app without publishing either via direct access to the partner account or a demo store?
Extension IDs are optional (they are helpful for us to be able to do some testing on our side).
Our preference is to have the customer extensions be as complete as possible by 8/31, we do favor completeness! If you are still working at that time and can only show a recording of a figma prototype by then, I’d recommend doing this so we can get a sense of what you’re working on ! Generally recommend to all folks to include links to any mock ups in the “Anything else to mention in regards to testing the app?” section so that our UX team can easily review and provide suggestions !
In general - we do recommend to put separate features in distinct extensions rather than trying to extend multiple targets within a single extension (apart from very specific use case, such as a feature that is exactly the same across different targets). This is because the merchant experience is much more rich in the case of one target being extended per extension, and it allows developers to leverage features such as extension collections and default extension placement.
It’s true that sharing code across different extensions can be challenging. This is something we’ll be looking at improving in the future in our ongoing goal of making the development experience across checkout and customer account UI extensions as consistent and good as possible.
Amazing, Order Management is a great use-case ! Yes! Based on how I’m understanding the question, you can take this approach! Important to be ready to switch over when Customer Account goes to wide GA (all launch partners will be required to do this).
We built our extensions very early, we didn’t notice any guidelines in the Checkout Extensions or Customer Account Extensions documentation regarding this best practice.
Unfortunately now we have merchants implementing this extension in both contexts, so switching might not be possible for us. If your team has a way for us to split our current extension into two published versions without interrupting the checkout profiles merchants have set up, I would really much appreciate that.