When an order is created at Shopify, a callback is initiated from Shopify that hits the webhook given in the settings.
The parameters that it uses to hit the webhook, those contain multiple emails, and there are no docs for those.
You can see those parameters here: https://codebeautify.org/jsonviewer/cb3e0c52
One email is in the root. 2nd is by the name contact_email, and the third one falls under customer and goes by the name: email.
As of now, there is no documentation that states which email stands for what.
My question is: how would I know which email has the customer used for purchasing the product, and it would be the very email that I will use for contacting back with a customer.
Shopify webhooks: https://help.shopify.com/en/api/reference/events/webhook
You can do the following. One. Check to make sure a customer record was attached to the order. Surprisingly, it has been known to happen that you get an order without a customer due to a glitch. Assuming you have a customer record, use the email field from that. If the customer record does not exist, the one at the root is likely your best bet.
That is it. Any other emails floating around can be safely ignored by you. And also, be double dog sure you do not email this customer unless you are allowed to. Otherwise, you are spamming, and that will get you hammer-banned by the merchant, who will take the brunt of the abuse from your spam.
That means checking the buyer_accepts_marketing attribute.
Related
I have just published an app, and so far my purchase rate is below 1 per month, so dealing with refund requests, and refunding the correct purchase would be easy.
I am concerned when the rate increases, I may have no way of telling from a "contact the developer" email, which user request is associated with an order-id, and thus be able to refund the correct account.
The android Google Play does not seem to give an order-id so the user can help associate themselves, and the console does not seem to allow association with an email address.
I received this reply from google...
Sign in to your Play Console.
On the left menu, select Order management. Search full order with order id or email address of user.
Check the boxes next to the orders you'd like to refund. To refund multiple orders at the same time, make sure you select orders placed
by the same user.
Select the appropriate refund reason.
Select Submit.
So given I knew the email address of one of the customers, I was able to search for exactly that customer, and it highlighted the transactions made by that user.
It didn't seem to cope with wildcards, or partial matches (makes sense given privacy).
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.
How can I have access to bigcommerce's %%GLOBAL_CustomerId%% variable?
I create a sample template and logged in with as a user. That variable doesn't show up. Isn't it suppose to be a Global variable?
Background: I want to create an app for bigcommerce that can identify a user base on their customerID. If I can't grab that variable, you guys see any other way to work around this?
It's not immediately clear in the docs, but you can use %%GLOBAL_CurrentCustomerEmail%% anywhere on the template to get the email address of the currently logged in user.
If you need the customer's ID, then you can query the API with the email as a parameter.
Personally, I'd rather "trust" the customer's email as a point of identification, because you never know if the Bigcommerce ID's may get changed or not (example: Customers are deleted and then reimported, now having brand new ID's).
On a subject of security though, you cannot trust client side data, and should attempt to mitigate fraudulent requests through the use of a CSRF token or some similar measure. Otherwise, anyone can send you an email address and receive back a list of that person's favorite products -- golden information for say, a targeted advertising company, or just your suspicious next-door neighbor Joe who seems to always be conveniently checking his mail right when you get home from work, but never says anything when you walk by, not even a wave or a smile, despite the fact that you all have been neighbors for quite some time now. Like, should I say something? Hahaha, I kid I kid.
I'm using Paypal rest api to make payment
the workflow is:
Create payment
Redirect to approval Url
User approved (return back to my site)
Execute payment
But there's one thing that I don't want users re-filling shipping address again because it was filled in my website.
So I change the workflow to:
Create web profile (set no shipping field)
Get web profile ID
Create payment with experienceProfileId given
Redirect to approval Url
User approved (return back to my site)
Execute payment
But I found this will create a lots WebProfile every time user request payment.
I think it is crazy to do:
create and delete it later again and again
attempt listing WebProfiles and check which is the one I want to use every time while creating payment
store experienceProfileId as a constant
What is the best practice for handling WebProfile or does there any solution just hiding shipping address while user approving payments?
Maybe this is not the answer regarding this "WebProfile". As a fact, I dont know what exactly "WebProfile" does or is.
I worked on the same Workflow these days. As you wrote I needed to predefine some address. For me it was obvious, that I have to do the database-stuff on my Website. Then I exactly define the order, shipping_address, etc. and send the users to Paypal.
If you predefine the new ShippingAddress() to your ´new ItemList()´ by
$itemlist->setShippingAddress($shippingaddress) the user cannot change it within the Process.
http://i.imgur.com/nAg8jxU.png
Maybe this helps you a little.
You can create a contact and specify email, but the only option for updating a contact seems to be name. Is it possible to update a contact's email?
This would be preferable to making the user delete the contact and then add it again it with a new email, in cases where they mistype the email (or if the address changes, I suppose).
Nah, there's no way to change the email address. You can programmatically delete the contact rather than making the user delete them, I think this is what the website did.
Just a note, as I mentioned on this other thread (Add contact to pushbullet with the api): the official apps use the (not yet documented) /v2/chats objects instead of contacts
You can update a contact, but the exact rule is vague:
Any non-contact data will not be modified.
I use it to change a contact's primary email address, but sometimes it works, sometimes not, and it seems to be related to how the email found its way into the user's google contacts.
I suspect if an email address was imported, there's an issue, but I have spent a lot of time and still have no real idea.
In fact, my implementation is horrible. I first store the current email addresses for a contact. Then I do an update to clear them out. Then I do another update to add them back, but this time with the primary=true flag set on the new primary email. Can't get it to work as in the reference, whereby a single update transaction should work.