we are using Paypal Pro's Hosted solution for payments and finding that a lot of orders aren't completed when customers go to the payment page (one customer complained that they could only select Australia and United States for the shipping country!), we've found a lot of inconsistency with Paypal's service and 25% of orders aren't complete.
Worldpay seems like good alternative, does anyone have experience of both Worldpay and Paypal, is Worldpay more reliable?
Is Worldpay's documentation any good? Paypal's is terrible.
Are there any other alternatives?
We're trying to keep it simple by having the IMA and gateway all in one and process around £3k-£4k of payments a month.
Take a look at Avangate - www.avangate.com
This question is a few months old, but I'll answer it anyway.
PayPal's documentation is quite bad, but WorldPay isn't much better. In fact, they have documentation in place for somethings they don't yet support, and it can be difficult at times to figure out whether it's your code or that the service does not exist. This applies, in particular, to recurring payments.
We used to have PayPal, but we switched to WorldPay. My personal view is that PayPal is more flexible. WorldPay has its limitations - especially if you are selling SaaS and need some real flexibility, and as things get complicated for us, we have to get creative to work with it.
But at the end of the day, WorldPay support is a million times better than PayPal. For us, they are slightly cheaper (and will become cheaper this year hopefully as we have done some volume with them). Support responds to emails pretty regularly if not a 100%. Plus you can call. They're even happy to look at server logs and tell you why or how something got lost if it got lost.
To sum up and answer your question:
On Documentation - they are almost the same as PayPal.
On service, they are MUCH, MUCH better.
On price, they will eventually get better and hold money for only 48 hours before it hits your account (this is negotiable, btw).
Depending on what you want, there are other options available. If you want recurring payments and your IMA and PSP to come from one source, WorldPay is a good alternative, especially if you are based in the UK.
If IMA and PSP being the same is not important, I suggest checking out SagePay (UK) and Authorize.net (US) - IMHO they are both quite good. SagePay has its limitations, though, especially if you want recurring billing.
Please note, the above is based on my experience of selling customized, subscription based SaaS, not an online store.
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
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.
We're offering Paypal checkout as a way to purchase items on our website, and offer our goods internationally. Our problem is that when a user selects Paypal there's no easy way to set a shipping cost based on their location...
For instance if a user is from the USA, his/her shipping cost will be $3.85
If a user is from the UK, his/her shipping cost will be $5
Aside from having users pre-select their country (which seems pretty flimsy because they could just select domestic, then change their address to something international) is there a way for Paypal to adjust shipping based on user's shipping address??
Does https://www.paypal.com/cgi-bin/webscr?cmd=xpt/shipping/EasyCalculateShipAndTax-outside help at all? It describes a way to (within PayPal's interface) pre-set shipping costs for different destination countries.
It looks like this article and thread may have fallen into the abyss but I thought I might chime in and give my two sense.
The challenges I have struggled with around international sales are really two parts.
First, and I won't dive too deeply as its more related to the merchant service and credit card processing side of the business, but merchant services and payment gateways have yet to deploy a system that roots out fraud. The unfortunate fact is that assuming a customer abroad uses a fraudulent credit card it will almost certainly slide through the gateway and merchant services as a good sale, then deposited into the retailer bank account, only to be identified as suspicious weeks later. Naturally the banks reach in and extract the fraudulent funds and leave the retailer holding the bag.
The other side of it the logistics, and more precisely the competitive or noncompetitive pricing leading to sales.
Amazon.com has been a steamroller throughout the marketplace and many would argue the vast benefits it has brought with it byway of competitive forces. Amazon has been a God send to many particularly small businesses who without the Amazon marketing advantage would be little more than a doodle on the back of a napkin at the looking drinking hole. They are great at reaching a domestic consumer and their impact in the larger international space is growing fast.
But for those of us who try to sell through our own website, foregoing the massive commissions paid to the behemoth, it can be a little daunting to tackle the international shipping.
First, the rates. Getting rates that compete is tough. Have you seen the retail rates from Fedex, DHL, or TNT? They are insanely expensive and unrealistic for a retailer. I negotiated rates with UPS, TNT, and DHL, but the results were not good. Not enough volume to drive real discounts. This is when competing with Amazon makes you feel really really small.
I'm measuring the percentage of lost business against incremental increases to shipping rates and its extreme.
Frankly, as a seller who has evolved through the past decade of Amazon ups and downs I've learned through heartache and loosing lots of money, whether through BiG Bank Merchant Services who take no prisioners or the hefty costs for international shipping. Where I have moved my inventories is away from Amazon and FBA and into fulfillment centers capable of handling all my logistics issues.
For instance, reverse logistics. For those of you who may be new to the term, it refers to the process of returning merchandise from end consumer to merchant. Managing this with international customers can be complex. Additionally, fulfillment centers offer volume rates I'm not able to get on my own with the aforementioned carriers; UPS, FEDEX, DHL, TNT. Rather, the fulfillment operations I work with tend to be flexible and understand the cost correlation associated with international sales.
The fulfillment companies I have used are:
Good - Amazon FBA
Better - Shipwire
Best - Newgistics
I won't ooze over any of them, but I'll say that as my requirements have evolved FBA was incapable of keeping pace. With the other solutions I have full EDI integration by and between me and all my distribution partners. Partners that make life a lot more manageable.
As for international shipping rates that beat retail published rates, check out these international shipping calculators:
USPS
DHL
MyUS
American eBox
``
These will at the very least send you in a direction that makes sense.
I hope this personal recount provides help to those who are transitioning through differing stages of growth.
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I understand payments are a tricky thing, but I'm yet to find a worthy alternative to PayPal. I want to change from PayPal because I think they are expensive and it doesn't work in all countries. Furthermore, I think that the API is sufficient, but could be better. The API documentation, however, is total utter crap.
I am looking for a payment / transaction service that is more developer friendly, preferably with:
A clean and well-structured REST API
Excellent developer tools and a sandbox
Good example API implementations, preferably in Python or Ruby
Worldwide credit/debit card coverage
Rates cheaper than PayPal (or the possibility to choose a payment plan)
I suppose Google Checkout is somewhat worthy, but it requires both the developer and prospective purchasers to have a Google account. Any other suggestions are very much appreciated!
Stripe fits a lot of your criteria — you can accept credit card payments without a merchant account. You also get to control the payment flow without having to worry about PCI compliance.
A clean and well-structured REST API
The API is based entirely on REST — you can even use curl to charge cards:
curl https://api.stripe.com/v1/charges
-u <YOUR_API_KEY>:
-d amount=400
-d currency=usd
-d "description=Charge for user#example.com"
-d "card[number]=4242424242424242"
-d "card[exp_month]=12"
-d "card[exp_year]=2012"
-d "card[cvc]=123"
Excellent developer tools and a sandbox
You can test your payment form integration with test API keys before going live. More info: https://stripe.com/docs/testing
Good example API implementations, preferably in in Python or Ruby
Stripe has official libraries in Python, Ruby, PHP and Java, and there are more community-supported ones here: https://stripe.com/docs/libraries
Worldwide credit/debit card coverage
You can charge all international credit and debit cards with Stripe.
Rates cheaper than PayPal (or the possibility to chose a payment plan)
You pay one standard rate of 2.9% + 30¢ per transaction. Unlike PayPal, there's no extra charge for American Express or international payments. Details here: https://stripe.com/help/pricing
I am an engineer at Stripe. Feel free to drop by our chatroom if you have more questions. You can also email us at support#stripe.com.
I find Klarna to be an very good provider.
They have an easy to use API and they also provide different ways of payments. They also provide a service to let your customers pay by invoice and let you get your money immediatly so Klarna takes care of actually getting the money.
Do you have an objection to using a standard gateway and merchant account? Your bank may resell Authorize.net, for example (I know Wells Fargo does), which has pretty much everything you're looking for. You will end up paying about $40/month in fees for both of these services.
I have used Google Checkout as a payment service as well, and it works fine.
Intuit has a merchant account offering out as well.
Moneybookers - http://www.moneybookers.com/
API Manual - http://www.moneybookers.com/merchant/en/moneybookers_gateway_manual.pdf
First Data
Is international
Integration is easy and developer friendly
REST APIs
Support for all mayor tender types (CC, DC, Gift, ACH, Lec, etc)
Support for all mayor card companies (even European ones)
Many different service plans that adapt to many needs (flat subscription, per transaction volume, per dollar volume, etc)
http://www.firstdata.com
You should probably consider Amazon's "Flexible Payments Service" too... I'm a fan of most of their web services. Not sure offhand whether payees must have an Amazon account to pay or not... but AWS services tend to be well documented:
http://aws.amazon.com/fps/
Take a look at SagePay. I haven't developed against PayPal or GoogleCheckout but the SagePay documentation from the knowledgebase is pretty good. SagePay also have a neat little testing platform.
Depending on your usage they can work our cheaper than PayPal and Google checkout.
http://www.zarr.com/Blog/2009/12/Summarizing-Paypal-Google-Checkout-and-Sage-Pay-as-payment-processing-programs/
Hope this helps
I'm a developer at Payjunction, so I recently looked at ActiveMerchant for Ruby (it can use Payjunction, PayPal, Authorize.net, and some others). If you are looking for a Ruby solution, I like their code, independent of who you use as an actual payment gateway. Don't have a recommendation in Python.