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
Related
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.
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'm writing a web application that will track incoming traffic to a website and track the origin of the traffic and its behaviour on our site, so that we can get some idea of the return on investment of our marketing campaigns, the actual keywords and their value to us (rather than to google) and the lost traffic, and our lost spend.
Part of this involves looking at the referrer information from the browser on the first page visited. Referrers like Google Organic and Google Paid Search are easy to identify using regex matching to look for particular strings within the referrer (I'm using php's $_SERVER). The same is true for Bing, Ask, Yahoo, LinkedIn and Facebook.
But, I'm having a problem with one particular source - Google Content Network. Sometimes traffic coming from these ads has a nice link that begins http://googleads.g.doubleclick.net/pagead/ads?
which is obviously easy to code for. On the other hand, the traffic from sites showing our ads sometimes comes with the Referrer of the site itself as though it were a hard coded link. This second hard coded type link is causing problems as we can't differentiate it from regular referred traffic.
So, other than tagging the urls our ads are pointing to with something like '?source=gcn', or scraping the referring page to look for a hard coded link or a google ads iframe, has anyone got any magic sauce to overcome this issue?
Thanks in advance
Ross
So, it seems I've been looking in completely the wrong place for a solution to this.
In a nutshell, the problem is that I need to access Google PPC information regarding visitors to my site but google doesn't always pass this information along in the referrer and certainly is problematic where Display Network appears on a page using javascript to insert it directly into the dom.
Where should I have been looking? Google Analytics. The __utmz cookie contains a wealth of information regarding the route that traffic got the site... including whether they came via PPC / Organic or Display Network and the search terms (where applicable) that got them there.
See the following page for more information:
http://code.google.com/apis/analytics/docs/concepts/gaConceptsCookies.html
Who'd have thought! Anyway, there is some great documentation on what the cookies do and how they are constructed. Problem Solved.
Ross
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.
I want to write a program that analyzes your fantasy baseball team and notifies you of recommended actions, possibly multiple times per day. The problem is, you aren't playing fantasy baseball on my site, you're playing on yahoo, or cbs, or espn, etc.
On the majority of these sites, fantasy teams and leagues are not public, so you must be logged in and a member of the league to see the teams in the league.
All that I need is the plain html for the team page on each of those sites to be sent to my server, where I can then parse and analyze the file and send user notifications.
The problem is that I need username/password combinations to easily get this data to my server when I need it, and I think there will be a lot of people who wouldn't want to entrust their yahoo/espn/cbs password to me.
I have come up with several possible ways to solve this problem:
The most obvious way is to ask for their credentials for the site on which their team is hosted. Then I could just programmatically log in and request the data I need. I'm guessing a number of people would be comfortable giving me their credentials, and a number of them not so much.
Write a desktop client, which the user then downloads. The client would require their credentials, but it could then basically do exactly the same thing that the server based version would do, log in, request the page, and send the page back to my server. The difference being that their password would never need to leave their desktop. Their computer would need to be on, and this program running for this method to work.
Write browser add-ons that navigate to the page I need, use the cookie that is saved from a previous login to login to the site, and send the page back to my server. This doesn't require my software to ever ask for their password, but if the cookie expires I am hosed, and I don't know much about browser add-ons besides.
I'm sure there are other options, but these are what I've come up with so far.
I have two questions:
1. What are the other possibilities for this type of task?
2. Am I over-estimating people's reluctance to give me their yahoo (for example) password? Is option (1) above the obvious choice?
It was suggested in the comments that I try yahoo pipes, and that looked like a promising suggestion so I explored it a bit. Having looked now at this, I don't think that is an option. So, it looks like I'll be going with option 1.
This is a problem I grappled with a couple of years ago when I wanted to do the same thing. Our site is http://benchcoach.com and the options we were considering were the following:
Original we considered getting the user's credentials and login. We would then log in and scrape their league and team info. The problem there is that after reading several of the various terms of service, this would definitely be violating the terms of service. On top of this, Yahoo! was definitely one of the sites we were considering and their users have email (where we could get access to sensitive data), and Yahoo! wallet. In addition, it would be pretty trivial for Yahoo/ESPN/CBS to block our programmatic logins by IP Address.
The solution we settled on (not 100% happy but it does seem to work) was asking our users to install a bookmarklet (like delicious, digg or reddit) which would post the current html page to our servers, where we could parse the data and load our database. If they were still logged into their Yahoo/ESPN/CBS account, we would direct them directly to the pages, otherwise, those sites would prompt for authentication. Clicking the bookmarklet once more, would post the page to our servers.
The pros of this approach was that we never collected anyone's credentials so any concern of security would have been alleviated. Secondly, it would make it impossible for Yahoo/ESPN/CBS to block access to our service since we would never be connecting directly to their servers but rather the user's browser would be posting the contents of their browser to our server.
The problems with this is that it takes 2 clicks to post a page to our site. For head to head leagues, we needed 3-4 pages so it would take our user 6-8 clicks to sync their league to our servers. We're still looking at options for this.
One important note is that I ran into the product manager of the Yahoo Fantasy Football site at a conference a year ago. We talked about how we were getting the Yahoo data, and he confirmed that getting credentials would violate their TOS and they may stop us. While I don't think they would have, it would have made it hard to invest time and energy to develop this only to have them block our site and pissing of users by closing their accounts.
A potentially more complicated answer could possibly be done with (for example) yahoo pipes.
Hypothetically, you create a pipe which prompts the user for their credentials and provides them with a url which contains their scraped data. They enter this URL in their site, and never have to provide their credentials directly. Even better, for the security-conscious, it would be possible to examine what the pipe was actually doing before entering any information.
The downside would be increased complexity (as well as you'd have to write and maintain the pipe). Having said that, you could provide a link directly to the published pipe from your site, to make things as easy as possible.
Option 1 is the obvious choice. People who trust your site will provide the details. There is no other way you can login to other site while screen scraping.