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!
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
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.
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!
Im not sure if this is possible but I am trying to setup two forms for a payment option for the following website
http://103.14.141.156/~wwwbetac/index.php/en/checkout
Pretty much over in New Zealand we have a company called Farmlands. We need a simple option under Payment Options or (Select Payment) and it says Farmlands.
From there they can go into a form which just has Farmlands Name and Farmlands Account Number.
Is this at all possible? Sorry if it doesnt make any sense.
Thanks
Short answer - yes this can be done as a VM payment plugin.
Longer answer - Payment plugins in VM2.0 are simply Joomla plugins. They do follow specific rules to work as a payment plugin so your best bet (unless you are an experienced programmer) would be to take an existing plugin and make some modifications to match your needs. You didn't mention if Farmlands has an API you will be communicating with or not. If it does, then you will want to start with something like the Authorize.net AIM plugin. If not, then you can use the Offline Payments plugin as your starting point.
Here is the documentation for VM Payment plugins - http://dev.virtuemart.net/projects/virtuemart/wiki/Payment_plugins