I'm using Chrome and I am trying to create a Payflow Gateway Account. I went to https://registration.paypal.com/ and followed all the steps to register. But when I was in step 3 (there are 4 steps in this step), it requires me to log in to the Paypal account. So I entered the email and the password, moreover, it requires me to enter the code in the captcha.
But I just saw a broken picture. I used the listen option but I can't hear anything! Can anyone explain to me why this happens, is it because my network is weak or because my browser is having a problem (or because of Paypal). I have also tried to enter a random code but when I was in the Product Selection / Billing step, I can't click on the checkbox and the button.
Is it because of that random code or because of another error? And if anyone can create for me an account, I will be grateful.
I tested the signup, and it worked for me. I was able to enter both captcha and proceed with signing in.
If you are signing up for a business product as serious as the Payflow Gateway, you should have the resources to do the signup from a different computer and internet connection. Even a friend's laptop at a coffee shop is likely to work around this issue you are experiencing.
As an aside, I do wonder why you are signing up for Payflow, which was a great payment gateway in its time -- but is now almost 20 years old. Do you have a specific need to integrate this?
There are better options available, like https://www.braintreepayments.com/country-selection
Or if jut want a simple credit card checkout, the black debit/credit card button of PayPal checkout: https://developer.paypal.com/demo/checkout/#/pattern/client , might suffice
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 have a website(PHP) which has payment functionality with recuring/autopayment feature where user will enter their credit card detail once for shopping and from next time onward they don't need to enter their credit card detail again. Credit Card detail will not be saved to my database but will be saved in payment gateway with unique id/reference. I just need to use reference id for payment whenever user do shpping.
Earlier, i was using authorize.net payment gateway with its CIM(Customer Information Management) feature for auto payment which was working fine but now my client does want this payment gateway. I want some alternate payment gateway which support CIM feature.
If someone has already done same kind of stuff then please help me.
Authorized.net is the best option, because of reputation, costs and developer friendly environment. However there are alternatives as stripe, 2checkout, braintree...
So I'm writing a mobile app and have reached a point where I need to allow users to register a username. I'm doing this by asking for an email address, username and password.
Typically, it's been normal to set this sort of thing up on the web by having the user confirm his email address by clicking on a link sent to his inbox.
Needless to say, on a mobile app this is a bit clunky as the user will be redirected out of your app and into his browser.
So I had a look at how other mobile apps are doing it (WP7) and was surprised to see that DropBox and Evernote both allow you to sign up without confirming your email address. The end result of this is that I was able to sign up with completely bogus email addresses and/or valid email addresses that don't belong to me.
I assume this is done on purpose.
Your thoughts?
I came across the same issue when writing a social networking style app. I chose to have the user create a username and then provide and email and password. I do not verify the email address and I've never attempted to send any email to them (yet).
What I would suggest would be alternate ways to validate a users email address. My app allows users to do Facebook Connect. All they have to do is log into Facebook, and the app talks to Facebook to confirm that they are using a valid email address. No need to verify it with a URL in an email.
I believe Twitter has a similar service and there may even be a few others that provide an API.
I've also discovered that a lot of people just want to tinker around in the app and not create an account at all. It's definitely a balancing act
I'd say it depends on your app and how important it is to ensure users have valid email addresses. In an app I'm creating now, we want to discourage users from signing up with multiple bogus accounts (because our system could be gamed that way) so we're not allowing users to log in until their email address if verified. On other sites however, it might not be such a big deal so why bother users with that extra step?
As for a mobile device, I don't see why you can't still send a verification email that sends them to your website to verify their email address. There are plenty of mobile apps that also have a website users can log into to manage their account.
Another option is have multiple "states" for users. Before they validate their email, they are in a "pending" state. Once they click it, they're in an "active" state. If you store the createDate for the user, you can periodically remove pending users older than 1 week (or however long).
The bonus is that you can easily add more states, such as suspended or deleted.
Personally, I wasn't too happy for users to create accounts with any old email address.
I think a few decent options are:
send a confirmation email with a link that uses a Custom Url Schema to redirect back to the app (although this is only good if they use the link on the same device)
send a short PIN in the email for them to enter back in the app.
send a confirmation email with a web link, have your server confirm the valid email/token, and have your app check the account status either periodically or with some sort of realtime tech like SignalR or Firebase.
I prefer the last one, although hardest to implement. A user might well have their phone in their hand and their laptop next to them, register in the app and try to click the link in the email that just showed up on their laptop. I like the idea of the app then just "knowing" that they've validated.
Do you have a web server? Write a web service that does the validation for you on the server side, and sends back the result.
Either you can use some platform, such as Facebook connect as #Brian replied above, or you may give users a reasonable timeframe to verify, for example, a few days or even a week. After that, the account gets removed.
You can even have your app issue notifications to remind the user to verify his account (such as every day, or on the last date of the verification.
Don't ask for email confirmation on mobile and allow the user to use the service. When the user is using a PC, then ask the user to confirm his email.
I won't defend my recommendation because most of the solutions here are valid. There isn't one correct way. You asked for ideas and here's one.
A good strategy is to allow people to use as much of your app as possible given the amount of data they've provided.
For example, in the case of a newsreader you might let someone browse your app without registering, then require an account for offline syncing, and a verified email for alerts. Always give people a good reason to take the next step, and build engagement first, then people will forgive you pestering them later.
I've registered one app on Google App Engine, and it works fine. I want to register a second app now (on the same account), and every time I click the "Create an Application" button, I get forwarded to the SMS account verification page. My number's already been used to register my first app, so of course it doesn't work. Has anyone else seen this? I'm using Google Apps on my domain, that seems likely to matter here.
Oh, and I've seen a number of "workarounds" for this issue - wife's cell number, prepaid cell from Wal-Mart, that sort of thing. I'm hoping for something a little more sustainable (for my third app, etc.)
Thanks!
I know that this has happened to others. It seems that the app engine team sometimes has to address these manually. Try filling this form out...
https://appengine.google.com/waitlist/sms_issues
You should be able to create 10 apps per account, but you can only have one account linked to each phone number.
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.