We recently made some updates to the Shopify Partner Program Agreement (PPA) and the Shopify API License and Terms of Use (API Terms). These changes encourage the best possible merchant experience within our developer and partner ecosystem and protect the integrity of the Shopify platform.
Please review this summary of some of the changes we’ve introduced on our Developer changelog. We encourage you to take a few moments to review the updated PPA and Shopify API Terms to better understand how all of the updates may impact your business.
What does this exactly mean:“All data relating to a merchant’s customers that a partner collects on behalf of the merchant (excluding any sensitive personal information) must be sent back to Shopify.”
I would really like to understand what are the implications of your recent announcement that all payment processing should go through Shopify checkout.
All checkout and payment processing must go through Shopify checkout. Partners cannot bypass Shopify checkout unless authorized by Shopify in writing.
I see this as being targeted toward app developers(for example, ReCharge). They would charge 1% commission on their Custom Checkout experience, which theoretically would be lost commission for you. I get that.
However, there is another scenario. For the market I am currently developing for, Shopify Checkout is lacking. Common means of payment are banking integrations and shipping is often done to Pickup points, both features not possible to implement with Shopify Checkout.
So custom checkout makes sense - for shipping support and at least for some payment processing.
So, now, as a Partner I would not be able to deliver this functionality, essentially, making Shopify a very unattractive choice for this market.
However, if someone, who is not a Partner, would instead get a Staff account on the Merchant’s store and developed this checkout on their own - they would not be breaching any ToS agreement and would be good to go.
How come I, as a Partner, have been put in a disadvantageous position when it comes to delivering solutions for my clients.
“All data relating to a merchant’s customers that a partner collects on behalf of the merchant (excluding any sensitive personal information) must be sent back to Shopify.”
I don’t find this statement explained in the latest Partner & API terms page. Shopify needs to provide a mechanism to send back this customer data. If the customer data is received via Shopify API then is it still required to be sent back and how? Or does this apply only to customer data collected outside of Shopify? Very confusing change that we don’t know how to implement before the deadline of May 12, 2019. Apps team please clarify. Thx
I will quickly add that in addition to raising my concerns over on the FB partners group, I totally agree with @Nesters and it’s a major pain point for me going forward with Shopify.
I’ve put a good 6 weeks in to developing a design system targeted at ReactJS based SSRs such as Gatsby or Next exactly because I wanted to provide a storefront solution that has less limitations for merchants. One of the options there is for checkout to bypass Shopify’s checkout completely because let’s face it people - if you have a storefront like it’s 2019 and then you redirect to a checkout that’s like 2014 and on top of that it’s on a different URL because you can’t frame it in to your PWA app… well I am short of civil words to describe this situation. It is not nice!
Look, I get it that you want to keep transactions revenues and I am totally okay with that and so is anyone signing up for Shopify. That’s not really the issue or motivation to bypass checkout.
The reason to bypass Shopify checkout is you are NOT listening and from what I can tell from 2013 onward backlogs in these forums have staunchly held position that Shopify checkout is optimal and if you believe it isn’t “look at your Plus plan”.
Please clarify what @Nesters already mentions - is it okay for merchants to bypass Shopify checkout on their own behalf without partner / dev intervention?
Please clarify what this means “Partners cannot bypass Shopify checkout unless authorized by Shopify in writing.” - in particular the circumstances of getting authorisation from Shopify to bypass checkout?
Please do not make assumptions about checkout and what’s best for merchants. Yes you have your numbers to backup your claims and I am sure that checkout, as is, is very effective. But put that in to a completely bespoke and highly branded storefront theme, possibly not even based on Liquid or served by Shopify, and that “highly effective” checkout suddenly sticks out like a massive UX blunder. Open up checkout customisation for all plans.
Please complete API checkout - no, webUrl to complete payment step is not good enough for all the reasons mentioned above. Imagine the agony of doing a mobile app and having to load a web view just so we can load that checkout step? You guys surely know that web view on some mobile platforms is quite ineffective. Not to mention the horrid UX when your customer gets kicked out of a stunning native UI experience in to that checkout web view.
So yes, guys & gals, you have my support and all if you wish to forbid bypassing Shopify checkout - but please allow us to use it properly first!
“All checkout and payment processing must go through Shopify checkout. Partners cannot bypass Shopify checkout unless authorized by Shopify in writing.”
@Irene Given the fact that we already operate a solution that violates this policy, who can we contact to discuss a potential authorization by Shopify?
Also, how will this impact merchants that already rely on our solution?
All checkout and payment processing must go through Shopify checkout. Partners cannot bypass Shopify checkout unless authorized by Shopify in writing.
Our app has currently a solution that bypasses Shopify checkout mainly due to the fact the checkout API is not providing enough functionality to achieve what merchants require.
Moreover, there are merchants who originally didn’t use Shopify due to certain features missing and finding out they can achieve them using this method, decided to join Shopify.
Also, you are requiring partners to implement changes outlined here within 60 days, without providing an alternative solution, which in some cases may be affecting months of development, with such a small grace period.
“not use an alternative to Shopify Checkout for web checkout or payment processing, or register any transactions through the Shopify API, without Shopify’s express written authorization.”
Does this mean that we’re no longer able to use the Orders API Create Transaction endpoint at all for any reason without Shopify’s permission?
Hey everyone, I’m going to be going through the thread and responding to every post, and we’re working on some docs right now to clarify some of the more complex issues in more detail. I’ll update the main post once we’ve got some more detailed content for you.
I’ve got a couple of responses started, I’ll post these for now while we work on the other content. We’re definitely listening.
Good question. A good rule of thumb is : If it can be stored in a structured way on the Customer object, then it should be stored there to make it available in the merchant’s admin. There’s a doc that details this here. We don’t want to be in a place where all of the data on a merchant’s leads are exclusively controlled by someone other than the merchant.
We are generally open to changing things if you have specific concerns around any of the policy changes. If you feel like a few of these points have really hurt you, then post some details so that we can make sure we’re not missing anything.
This definitely makes sense to us, and is the reason that we explicitly call out the fact that there are exceptions in the TOS. First and foremost, we want to deliver value to merchants. That being said, there are a lot of poor checkout experiences. We’re working really hard on ways to solve this problem at scale. Documentation is incoming.
If you’re an app that’s collecting data on the storefront, there’s a chance the merchant can’t access their customer data unless they go through your service. We want merchants to be able to access this data through the admin. If you’re just interacting with the Customer resource through the Admin API, you don’t need to worry about this change.
There are a few concerns that should be addressed.
Certain merchants I’ve worked with are using Shopify not for its web checkout but for its content management system and its related tools and apps on the backend. They’ve chosen not to use Shopify Checkout on purpose and have developed custom web checkouts. Sometimes it is due the fact that Shopify does not provide support for certain payment gateways or they require very specific functionalities. They also do not want to use Shopify Plus, which also do not have these functionalities.
Shopify is simply a part of the overall technology stack and not the primary technology stack. They could very well have developed their websites using Webflow or just plain old Wordpress. Instead, they chose Shopify for its product and order management, but not for its web checkout.
Some early conversations I’ve had with merchants since yesterday indicate that they are exploring options of moving off of Shopify completely due to this API ToU change, given their heavy investments into their own customizations. Mind you, these are paying Shopify customers.
I think the Shopify team need to address this segment of the market. It seems the updated API ToU does not address this quite common use case and the negative impact this might have on not just developers, but on merchants themselves. The whole idea of having an API in the first place is so that merchants and developers can create solutions that Shopify won’t or can’t support. The logic and argument that Shopify is trying hard to solve problems “at scale” does not work when it is apparent that there are edge cases/needs of individual merchants aren’t met.
Regarding: ‘Developers cannot create multiple applications that offer substantially the same services.’
We have a software platform that powers fulfillment applications. Though our applications have the same service in that they support drop shipping each application is managed by a separate business, each with their own unique product lines.
I’d like to know if this provision is meant to discourage our business model, a model in which only encourages people to provide services to Shopify stores and gives Shopify retailers access to brands and products they otherwise would not be privy to.
@Shayne Are you saying that in this case custom checkout would be okay until you provide more tools to achieve the desired functionality?
What should I (as a developer) and the merchant do in this case to receive a written authorization?
Should we provide an explanation why this is necessary for the business?
Do we need to showcase a demo that it’s a legitimate checkout experience (this seems a bit counter intuitive considering that it’s against ToS in the first place)?
Explain the technical details of the checkout implementation and processing of customer data?
We are looking forward to hear from you guys. There are multiple projects that are in a situation where custom checkout is the desired way to move forward, however, now we have no clue whether it is okay or not.
It looks like Shopify has issued an update to the API Terms so that section 3.2.18 (checkouts outside of Shopify Checkout) no longer apply to private applications.
Thanks for the heads up @donny ! Also, respect to the Shopify team for the quick update and additional documentation.
However, my initial question still remains:
Given the fact that we already operate a solution that violates this policy, who can we contact to discuss a potential authorization by Shopify?> > Also, how will this impact merchants that already rely on our solution?
Our competitors in the face of Bold, One Click Checkout and Carthook have all released statements, that their custom checkouts have been authorized to keep working. What are the rules/conditions that we need to comply with to get this authorization? Who can we talk to? Also, what will happen to our current customer base?
It would be a shame if you cherry-pick some custom checkouts and kill-off smaller projects, just because they have an internal connection with Shopify. We’ve all chosen to build software for Shopify, because of the open API’s and the opportunity to stand out if you build a better product, I would hate to see my app being shutted down, while the exact same alternative product keeps working with Shopify’s blessing.
Thanks for responding with updated documentation and clarification on many concerns raised here. I am no lawyer so all this legal lingo is a little beyond me, but could you also be more explicit about
You’re a partner that works with individual merchants on custom checkout needs using a private app. These changes don’t affect your current engagements with these existing merchants.
mentioned in documentation. The bold text implies that the changes do not affect existing private apps but leaves a little uncertainty about new private apps. Am I reading too much in to this? The ToS simply exclude all private apps and make no mention of existing or new engagements.
Thanks for all the feedback everyone. As @donny mentioned, we’ve updated the terms for clarity. The intention was never to remove the ability for partners to provide bespoke solutions for their clients. The merchant owns their data, and their API credentials are there so that they can access it.
We really appreciate the depth of responses in this thread, thanks to everyone for taking the time.
Good point @leteyski . I was wondering what would happen to those vendors you mention. The fact they already released statements that they will not be affected does suggest they knew upfront.
