Does anybody knows when this feature will be supported by REST API? I'm really like PayPal REST API, but this feature is very important to me and I believe to many other developers
Thanks
I can't officially speak for PayPal, since I have not worked for them in over a year (and wasn't an official spokesperson then either). However, since they almost certainly won't give you an official answer let me say what I can to help you:
Adaptive Payments (AP) is a product line, not a feature. AP is a bundle of features and behaviors, with an interface designed almost 10 years ago now (before the world converged on REST-style APIs).
PayPal's REST APIs, while named after an interface technology, are in fact also a product line, not a feature. A different product line from AP, with a different set of behaviors and features.
So AP being supported by PayPal's REST APIs is like saying "when will the Chevy Tahoe be supported by the Chevy Equinox"? Wrong question.
However there are two things that PayPal could actually do:
1) update AP with REST-adherent versions of the existing AP APIs. These would not be PayPal's REST API product, but the AP APIs reskinned. However, IMO the chances of this are near-zero for a variety of reasons. Don't hold your breath (or your development) hoping for this.
2) Improve the REST APIs by adding more features that AP currently has but the REST APIs do not. This is quite likely to happen, as part of the incremental improvement of the REST APIs, which PayPal wants to use as one of their primary going-forward integration paths (secondary in importance only to Braintree-based integration paths, if any).
If you can enumerate the specific features of AP that you want to see added to the REST APIs, let PayPal know. They likely won't promise dates for future feature deliveries (unless you are a strategic partner contracting with them to get those additions), but they are definitely actively working through a roadmap of REST improvements.
Related
We are building a Solana based application which will mint Semi-Fungible tokens (for Fungible Assets) let people trade them.
What we want next is to add metadata to this mint through which we are also going to set the creators and the seller fee basis points for royalty payments. We know how to do this and we have done it.
Anyway, the problem is the following: all the docs available on Metaplex we’ve seen are revolving around NFTs, Master Editions, Printing Editions, Auctions, etc. - which is not the case for us as we need to mint more than one token from the same mint.
The most important thing is to manage to benefit from the royalty fees each time shares are being traded on the secondary market. So we don't need auctions, vaults or other mechanisms like these.
Initially, we were thinking about Serum, but we don’t know whether
Serum also takes care of transferring the royalty fee to the
creators when the funds are settled.
After Serum, we’ve looked at the examples in the Metaplex
documentation about Metaplex Storefronts, but, as I said above, that
was really focusing on NFTs, Master Editions, Printing Editions,
Auctions, etc. - which don’t seem to fit our use case of Fungible
Asset. Maybe can this be customized for our Fungible Assets use case
somehow?
Would you be so kind to help us clear up a little bit what approach is the best for our use case and our needs?
Serum v4 (not released on mainnet yet) does support Metaplex royalties (see this commit). It should be released on mainnet in the coming weeks/month.
I am not aware of any other smart contract on Solana which supports this feature. However, you could probably create your own fork of an open source AMM and add a logic similar to the commit above.
As a new developer, I found there are two very similar types of Paypal from Paypal Developer's page: https://developer.paypal.com/home/
For Business and For Enterprise (I understand For Marketplaces and Platforms is meant to be used entirely different use casaes)
I saw "Manage Risk" under for Enterprise -- that seems to be the only difference from For Business -- but even a small business needs to manage its risk, doesn't it?
Can someone give me a high level explanation, when should I use For Business and when should I use for Enterprise from the following perspective?
how much extra functionality does for enterprise offer comparing to for business?
how much extra complexity for the developers to implement the integration comparing to the later?
It's a matter of scale. The product offerings in the Enterprise section aren't designed for or marketed toward small and medium sized businesses. What exactly that means, and whether there might be a particular exception to something you need, will vary.
If you have to ask whether the Enterprise section applies to you, it doesn't.
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.
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....