So I'm building a membership website. The principle is simple in that you sign up for a recurring membership, then you are allowed to register, and the server will be notified of all payments or non-payments so it can keep the membership active or disable it for non-payment.
So two questions, and this is pretty broad since I'm just looking for the right place to start.
Does this require full PayPal SDK integration (I'm using CakePHP) or is it possible to use the simpler Premade solutions - I guess my question here is, is the only way for PayPal to contact my server when a member pays through full integration?
Is it possible to set this up completely on a local host? I'm building the website on my localhost of course it occurs to me that I don't have it connected to the internet for PayPal to communicate with it directly. Are there work arounds for this?
Really just looking for anyone experienced with this type of E-Commerce to chime in. I'm very experienced with PHP so I'm really just looking for a place to start.
How to programmatically (not manually with our PayPal dashboard) bill (every month) a PayPal subscriber of our service for a non-fixed-amount Automatic Billing?
I would recommend PayPal's Reference Transactions to achieve your purpose. Please check below link for its details.
https://developer.paypal.com/docs/classic/express-checkout/integration-guide/ECReferenceTxns/
The Classic APIs aren't going away for a long time. They have way too many solutions currently integrated with it, and the newer REST APIs do not currently support all the features that Classic does. For example, reference transactions are not currently supported in the REST API, so you'll have to use Classic for what you want as of today anyway. They have said they'll be adding reference transactions to REST sometime this year, but I've heard that about other things before and it generally takes longer than planned.
I am personally sticking with Classic for most of my applications as of today.
I want use the titanium module for payments.
I was unable to identify which one is better from below modules
ti.applepay
ti.paypal
What are the features of ti.applepay module?
what are the features of ti.paypal module?
Can any one help me out.
Basically, they are there for different purposes.
Ti.ApplePay is for supporting payments with Apple Pay, using credit-cards linked to your Apple ID or custom ones you add to your iOS Wallet.
Ti.PayPal is for supporting payments with PayPal, using credit-cards or bank debit linked to your PayPal account.
So you could rather support both of them instead of just one, it's highly depending on your desired use-case. Hope that helps!
Recently I looked at the less onerous payment options using PayPal. And considering my knowledge thought of using the Payments Standard Buttons.
Follow the tutorial to create the signature buttons to my system, but particularly did not like having to be managing my buttons on the PayPal website. In this sense, I sought something more flexible and found the PayPal JavaScriptButtons.
I was satisfied with the possibilities of JavaScriptButtons, though concerned about some aspects. For example, my Merchant ID, Product Amount and Currency will be exposed in my HTML. In this way, a user can edit the values of these fields through the Inspection Tool available in the browser, causing potential problems...
Finally, I would like the opinion of you with regard to best practices and possibilities in this scenario.
Already thanks!
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