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.
Related
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.
The company I am working at offers a web based calculation tool which has to be paid monthly (a fixed price for a license).
Normally, users go to our website and authenticate themselves with their credentials and then can use the application. When they cancel their subscription they are not able to use the tool anymore, obviously.
Now another company called us because they want to provide our application for their own clients. We have already fixed that they have to pay a license fee for every of their clients. But there is also a restriction: their users should not have to log in on any of our websites (only on the website of our client). But the web application is hosted on our server and is loaded as an iframe.
Now there is that problem that we are not sure whether our client tells us the correct number of people who use our application wherefore we would like to verify that in some way.
One of my ideas is the following:
Our client has to call an API for every users who would like to use our application in order to submit some information like name or an unique ID of that user
When the user would like to access our application, an ID parameter is appended to the iFrame URL
I think that this is not a very good solution because our client could use the same ID for every access and pretend that only one users uses the application. By saving the ip address and id of the accesses it is possible to determine fraud in some cases because ip address will not change frequently.
We even do not have to know WHICH user accesses the application but only the NUMBER of users per month.
I am interested if there is a cryptographic solution where it is hard to cheat. Something like an authentication method which does not require any interaction of the user.
Well you can't. You should require the partner to issue a token for each user so you know they came from the partner.
You could have the partner call an api you expose to issue a one time token for a user and specify user id and IP. You could alternatively have the partner digitally sign such a login request.
If you bill the partner per user, and the partner decitfull he could claim less users.
You can fingerprint the users, you can give long term coockies, you can check IP and fonts installed etc. These will allow you to detect most types of fraud.
If you give a declared userId a cookie and then see him again without it, you assign him a new cookie and then later see the first cookie again while the partner is always declaring same id that is a very strong indicator of fraud.
If I was the decietfull partner I would pair up geographicly close users and merge their IDs. it would look no different from a user with two devices. But this still limits the extent of fraud possible. Two devices per user is plausible. 10 less so.
Find business partners you trust.
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.
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.
I'm looking to implement an SMS authentication for one of my projects, basically before a user is able to register an account with us, we would like to authenticate the user by sending sms containing a code to his mobile phone, and get him to put in the code in our form before he can proceed.
I've been looking around and found onVerify to be a pretty good way to go
http://www.onverify.com/
But I'd like to know if there're any other alternatives similar to onVerify as it is a bit expensive, so if I could go with cheaper one, that'd be great.
Thanks!
You can do this easily enough if you have access to an SMS provider.
Typically you send an SMS to the user by making an HTTP request, containing the verification code. You'd store this code, and the recipient number, in some persistent database, against which you can compare when they fill in the details on the form.
You don't mention which geographic regions you expect your users to be in, which can be important given the variable delivery quality in some markets.
Have a look at the HTTP API for BulkSMS, message pricing and coverage.
Note that you can register in various regions, if you, for example, want to price in USD.
Disclosure: I work at BulkSMS