For a Shopify App, should we be using 'shop_id' or 'shop_url' to keep track of user accounts?
The 'shop_url' account is easily accessible, but I'm wondering if this is a reliable field (does the shop_url every change if a user attaches a domain name or contacts suppport?). There is also a 'shop_id' variable but it seems to require extra API calls and makes me question if I should be using 'shop_id' or 'shop_url'. How do other Shopify App developers keep track of their customer accounts? Do you use the 'shop_url' as the 'key' in your database?
Everyone without fail will use the store name. That combo *.myshopify.com. It is unique to a store, and is handed to every call made to an App. shop=drunkmonkey.myshopify.com for example. No ID. Nothing else is used, just that parameter.
Related
I'm working with a client that wants to build some custom rudimentary affiliate functionality. The requirement includes two types of users: "owners" who are technically the affiliates and "customers". We are planning to use metafields to assign owners to customers (simply an integer metafield in the customer object that holds the owners userid, managed by a site admin). We would like to create a liquid template, accessible by the owners, that show a list of their customers and some customer and order metafield data. This requires one user (the owners) to be able to each into another user's (customers) metafield data. Is this possible in liquid without creating an externally hosted app?
If not, I assume this is possible via the API. In that case, is it possible to use the API right in liquid without creating an externally hosted app?
Thanks!
No, Shopify does not allow you to access customer objects (and by extension, metafields on other customer objects) other than the customer that is currently logged in.
To access arbitrary customer information, you will need to set up an app with admin permissions to access customers. While technically you could make admin API calls through the front-end, doing so would require exposing admin-level API credentials and would be a Very Bad Idea.
You will definitely want an externally-hosted app to run this code on, as the app you are describing will have access to PII and other sensitive data.
Background:
I am making an app which will be a public app and will put it on Shopify App Store.
I have completed with the OAuth process and I get access_token and scope in return which is good. I can now use this token and send API requests with X-Shopify-Access-Token in the header.
But, for my database design, I need the user details as well, like user ID or email ID for example. However, I read the docs(scroll up a bit) and it suggested in the caution section that email address is not reliable to identify the user(merchant). I also gave a read on access modes which is online and offline, and in my case, I would need an offline access token.
Question:
How would I get a User ID from Shopify during app install so that I could uniquely identify each merchant?
One of the reasons I would want to have this is because a single merchant could have(or see) multiple stores linked with my app and I wish to show them details for each store under a single user account.
When a merchant installs your App, during the oAuth flow, you are presented with the shop name. That is unique, and will always be present for incoming calls to your App from Shopify.
You do not mess around with email, or user ID's. You simply persist the access token you got in your data store, with the shop name.
If you wanted to group by a merchant name, you know each Shop object provides the shop owner details. So you can always dig those out and store them along with the shop name, allowing you to show one merchant, many stores.
I have developed a Shopify app, I wonder if we can perform the following functionality :
when a customer has logged in to his account on the store I want to also log him into my app, in another word I want to make a customer account is the same as his account on my app.
One thing you know. A customer logged into a Shopify store has a visible ID to Javascript. You could thus use an App Proxy to securely pass back their ID to your App. Using that ID, you can offer functionality to that customer, in your App. As long as you restrict access to the Proxy, you'd be A-Ok security wise.
If you wanted to allow access to the App without Proxy calls, you'll have to put into place your own security, which as we know from experience, will likely be weak and or a calamity. Most people should never roll their own security patterns. If they login to the App, without Shopify Plus Multipass, you cannot log them into Shopify. So you have no other options AFAIK.
I am trying to make a plan to update my client's shopify stores by building Shopify app or using external library. Basically, I want to provide my clients with some convenience by automating the inventory update, order process and extra stuff.
For now, I have only two scenarios.
Whenever my wholesale inventory changes, i want to update my client's shopify product list to be updated (quantity, price and product description) accordingly.
Whenever my client(shopify store owner) receives an order from his/her customer, i want the order information to be automatically transferred to my server.
If possible, I want my clients to be able to integrate with my application without any tech knowledge. I have looked into the Shopify app (public/private) and some external API(java), because I am a java developer.
I checked Shopify Java library which requires api key and password to be able to access shopify owner's store for product/order access, but I am not sure how user-friendly this approach is in terms of Shopify owner's side.
For Shopify public app, I am not familiar with it, so I am not sure how much I can do with it.
Could somebody provide some details about pros/cons about these approaches?
Thanks.
All you need to know is that with Shopify, you can connect to their shop using standard HTTPS. Even better, it's all GraphQL now. As for credentials, Shopify is fully modern and offers you two methods of getting credentials.
Your merchant client can create credentials with permissions right inside their Shopify Admin -> Apps. They give you the keys, you're in business
You get them (or you) to simply click install your App running at some HTTPS address, and you use oAuth to get the credentials.
Either way, makes no difference to the actual code you write to interact with their shop and deal with inventory, sales etc. You do not need to make your App public in the sense of App store, so you can use your partner dashboard to create an App and oAuth install, or like I said, use the private App way.
I have a requirement to do 3rd party age verification before I ship an order. I'm using a company called EVS for this. They released a shopify app recently, but seems partly baked. It requires a user to enter date of birth when registering for an account and then triggers the verification when the user places an order. The main problem with that is that it's rare for a customer to actually create an account before ordering for the first time -- instead they order first, then shopify emails them to create an account after the fact. Creating the account afterward does not allow the customer to enter DOB.
So I'm planning to implement my own solution. I can use EVS's API to run the verification by sending a combination of Name, Address, DOB, DL# and State, and last 4 of SSN. I have already built a proprietary order management system that pulls in customer and order data, and I can write a client to perform the verification.
I'm less savvy on the shopify side. I need to balance customer friction when placing an order for the first time, against having to do a lot of manual work for verification.
Below are the options I have conceived. Are there any other options? Any ideas for a better solution? Keep in mind I need to verify a customer once. I can tag the customer account as verified, and once verified it's business as usual.
Alter shopify templates to only show the checkout button when a user is logged in. If not logged in, show a "Create an account" button instead. That way the user provides DOB during account creation and the EVS app works as designed.
Set up a separate verification site like verify.my-domain.com. I can trigger an email to the customer upon order creation and ask them to verify. (May have issues with incorrect email addresses or spam filtering.)
If customer is not logged in, or account is not age verified, and they click Checkout, I can redirect them to a page. I can use a form on the page to do the verification. If verification passes, send them on to checkout.
For option 3, I don't know what shopify allows or what best practices allow. Can I use js to pass data to my own server on a different subdomain? Or post the form to another subdomain and then redirect back to shopify?
I'd appreciate any thoughts or suggestions.
You have pretty much summed up all your options, to clarify on them a little:
You can require that customers create an account in the store checkout settings. /admin/settings/checkout
This would work, you could iframe it in too on a custom Page. Or, better, use cross-domain calls or jsonp.
This is a little convoluted and you would have to persist and maintain lot of external state. I'd avoid this
I think a combination of 1 and 2. Turn on "require customer account". Modify the customer account creation page. Implement a cross domain policy with your server which will host custom code leveraging the EVS API.
I'm not sure if you are selling tangible goods or not but with stringent policies on users' age you have to bear in mind that shipping addresses could change. For a tight integration you should look at having webhooks whenever a customer is changed and make sure all their data is still valid since their last EVS approval.
I've been looking into this quite extensively and we've spent a number of hours experimenting with options. Our client in this case is on Shopify Plus so we do have the benefit of access to checkout.liquid.
Our research has led us to believe that one cannot pass the required 'customer note' of the date of birth to the checkout should they be attempting to checkout as a 'guest'. Perhaps because the 'customer' does not yet exist.
Our options have been narrowed down to:
Write a custom backend app that allows Shopify and EVS to communicate directly (XML API on the EVS side) in the checkout process or just prior and then pass the verification status back to Shopify to allow the order to proceed, or append some relevant status marker for the fulfillment department to act accordingly. The EVS app doesn't prevent the order from proceeding, but does flag the customer's age as unverified in the Risk Level panel in the admin. This would be quite a substantial project and by no means low hanging fruit. There is also risk of re-doing a lot of what the EVS app does already and running into they same obstacles they did.
Force customers to register prior to checkout (if not signed in). This seems the most viable approach. The only caveat being that existing customers will not have the customer note (birth date) and we'd need to build a smaller backend app to allow them to append this to their customer account via the Shopify API (this cannot be done via liquid).
These are our findings and I'd love to know more about how you ended up approaching this.