Is possible to assign multiple payment plans to a single billing agreement?
e.g.
The user subscribes to 3 different services:
sports magazine - 3months - xamount;
fashion magazine - 6 months - yamount;
music magazine - 3 months - zamount;
I have been looking, and the only option I found was creating 3 different plans, and make the user agree with the billing plan 3 times, which is not practicable.
I might even be seeing this in the wrong perspective.
Thanks in advance.
You need to create the plans only once, then you just subscribe all your clients to that plans... So, to answer your question: NO, it's not possible.
But it is possible the other way around, you can assign multiple billing agreements to one plan.
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 am setting up an online store using PayPal.
My issue is that I can only choose a fixed price for shipping (og percentage based which isn't relevant)
I am based in Europe, so shipping one item to europe or one item to the US is a huge difference, but I can't find a way to differentiate between them.
I'm aware that this is on the verge of being non-code related, but I'm thinking that there might be a way around this using an api or something along those line?
You could calculate the shipping on your side, and pass that shipping about over to PayPal as the amount to charge for shipping. There are several different ways to do this, some of which would depend on how you are currently integrated with PayPal.
I've read everything I've found on in-app purchase and don't know whats the best way to go in order to do the following:
I have an app I'm developing and want to set two paid options + 1 free option in order to access sample content and paid content.
I'd like to offer a paid 24 hour access and I've read this goes against apples TOS. (sorry but cant find the doc now). Says something like they wont allow apps that recognize and restrict content for specific amount of time.
Wondering if creating two consumable items
One Year membership Item
One day access item
Could be a good option and if doing this would be OK with Apple's TOS.
Apple's docs about consumables only talk about games, such as weapons, food, levels.....
Feel free to comment and suggest other ways to accomplish what I'm after.
At first I thought of subscriptions, but I think the shortest subscription term is a week.
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.
I’m trying to implement the following scenario:
User approves a recurrent weekly payment (subscription) for a selected package size
Every week the user can:
a. Cancel a specific week delivery and avoid paying for this week
b. Modify the package size and pay less/more for this time only
c. Add additional items and get charged for them in addition to theweekly package
Looking at the documentation I did not find the APIs that allowing me to modify the subscription according to my needs.
Can someone please direct me to the right documentation or provide a code snippet?
Thanks,
Yossi
I think this is unsupported. You may wish to look into subscription management services like Spreedly and Zuora.com for these use cases.
I don't believe this is possible. I'm trying to implement a similar thing. What I've tried is to issue a subscription modification with a free trial period. But it seems that the trial period parameters (a1,t1,p1) are ignored on a subscription modification. I've found some (unofficial) references that free periods cannot be inserted into an existing subscription, which is exactly what we need.
I'm pretty bummed this isn't supported. I cannot think of a clean way around it.