I'm trying to implement Paypal Pro Gateway to my e-commerce. I created appropriate account for developers and sandbox.
My problem is that I almost always get the "Success" or "SuccessWithWarning" respond. It's wrong in my opinion because e.g. I use wrong "expires on" (for card) or information for buyer (I created one).
My seller gets new payments but the balance for my buyer is still the same.
Should not sandbox validate data like that? I don't know in other way how to test my form.
The sandbox is left pretty open for testing purposes. Unless you use an expiration year prior to the current year it'll pretty much accept anything as far as that goes.
If you want to test specific error conditions you can do that with "Negative Testing".
Related
This is a project I'm working on for use between people at my university.
The idea is simple, it's a website where people can submit anonymous comments to other people based on a unique identifier, which is just a random number. People sign up with their unique identifier and their phone number, which would be saved together. Other people hop on the website and submit a comment with the unique identifier, which is sent via SMS to the corresponding phone number.
Conceptually I feel like this should be easy, the website just searches a table for the identifier and then uses an SMS API to send a message to the associated phone number. Also dynamically adds new lines to the table as people register.
I am real new to web development (if you couldn't tell), but I'm not afraid of a little code so I'm figuring it out. My problem is I have no idea big-picture-wise what building blocks I need to connect together. I think I found a good service called Twilio for the SMS API. I think I need to pay for web hosting, but do I need to rent server time? It's a real simple operation but the data also needs somewhere to live. I want it to be a long-term installation so I don't want to host it myself.
I would be very grateful if someone could real quick make a shopping list of the components I need to make this happen, or just any other tips if you've got 'em
I've been working on a secure shopping cart and checkout for a website. I'm using PayPal, and I'd read that PCI requirements aren't as much of an issue if we don't store card data on our site, so if possible I'd like to avoid that.
HTML buttons seemed like a promising option, but upon further investigation, it seems like maintaining control of active user sessions may not be possible. Below are my sources that seem to confirm this.
PayPal button return url usage
delete session variables when session id is known but not able to start session
PayPal payments pro is mentioned in the second post, but I'm wondering if it or anything else meets my 2 design constraints as they're implications for the implementation don't seem to gel very well.
If they are losing session data when returned from PayPal with a standard button then they have something else going wrong. That should not be happening.
That said, if you're comfortable working with APIs I always recommend Express Checkout and Payments Pro.
If you prefer REST APIs you can use that for PayPal payments and direct credit card payments.
If you prefer NVP / SOAP you can use the Classic API.
In any case, keeping session data alive won't be an issue, and as you mentioned, as long as you aren't storing any credit card data on your server in log files, in the database, or anywhere then you won't have to worry about PCI compliance.
So I'm trying to implement a payment solution for my website and after quite a bit of research, I'm still lacking a complete solution. I'm running Laravel 5.0 and need general shopping cart payment functionality. I thought I would post this to try to create a reference to help others that may be having this issue. I got as far as getting test transactions into the Paypal sandbox and that's where the brick wall has seemed to come in, but a complete overview would be helpful. I’ll list my issues that I need to overcome in order to issues some run into.
Issues needing to be resolved to complete the payment solution implementation
My biggest issue with what I've seen has been receiving the
notification of successful payment processing back, but I'll walk
through what I've seen thus far. I'm not sure how to set up a listener or other methods of detecting a correct payment processing
Dealing with Credit Card information when I’m trying to avoid it
for the time being – I’d like that to be done on the gateway website
Potentially kicking off some of the calls to these APIs in Laravel
when the user checks out
I’m trying to move items to my server, but the development is being
done locally which creates an added issue
The options
There’s simply Paypal
I’ve taken the basic form implementation as far as getting payments into Paypal, but I can’t seem to get payments out. I’ve tried the returnURL and that doesn’t seem to work
I do not necessarily like this option because it seems to be leaving a lot of information in the form that would seem to be better kept private on the server
I’d like to use something complete on git but I seem to find the documentation incomplete
https://github.com/thephpleague/omnipay-paypal
--Not sure how to implement this in laravel
https://github.com/ignited/laravel-omnipay
--doesn’t appear to be being used
https://github.com/net-shell/laravel-paypal
https://github.com/anouarabdsslm/laravel-paypalpayment
--The card information is not intuitive here as that’s what going to
paypal’s supposed to manage
It would be nice to use Paypal express but I don’t see a ton of resources specifically for that.
There's Aimeos.
I don't necessarily feel safe with manually implementing the vsrf
protection and it doesn't seem to offer that much more on the payment
front than
I’m open to others that are complete and charge similar fees to Paypal
Stripe doesn’t work for me. I’m not doing a basic subscription
Any complete thoughts would be greatly appreciated as documentation left short has caused issues in this case. Thanks!
This PayPal PHP SDK will make all of the PayPal classic API calls very quick and easy for you. It's available on Packagist/Composer and can be applied to Laravel very easily.
It supports Express Checkout, Payments Pro, Invoicing, Transaction Search, Transaction Details, Refunds, etc.
This is done in Laravel 4, but I had begun this "PayPal Glass" project a while back to show how the class library / sdk can essentially replicate everything you can do within a PayPal account. Here it is running on my local test server.
So yeah, that SDK should be able to handle everything you need to do with PayPal inside a Laravel project.
I'm using the Paypal 'Express Checkout' option in Magento.
(I'm not using any express checkout buttons, it's just because I was having problem with returning from Website Payments Standard).
In Paypal's Website Payment Preferences, I've set the 'Contact Telephone Number' field to off.
I've also made a number of changes on the Magento side to make telephone number optional
(as per this post).
However, the telephone number field still appears during Paypal checkout, and is mandatory. Obviously, this is potentially going to cause customers to abandon the transaction.
Initial response from Paypal support is that the telephone number is always mandatory, that the preference setting only controls whether or not the value is returned to the seller - this doesn't sound right to me, since it makes the setting largely useless.
Given that Magento usually requires a phone number, I'm wonder if possibly something in the Magento Paypal API call is overriding the default setting?
There must be some way of making the phone number optional?
Edit:
It would appear after further contact with support, and some more digging, that despite the description of the parameter, Paypal will always insist on a contact number for non-Paypal accounts (i.e. paying directly by credit card). This applies for Website Payments Standard and Express checkout at least, possibly more.
The 'Telephone number off' parameter then controls whether the phone number entered is returned to the store.
This strikes me as daft. If I'm on a checkout somewhere and asked to enter a phone number,I don't particularly care whether it's Paypal or the merchant asking me for it, I'm not going to be happy about it and quite possibly abort the transaction, especially if it's for a site I haven't shopped with before. I don't even see why Paypal need the number - if there's a suggestion of somebody fraudulently using my card I'd expect a call from my card company, not Paypal. I'd probably hang up if someone claiming to be from Paypal called me.
Plus given that is the way it works, they could have made it a lot clearer by pointing out the the 'Phone number off' field only applies some of the time
/rant
Have you tried setting the phone number option to 'On (optional)'?
I employ email validation to grant people full use of the site. The trouble is, sometimes these emails get spam-boxed, or never arrive, so I get many people complaining that they cannot confirm their account.
Was wondering if there are other (creative) ways to offer secondary validation option to users who didnt get the validation. Its a free site, so I dont want to ask for credit cards, or mobile #s.
The purpose of this is to make abuse of the site less rampant, since we ban a lot of people, and they come back with dozens of accounts to prove something. Spam/robot registrations are not an issue (right now).
What we started doing recently was letting members send us an email to a special email address. We give them a hash code, and all they have to do is put that code somewhere in the subject or the body of the email, and send it to us. We have a cron job running in the background that gets those emails, parses the subject/body looking for the hash, and if found activates the account.
It doesn't work 100%, because some ISPs also block their users from sending us emails, but no solution would work 100%.
Based on your comment in Rob S.' answer, it sounds more like you want to identify situations where the same browser is creating multiple accounts rather than confirm that what's at the other end is human.
Dropping a cookie in the user's browser can be very helpful in finding the repeat offenders, especially those not savvy enough to clear their cookies or visit while in private mode. Some forum software like vBulletin does this and can notify the administrators when it happens.
Another alternative might be browser fingerprinting, which is where you use a bunch of the information provided in the HTTP exchange. An example of this is the EFF's Panopticlick.
Just got a "fun" new way to annoy your banned people a bit.
once you ban them (I guess you close the account and ban the IP). Then log their browser agent string with their IP and screen resolution.
If there is a match when showing the website to them. Just remove the registration link/page. Dont even show the link to the page, as it might piss them off. Dont explain why its gone. Just keep it gone, eg. for 3 weeks or 2 month.
That way they dont have a cookie on the browser to remove, they cant find the registration so they cant know WHY they cant make a new account.
Secondly, if on a school or something (dont know how old they are), the other existing users will still be able to login to their accounts as its ONLY registration that has been removed. Not login.
How about that? is that clever enough?
Basically what you're looking to do is separate the humans from the robots. There are two primary ways to do this:
1) Require users signing up to check boxes and type a word spelled out in an image captcha. These are usually very difficult tasks for a computer to complete.
2) Allow users to sign-up using their account from a different site such as OpenID or Google assuming that anyone who has one of these accounts is a real person.
I recommend combining both methodologies.
Good luck!
There are unlimited ways of doing this.
You mention mobiles and free, but if you have access to a SMS-gateway, you can receive SMS-messages for free (but might need to pay some sort of monthly subscription though). But show a dynamically generated code the the current user. Store this code in "his session" and do an ajax check each 15-30 sec to see if the sms-code was received by the gateway. If so, accept the account and let them registrate. This would requiere the gateway + your users to have a personal mobile. Enough about mobiles...
Make a question or more that is randomly generated. Use pictures/tokens instad of tekst so that the user has to press the correct image in correct order to perform some sort of answer.
Could be like a jackpot-machine with 3 cells where the images are randomly placed and generated inside dynamic named files, so that robots cant analyse the names to guess the right answer.
You mention e-mails to be easy to spoof. Yes indeed, but what if the emails would come lets say each week containing some sort of "important info" that the user would need to read/use on the website to continue. Once the account hasnt been used for a certain time (lets say 3 month, kill it)... and you could also say to have a "free account" you must accept that we send you 1 mail pr. month that you need to activate within 1 week. If you dont, we are free to close/delete your account details.
... and many more
I dont know what you want to "protect", but if its for gaming, then dont let the gamers have "extra levels/weapons" until they have provided a certain amount of these codes OR paid for access OR validated by phone or something.
Thats my first 3 ideas, I think the possibilities are unlimited. The main issue here is, make it too hard to validate yourself and the users go away unless your site is REALLY worth it.
You might think of the much used "Free forever (but limited)" approach way of selling stuff these days on the net. The users can make as many accounts they want, but the licens is still only "single/small/basic". Once you get more experienced, you get more features or you might just upgrade by paying... at this time you know WHO is real and WHO isnt.
My point is, dont over protect. Just design with the mind of spammers will always find a way in, no matter how good you protect it. Those giving up first are your real users/customers.
I would rather spend time on making this product/website/game so great that EVERYONE wants to pay for an account after a while.
Lastly from real life... there are COMPANIES in China with kids employeed to play World of Warcraft with one purpose. Harvest virtual gold and sell it on Ebay to other western players who pays with real dollars. Its not allowed according to the gamelicens and their accounts/gameslicenses are constantly getting banned. But it gives them so much income so they have calculated with this and they just buy new licences and continue.
So if EVEN Blizard(WoW creators)
doesnt have enough power/money to keep
fakes out of the game, how do you
expect to do much better? :o)
Usefull answer?