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!
Related
More than a question this is going to be a long story and a call for all those professionals, developers and merchants that are actively using paypal adaptive payments (preapprovals and chained).
I (and my team with me) strongly think that adaptive payments are and have been a great solution.
Since we adopted them in late 2012 we immediately understood the potential and the flexibility of this great set of APIs. The adoption of this APIs in Italy was something like a nightmare in those times. No docs in italian, no support in italian, everything was done in english with one great support person of paypal in Dublin following us in the integration at the phone :) We were pioneers in our country but at the end we finally had our flows done.
Preapprovals + chained payments and the world can be in your hand.
We could do almost anything and this was what we did. A great platform for buying groups that in those last year is expoloding in our country. Today we have dozens of active and happy users (thousands we brought to paypal) and almost one houndred very selected merchants that we've followed step by step with the paypal team in the limit removal nightmare stuff. One, by one.
And here comes the call.
How many are we using them and what will be the future and possible migration solutions?
As almost all of the users of adaptives knows those APIs are well functioning but deprecated since few years. This means that nobody can start new integrations with them but, worst of all, that all those that are actively using them - like us - still don't really know what the future will be. I'm fairly certain that we can't be alone. I'm almost sure that there are other businesses, merchants, developers who have built great ideas relying on those APIs and now that we've given soul and blood for years putting all of our efforts in developing, optimizing, updating and growing our platforms and our communities, we're at a crossroad: to wait and hope or to look for alternatives.
On an app owner view, there's no understandable reason why paypal should shut off those APIs and, infact, till today, fortunately we've heard nothing about a sunsetting of those APIs, however we all know that they have been deprecated and any of us can safely say that there won't be a sunsetting or a forced migration in the future.
So, why don't we start joining our voices to have clear, understandable and certified roadmap and / or plans around this topic?
Talking with the commercial team in Dublin, they say that everything is ok with adaptives and they will continue working for a long time (and this would be great) but, on the other side, talking with the MTS team the view is a little bit different and no so enthusiastic go on mood in the air. Most of all because of the introduction of the PSD2 Directive in Europe.
As many in the European market should have heard, in the last few months another big concern (investing everything in the payments industry) is the PSD2 compliance and maybe just for this directive that the future of adaptives could be involved too.
Adaptives unfortunately are not PSD2 ready and the hope that paypal will put efforts in making them compatible while it is a deprecated solution is very thin.
The strong customer authentication, mandatory in the new rules schema would force the tech team to update all their products but, always on the merchant / app owner / user view, it seems more plausible that paypal will put the more efforts in the new products instead of renewing the old ones.
However, adaptives are both:
a great solution used by a lot of merchants (again, how much we are?!) in the world continuatively draining new users and merchants (for free) to paypal (just for how the adaptives and preapprovals works, in many cases you're forced to open a paypal account and all we app owners have done this for years);
an easily adjustable tool to be PSD2 ready
We're now in a "grace period" for PSD2 and that to make Adaptive payments complying with PSD2 directive wouldn't be so hard: preapprovals are the CORE and if you add a strong customer authentication to the preapproval flow the great part of the job is done. Chained payments made direclty at the presence of the user too, just adding a strong customer authentication should fit the needs and server to server chained payments sould fall in the MIT (merchant initiated payments) that seems to be out of the object of the directive.
Forcing migrations, on the other hand, would result in loosing a lot of customers, merchants, app owners that for some reason can't change the architecture because of the specific business model or because they don't find real concrete solutions in alternative APIs. Fixing it appears to be a better solution.
The call to all the adaptive payments users is to join this conversation and bring your thoughts, just to see if we're alone or if we're a lot with the same issue at the door.
An enthusiastic and happy adaptive heavy user and owner in Italy.
Cheers, Fil
In planning for the future, the best approach would likely be to put together a list of your platform's requirements and expected volume, and contact PayPal regarding: https://developer.paypal.com/docs/commerce-platform/
You can also look at other options
I don't think anyone knows exactly how long Adaptive Payments will remain available as a legacy service for existing integrations, but I would expect it will be long enough for you to set up a new one that users can migrate to
I'm searching for a shopping cart or web store framework that supports multiple vendors.
There are many, many shopping cart frameworks out there: that page lists couple of hundred. In spite of the comparisons on that page, supporting multiple vendors isn't a comparison item, probably because it's a rare requirement. Separate to that page I have evaluated a few of what appear to be the top frameworks, and none that I evaluated supported this feature. Which carts would you recommend?
Commercial is okay, although I would prefer open source.
Platform (Windows, Linux, ASP.Net, PHP, Ruby... Minix, Fortran... :)) doesn't matter.
A system
where I manually add vendors who request it (instead of them freely
being able to sign up) is also okay, if there's a store where that's
possible but freely joining up isn't built in yet.
Rationale: I'd like to create an app-store like website. "App store" is a close analogy: it won't sell apps, but it will sell digital goods and I'd like anyone to be able to sell their item on the store. It's this second requirement, multiple vendors selling through the store, that I'm finding hard to satisfy.
I've used multiple shopping cart frameworks (a lot of them broken), and my favorite (which just so happens to support multiple vendors) is PrestaShop. It's free, open source, and suppports all that you asked for. Is this the framework you were looking for?
-JXP
The Wikipedia page you cited lists multiple vendor support as a column in Other Features, along with features that are pertinent to your search.
This question otherwise requires domain knowledge and likely requires multiple answers. The best I can do is offer the bounded set of software that competes directly within this space, at least according to Wikipedia.
The easiest solution for achieving your stated goal of allowing multiple people to sell on your site while exercising fine-grained control of who can and cannot do so is perhaps using WPMU's MarketPress in tandem with BuddyPress or WordPress Multisite. I'm not a die-hard fan of WordPress, per se, but that might be an expedient way for you to get to a minimal viable product and to validate your idea before shelling out the time and/or cash to custom build it from the ground up, and/or labor ad nauseam with tweaking an existing framework. MarketPress is a good plug-in that'll give you many of the features of a full-fledged e-commerce framework... BuddyPress, of course, will allow you to set up individual vendor's with their own sites under your brand. The two work together. More on MarketPress at:
http://premium.wpmudev.org/project/e-commerce/installation/
Another alternative is Jimdo's PagePartners. I haven't used it, but it looks intriguing. I like their design sensibilities, and their stated business ethos. This might be a viable option, too. The caveat being: it's not white label. More info about Jimdo's PagePartners here:
http://www.jimdo.com/pagepartner/faq/
Finally, another interesting CMS to explore is SetSeed. I think it'll allow you to launch multiple sites for each vendor via a central hub you control, and will allow you to maintain your branding within each. How, the,n any sort of renumeration would flow back to you for setting up an individual vendor's store would be up to you to figure out... This is a fairly new CMS and it looks like it's evolving smartly and rapidly. If you require some customization of it, to approach more specifically what you ask for, now might be a good time to reach out to the developer...but you might be able to think of an effective way to adapt it for your use right out of the box.
http://setseed.com/multi-site-cms/setseed-hub/
Unfortunately, none of the above is open-source--but, again, the ease by which you could get to a functional site approximating your idea may off-set that drawback. Jimdo is an open-source contributor, however. So, maybe even an e-mail to them might be a fruitful dialogue to begin. If anything, check out each of the above, and it may influence how you search for other solutions, and will at least provide some models in your own thinking or with other developers. The shopping cart is an integrated feature, I believe, in all of the above cases. With regard to giving your vendors the capacity to deliver digital goods (e-books, mp3s, etc.), check out Fetchapp.com. Very cool app. Very easy to set-up...could probably be rolled into one of the above frameworks. The frameworks would handle the issue of individual vendor profiles and/or sub-domains.
I have a website where people do simple cognitive psychology experiments. Currently, people volunteer. To increase numbers of responses, I would like to offer micropayments in a manner similar to Mechanical Turk*.
My question is, What would would be the best system to use to make these payments? I would guess that both paypal and flattr would be options. Has anyone with experience with setting up a micropayment system like this be able to offer advice?
cheers,
Mark
*I am not thinking about using mechanical turk itself, just because I do not think I would be able to control the web based studies exactly I would need.
Flattr would work in your scenario:
Each person doing the test would need a Flattr account.
They’d need to login with their Flattr account on your site (like on fundd.de) or connect your site with their Flattr (easy with OAuth).
Once they’ve taken the test you manually Flattr them and by controlling your monthly budget you control how much each click is worth.
Our API makes setting this up fairly easy and straightforward http://developers.flattr.net/
Downsides:
Required to sign up with an additional service.
Flattr currently caps monthly spending at €100 so if you have lots and lots of testers you’d run into problems of making the payment high enough. We are reconsidering this, at least for users in good standing.
Monetary incentives for testers bring in a different crowd and can influence the results of their tests but you probably already know that.
Cheers,
Teller
PS. I work at Flattr.
I've done quite a bit of searching for a CMS platform or robust framework that will perhaps facilitate the management of signup and subscriptions right of the box with a Twilio tie in.
Thus far I've only been successful at finding how many startups have been funded by the Twilio fund, who's building the nextgen voice enabled app, and various other things of that nature vs any real meat. Seems that there's a dearth of meaningful information without applying a plethora of negative google filters to reduce matches and even then it's still not giving anything real meaningful wrt my search.
So, I'm hoping that someone may have a better eye on the lay of the Twilio landscape as far as already existent systems go that can handle the bulk of needs that exist for a "regular" CMS esque site that needs to also handle subscriptions and e-commerce related tasks.
Hitherto I've just planned to build something out myself, but I wanted to do a sanity check before I spend a lot of time that could perhaps be obviated.
My suggestion would be to find a CMS that does everything you want (except the twilio links), on the platform you want, and then just add the Twilio stuff in. Twilio is simple to use, and should be simple to add-on to most open source CMS's. It'll probably be the easiest part of the project....
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