I want to see if there is a way to quickly check on the mobile web on chrome whether or not a user has Google Pay enabled. On IOS, I can call window.ApplePaySession.can make payments() method on safari dev tools to instantly know if the user has apple pay enabled.
Is there an equivalent code snippet I can call on Chrome dev tools to figure out if the user has Google pay enabled? I don't need to be able to make a transaction or anything complicated, I just need to know if a user has that functionality enabled.
As far as my research, I found that window.PaymentRequest(methodData).canMakePayments() should do the trick, but the problem with that route is that methodData needs information such as the merchant ID and merchant name, which I don't have. On apple's side, I do need that info to make a transaction, but I don't need it to simply check if apple pay is possible. Is there a way (maybe similar to the previous code snippet I shared) to ask the browser if Google pay is enabled without providing extra info such as merchant ID?
Google Pay has a similar functionality to determine the readiness of the payment method to Apple Pay. Though it is not simple as finding out in Apple Pay, you had to set some data to determine the readiness as given in the link - https://developers.google.com/pay/api/web/guides/tutorial#isreadytopay
However, you do not require any explicit requirement of Merchant ID here to fulfil this isReadyToPay API.
Related
I am trying to obtain my production keys for my QBO app following the steps in this link
here
However, when I try to start the "App Assessment Questionnaire", I get the error message below:
You currently do not have a developer account, please click here to complete setting up your developer account. Once that is complete you will be able to access the help pages.
This is what I see, and I DO have a developer account. It won't let me continue.
Please help!
UPDATE
I see this error in the address bar:
ErrorCode=ERROR_CREATING_USER&ErrorDescription=License+Limit+Exceeded
UPDATE #2
I tried creating a brand new account, a new app, on a different PC and the same thing happened. So this is not a cache issue.
UPDATE #3
Created 2 support tickets for this issue
#00114423
#00114415
I had to use a different account to access the help site
https://help.developer.intuit.com
I've the same issue since Friday (02/18) and spent hours to figure out what's the problem.
tried from different browsers and different IP addresses
made a brand new developer account to test with it
had a 1+ hour chat session with QB support (but not developer support)
sent an email to an address received from the chat assistant
sent a feedback at https://www.surveymonkey.com/r/AppAssess
According to the browser's developer tools:
the Start questionnaire button opens this URL:
https://developers.intuit.com/app/developer/appdetail/prod/questionnaire?appId=xxxxx:UUID_of_app
then it redirects to:
https://login.salesforce.com/services/auth/sso/yyyyyyyyyyy/Intuit_Enterprise?community=https://help.developer.intuit.com
finally, SSO to salesforce fails and it redirects back to:
https://developer.intuit.com/app/developer/qbpayments/docs/qbms-payments/hosted-paypage/faqs/help-redirect?**ErrorCode=ERROR_CREATING_USER&ErrorDescription=License+Limit+Exceeded**+-+Customer+Community+Login&ProviderId=xxxxxx&startURL=%2Fs%2Fquestionnaire%3Fapp%yyyyyyyyyyyyy
So, it seems to be, QB have reached a license limit at salesforce, which prevents new logins to create and the questionnaire from to load.
And the funny part is: the same thing happens, when I tried to create a support ticket and used the "Ask a question" button at https://help.developer.intuit.com/s/
Which means, I can't start the questionnaire and can't start a ticket about the error either.
I guess, if QB developer accounts whom created support tickets previously or started the questionnarie before the license limit has been reached, they have have a SSO login account at salesforce and able to fill in the form or start new support tickets, but others are stuck because of the license limit.
If somebody have a working QB developer account and able to start a support ticket, please do it, and link this page in it.
Or maybe, we should contact salesforce support to let QB know about the license limit.
I'll give it a try.
This seems to have been fixed. I tried running the questionaire and it worked.
I have also been having this problem the last several days and had the same lack of success with QB support. The URL callback error I see is:
ErrorCode=REGISTRATION_HANDLER_ERROR&ErrorDescription=Please+sign+the+terms+of+service+before+you+login+to+community
I don't see anywhere I can sign a TOS in my account page - it's possible that in fact QBO hasn't signed a TOS with Salesforce. What a joke.
I was implemented inline payment and set Approved URL(return url) in business account with select 'Header Redirect' options, But after 3D secure page not redirected to given return URL with transaction parameters like order number,transaction id etc. because this parameters store in my system. It's working well on sandbox mode but when i have set live mode not return to set return URL.
Any possibility, can i set 3d secure page in inline (iframe). Currently 3d secure page showing on new page.
Please help me, if any one handle same issue.
Thanks in advance,
Rakesh
I would look to see if the issue is present only on IOS devices.
I manage multiple payment systems and just over a month ago, all of them started failing on the redirect. After careful investigation it was proven that it only occurred when using IOS.
The reason is apple released a stealth update that turned off cookies. They are required by the vendor (Worldpay, Protec etc) to hold your data while processing through the 3D secure as it is an Iframe.
Since the data is not saved, although a payment is made successfully (remember 3D secure is to verify cardholder present and not the actual payment) there is no information for the call-back to use and therefore it fails.
This is entirely in the hands of Apple, the banks cannot do anything, the vendors are helpless and the end user is none the wiser.
One has to wonder if this was an intentional move by Apple to undermine other payment processors as this started after the announcement of 'Apple Pay'.
I hope this clarifies things for you
Is it possible to check via MirrorAPI if a user actually owns Glass or if their account has the Mirror API functionality enabled?
There is currently (As of XE10) no way to do this. It is, however, a requested feature, so you may wish to star https://code.google.com/p/google-glass-api/issues/detail?id=107 to register your desire for the feature and to follow progress on it.
The suggestion there, and in other related SO questions, is to do a double-opt-in with the welcome card. This continues with the best practice of creating a welcome card, and also gives it a use to verify that the person can see it.
I think I also read in the mirror api docs, that a user cannot enable the mirror api if they are not a glass explorer: (right under step 2 on https://developers.google.com/glass/quickstart/php):
During this stage of the Mirror API Developer Preview, the API is only available to developers who have Glass as part of the Explorer Program.
If you are not an Explorer with Glass, the toggle is not displayed and you cannot enable the Mirror API.
I'm working on a service that needs to be able to read items from users' calendars. It needs to work whether the user is using Google Calendar, Exchange, Hotmail/Live, iCal, etc...
I want to do this (effectively):
calendar = Login(emailaddress, password); // Works for #hotmail.com, #gmail.com...
// For every item in the users' calendar extract the location of the meeting
for each (item in calendar)
location = item.Location;
I figure someone must have built some code that abstracts away the varied ways you login to these services and access the objects. But I haven't found anything yet. Any pointers would be appreciated. I don't really care what it's written in (Ruby, Python, C#, Java) as long as I can wrap it.
UPDATE: I've been able to get something working against the Google Calendar using the Google Calendar API. In the process I came across CalDAV and the fact that Google, Yahoo, and Apple support it. I'm going to focus on CalDAV for now, and then probably plumb in Hotmail/Live and Exchange later. I really only need the calendar event times and location so this should not be too challenging.
UPDATE 2: I have discovered DDay.iCal. I'd like to use this as my top level abstraction within my app. But I still have not found anything that will help me connect to, and interact with each of the popular mail systems. Nor have I found any code that shows how to layer DDay.ICal over CalDAV (which, theoretically, would give me Google, Yahoo, and Apple). Anyone?
There is a calendar REST API for Hotmail which is available in beta form as part of the developer preview of the Live SDK. This is also a beta interactive SDK for the REST API which you can try out at http://beta.isdk.dev.live.com. Just try out the query "/me/calendars"
I have seen a disturbing trend where websites are starting to require verification sent to cellphones by text message (SMS). Gmail and Facebook are two of them. What I want to know are the following:
Is it a good idea to start requiring cellphones instead of emails now?
How do I do it on my own website?
Edit
Here are some of my new questions on the topic in response to the answers:
I see that most of you are saying that SMS registrations is ok. But what about the people who don't have cell phones? And why is it accepted to give out your cell phone information freely?
Do those big providers really pay per message to a gateway service? Is it not possible to set up a server with the correct SMS software, or at least buy a subscription directly instead of having a middleman?
Most SMS Gateway services have some kind of API. An HTTP interface seems to be the norm.
Just make sure you sign up for a service that allows receiving of messages because not all do. It's more work for them since they have to send some kind of data back to you.
Some services offer send receipts too which lets you see if the receiver got the SMS.
Some examples follows.
Esendex API docs
TxtLocal
In regard to question number one, I think Commander Keen's advice is sound.
It is a good idea if you want to limit the number of fake accounts. I see it used lots in local newspapers here in Norway. I guess it makes people think twice before posting useless crap on their discussion forums.
But do you really hate your users that much? Gmail and Facebook are big enough now that people will accept jumping a few hurdles to use the service, but you need something really interesting to make the user accept this inconvenience.
SMS is the reason I can't use App Engine ().
The first problem is that some people do not have cell phone. I can use Facebook almost completely without validating cell, but uses CAPTCHA to get through certain actions. Therefore, CAPTCHA is one of the good alternatives.
I personally think, cell phone stuff belongs to cell phones and should not be in the Web.
What if every forum admins and newbie PHP developers in the world used SMS validation and someone hacked (cracked) into their database? Do you trust a small forum? Is anti-fraud measure required so desperately?
If your site is very large and popular, it may be good to get SMS validation.
As a member of CS Networks Support team. I am going to give you some answers.
People use their cell phones as a medium of verification, so the service providers can be sure that registered member is not a bot or something else.
Yes it is true. Big providers pay for SMS gateway services. Yes it is possible to have an infrastructure like that, but it is recommended that you have a team of people that are in this business for a long period of time.
The one main reason for using SMS as a way of authentication is that you link the account to a mobile phone, which effectively reduces the chance of fake user accounts by a very large margin.
To implement this feature, you will need to sign an agreement with a SMS Gateway that has coverage for the countries (and operators) that your customers are located in..
Most SMS Gateways can easily be integrated in your software, and will most often provide you with access to all the mobile operators that you require.
I would not recommend using an email to sms gateway if you can use an API, as these are most often less responsive than using a proper API to send messages, where you will get a live connection with the SMS gateway itself, not an email server in front of the gateway.
Examples of SMS Gateway providers:
PSWinCom - www.pswin.com (Note: I am employed in this company.)
Clickatell - www.clickatell.com
HSL - http://www.hslsms.com/
Answer to 1st question: One reason which I can think of that led Gmail and Facebook to follow this trend is the emergence of bogus accounts. Now-a-days, there are use-n-throw email availabe for free like www.10minutemail.com which gives u an email address for 10 minutes. So the use can take such an email address and start a new account in the site.
But in the case of 'sms'-registration, I dont know of any such use-n-throw service provider. So everyone needs to give his own number for registration. This leads to registration by legitimate users.
Answer to 2nd question: This depends on which language u are using. Moreover, you may need a SMS gateway to achieve this.
Since you dont care about the language, try to look for SMS gateway for sending sms through computer or your web server. Some of the cellphone network providers provide an email service to send sms to a phone. For example, you are sending an sms to +910123456789 of 'xyz' network provider, you just need send the sms in the body of an email with the to-address as +910123456789#xyzmail.com
'xyzmail' part of the mail address will change according to the network provider. Plus this option is not found to be reliabe.
check out TeleSign.com
they offer phone verification solutions that you can implement into your website
phone verification is a way to reduce fraud and spam significantly
There's a trust issue here that goes both ways. If you're the provider of a service that can be spammed, you can trust that your users are people and that their email addresses are legitimate. This is probably irrational. Or you can force your users to trust that you'll deal with their cell number information safely. Many users will feel this is irrational.
And then there are people without cell phones (I happen to be one). Most discussions on the web aren't very important, but if you're trying to foster a discussion on anything important, limiting the discussion to people that have cell phones and know how to receive text messages will limit your discussion to the viewpoints of the rich and technologically savvy. If you're providing an important service like email, a texting requirement sets up a barrier to entry and saps the democratizing power of the web. It amounts to shunting the cost of your spam problem onto the disadvantaged. To me, that's unacceptable. Again, though, if your site is just inane pop culture or a marketing exercise, as most are, who cares, go right ahead.