The paypal IPN simulator does not seem to include charset variable in the POST to notify_url. My code currently fails because it assumes the charset should always be present. NOTE, that so far I noticed this issue only with simulator.
Is it optional? If so, then what should be the default encoding if not present?
If it is not optional, then how to have simulator send the charset out?
If someone could point me to the documentation that confirms his point it would be even better!
Thanks in advance
It's listed under Transaction Variables, which means it should appear in all transactions, and it's not described as optional. However the PayPal documentation and the IPN simulator are known to disagree in other respects, for example date formats. You should treat it as optional for the purposes of testing.
But don't do too much testing with the simulator. It's really only good for establishing that your verified callback works in my opinion. You ned to do real testing and your research into what fields are present etc using sandbox accounts.
Related
I have a site making calls to the PayPal sandbox. This has worked fine in the past. Today, all of my calls are returning INTERNAL_SERVER_ERROR. I am using the Node.js paypal-rest-sdk module to make these calls.
The debug ID of the transactions are 38ddafc521580, bc93a6d0f3b60, and fb3f7b74697c9.
On a related note - I don't see anywhere on PayPal developer support where you can directly ask for help with these issues; PayPal seems to just point to StackOverflow. Is that correct? Seems like I should just be able to log into the PayPal developer portal and ask for help with specific debug IDs, or at least see some more detail for those transactions on why they failed. Using StackOverflow for this doesn't feel "right" to me...
UPDATE: An update was pushed out just now that should resolve most of the external issues. Can you all please let me know if you are still seeing problems? There are a few outstanding problems in the cleanup, so I want to make sure they aren't impacting anything.
Full disclosure: I work at PayPal
I just ran a test against sandbox and have confirmed that there appears to be some downtime. I've notified the sandbox team of the problem and have provided your (and my) debug ids for them to take a look. We're on it and will hopefully have a resolution shortly.
From the support side, you're correct, there is no forum system for technical integration issues. For problems with downtime, you can report those to the technical support team at https://www.paypal-techsupport.com/app/ask/session/L3RpbWUvMTQ1OTM0NzAxNi9zaWQvVC00anZNTW0%3D, or contact support directly from https://www.paypal.com/selfhelp/home. You can always reach out to the merchant technical support Twitter handle at https://twitter.com/paypal_mts as well.
For integration troubles, that's where SO would be best, where we can help work through code issues.
The server errors have gone away, but they've been accompanied by a massive uptick in customers getting a message that reads "the card you entered cannot be used for this payment". So they're still not able to make payments. We had the first couple contact PayPal, but we've gotten so many that it seems like it's not a coincidence. Do we really need to refer people to PayPal (which will cause them grief, surely, and cause PayPal to get a bunch of extra calls) or is there still something going on?
https://developer.paypal.com/docs/classic/api/country_codes/
lists the country_codes available for use with PayPal Express. That's fine and dandy, but not exactly code friendly! I see no actual API call that presents my server with this information. What am I missing? Do I really have to manually type in that list and manually check periodically to make sure nothing's changed?
Well, according to PayPal support... nope, only way is to manually do it. Granted, geopolitical scenes aren't changing THAT rapidly, and PayPal probably tends to align itself with the more stable list, but still I expected better. I should be able to set a cron that checks periodically against a nicely formatted JSON, etc, so I can automatically update the country list used by my sites. That way 5 years from now I don't have to find out that 4 years earlier I started unnecessarily missing business because PayPal opened up their services to Antarctica's hot bed of ecommerce activity.
I have a use case in which we need to transfer funds from our merchant account to our customer local bank.
I found paypal legacy api which says it can make ach transfers.
I want to know how secure is using this legacy api and whether this is supported anymore or not.
Any suggestions will be greatly appreciated.
Yes, it still works fine and will continue to work for a very long time. Too many solutions up-and-running on it for them to dump it, and it's also still much more mature (loaded with more features) than REST. They continue to add new features, too, so for REST to catch up it's going to a while.
REST API still needs lot of features, so I don't think that they will shut Classic API down soon.
Does anyone know how to test the callback for In-App Currency Offers that were just released by facebook other than completing the offers themselves? As I need to see if my modifications are correct before I use them on a live app.
Facebook does not provide a code sample or even a clear explanation on how to test.
Unfortunately, there is no option for sending a test callback or anything like that - especially maddening because TrialPay does (or at least used to) offer this functionality for non-Facebook integrations of their product.
There are free offers & surveys, which are somewhat unreliable in their own right, but may be preferable to actually spending money - kinda depends on how much you value your time. Sure, this is less than ideal, but it's what we've got.
Does anyone else find that the documentation of a lot of payment processors have poor or incomplete documentation as to how to use their API? Or it's just plain confusing?
Recently I have setup both PayPal and Beanstream and found that both are either confusing or don't include full documentation.
For example, in the BeanStream documentation, they say they will return a "message_id", which is great, but no where do they tell you what the different id's mean. It also comes with some text, so you can start creating a list, but there is no way to check to ensure you get either a valid one or the one that means it was successful.
Has anyone had this experience?
Edit: I will agree that when you email them they are helpful, but unfortunately most of them are only open normal business hours for general tech support (other than emergency) which isn't always useful as that isn't when it seems like I do my integration.
well, this isn't really specific to payment processor documentation, in that, all things being equal, well documented APIs will help encourage development. for what it's worth, i've worked with paypal, authorize.net, ups, and usps APIs, and didn't find them overtly confusing (not implying that they were a particular joy to get through).
that being said, i wish more documentation was like PHP's. despite it being such a scattered language, the documentation is really quite good.
Having worked with a lot of APIs, not only for payment processors but for lots of other ecommerce related web services, I have to say to that while the docs can be less than stellar, they usually aren't that bad, and if you send them an email or give them a call, they will usually be pretty helpful.
I have found the documentation and code examples from Authorize.net and Nova's ViaKlix very helpful. I stay away from PayPal.
This may not be much help to you, but as you get more an more experienced w/in particular domain the interfaces get easier. By weird twist of world, I've coded a whole bunch of credit card interfaces, and once you kind of get the lingo they all work the same.
The only other suggestion I would offer is to avail yourself of support resources in addition too the documentation provided. We recently worked with a relatively well known payment gateway, and while their documentation completely sucked (by their own admission as well), the support staff was incredibly knowledgable and more than willing to help out/explain.
I've used Realex and PayPal. Realex documentation is fine. Clear and straightforward. PayPal's is absolutely eye-bleedingly horrible. And I'm the kind of weirdo who enjoys reading documentation so much I've been known to read it for fun (I've read through the entire OpenID specificiation, even though I have no immediate plans to use it).
I've only worked with PayPal, but the simple version (where you just set up an HTML form on your web page and submit it with the PayPal button) is super-easy to work with. And if you're looking for near real-time payment feedback, I always found it easier to just write a program to check my PayPal email account periodically, and parse payment details from the body of the email itself.
I've had to use Authorize.net for several sites and the supplied documentation is 'just ok' assuming you are working in the somewhat limited technology sets that they supply sample code for. It was a breeze to get it up and running with PHP but considerably lacking when trying to pull off the same thing in ColdFusion.
Several other sites done via PayPal which IMO was a much better experience.
PayPal is a nightmare when it comes to setting up and testing the test account (Sandbox).
Re: Beanstream you have to login then you'll see the documentation link on the left hand side.
The design is so '90s and they recommend using IE.
Re: Paypal I adapted this code from http://www.php-suit.com/paypal for my Zend Framework project.
Note: you've got to have ssl:// socket transport wrapper registered otherwise (visible in phpinfo()) you'll have to tweak the code to use curl.
Here is how to get the code using SVN
svn checkout http://paypalphp.googlecode.com/svn/trunk/ paypalphp-read-only