Currently we use WHMCS PayPal payment gateway module but looking forward to develop our own module if we could solve our case.
The case is that we need to have a possibility to restrict clients to make payment from some specific country or countries. In standard payment way PayPal do not provide any payer details take a decision on our server side and not forward client to PayPal to complete the payment if it necessary.
Have anyone experience on solving this case? While after reviewing PayPal API do not found (or missed) the possible solution.
I'd prefer to comment on this, but the char[] is too long. strcpy is always an interesting problem.
You could scrape some site like https://ip-lookup.net/ or ARIN itself by execing curl or using a HTTP library like POCO or libcurl.
There may be some library out there that performs the lookup, you'd find that with Google. It will probably be based on IP in any event.
Related
I am reading this paypal-rest-sdk based payment integration approach from a blog, but I can't find it on Paypal's official developer pages. Question: If someone can help me link that blog's approach to a Paypal's developer page explained method, I'd appreciate.
Instead, I see a Braintree based payment integration approach listed on official Paypal developer page. Question: Is this one more preferable than the previous one? Plus, can this approach accept credit card payment (reading the doc, it seems to only support Paypal payment)
The PayPal-Node-SDK is deprecated, and the Express Checkout via Braintree Mobile SDK is only worth using if you need a native mobile SDK. So the answer to your question, based on the information provided, is most probably: neither.
Instead, you need to do a better job of reviewing the information on https://developer.paypal.com , namely https://developer.paypal.com/docs/checkout/
For a good server-side integration, the front-end at https://developer.paypal.com/demo/checkout/#/pattern/server will be particularly useful.
Note that the fetch() routes it calls need to be placed with actual routes on your server, which will call the PayPal APIs for creation and capture during teh checkout. For those API operations from your server, use the supported Checkout-NodeJS-SDK.
I was looking for a payment solution for my web-app. I saw that there are APIs like stripe (for credit cards) or PayPal plugins that can deal with certain paying methods.
Then I saw that there are libaries that can deal with all sorts of paying methods like Payum (https://github.com/Payum/Payum) or Omnipay (https://github.com/thephpleague/omnipay).
If I understood it correctly they are both the same type of library: They both process payments of various methods in a standardised way. However I did'nt find any comparison between the two, but solutions to how Payum can include OmniPay. So I got confused. Thus my question:
Does Omnipay cover the same purposes as Payum. If yes, which one has what advantages. If no, what parts of the paying process are they exactly implementing.
Payum vs Omnipay
The short answer is Payum provides same functionality as Omnipay plus some extra features.
Payum works best when you combine a payment model with a convert action. The model must not be only a Payum’s one, I encourage you to use your own or one from a ecommerce platform. The idea is simple: you send a request to Payum to capture your model. In the action you convert the payment model to a gateway specific format, most probably an array. The beauty of this approach is that your code is never changed, and looks like this:
$gateway->execute(new Capture($payment));
All gateway’s differences are hidden inside a gateway. Of course Payum supports a gateway specific format, or a Payum’s Payment model as well. In case of Omnipay you cannot simply replace a stripe gateway to a paypal one, because they behave differently and what is more important they require different data. Stripe require a credit card to be provided where Paypal does not care about it but instead wants return and cancel urls to be set. You have to reflect these differences in your code, is this abstraction? By the way Payum generate cancel and return urls for you and they are secure ones (we talk about it later).
Sometimes you have to get more details about the payment transaction, or a payer, or more info about an error. Payum provides you access to all data that takes part in a communication between your code and a payment gateway. The data format is a payment specific, so if you familiar with Paypal protocol (for example) it would be easy for you to understand what is going on there. Another good example is Klarna Checkout. It returns shipping\billing addresses, gender and date of birth. With Payum you can easily get these out of payment and use for your needs.
Payum gives you a better status handling. Omnipay provides only two statuses success and failed, but it is not enough. For example Paypal sometimes returns pending status because of multi currency issue. In this case omnipay says the payment has failed, but in fact it is not. Or user can cancel the payment at Paypal side, Omnipay will tell you it failed but it is not really true. If you need a status which is not provided by Payum by default, you can easily add it. Do you already have payment statuses, maybe your ecommerce platform provide them and you want to reuse, no problem Payum could be adjust to use them.
Sometimes users want to cheat on you or pay less for the stuff. As a developer you have to think about it and take care of your data. What do you expose to a user? Could it be used the wrong way? You can not rely on an amount given in the url, until you validate it. For example Paypal sends you a push notification to the notify url you previously sent to them. Payum generates for you such an url and when the notification comes back it validates it. You get unique, secured urls out of the box. The payment internally associated with that url, and once you remove\invalidate the url user not able to access the payment behind it. Omnipay does not provide anything to help you solve security issues. There is one good side effect with these secured urls. The secured urls invalidated\deleted once they not needed. This is good, for example user clicks “Back” button in a browser. He would not be able to do a second payment because the purchase url no longer exists, instead he will see a 404 error.
It is not a good practice to store credit cards at your side, isn’t it? There is no excuse for storing it accidentally, or just for few seconds. Payum has a sensitive value object which ensure that nothing is saved accidentally. You still able to store it, but while doing so you are on your own.
Omnipay supports only gateways, that do a redirect to gateway side or require a credit card. But there are bunch of other gateways, and they act differently. For example Klarna Checkout require a snippet (iframe) to be rendered, Stripe.Js requires their javascript to be executed on a purchase page. Stripe Checkout renders its own popup. Payum supports them all, and as we talked at the beginning you can switch from one gateway to another without changes in your code. Payum does not natively supports a gateway you need? I do not think reimplementing every gateway in house is a good idea. That’s why a bridge for Omnipay gateways exists. It allows you to use Omnipay gateways the Payum way.
Payum tries to standardise the payment flow. There are three steps prepare, capture\authorise and done. The first one is called “prepare” and at this step you have to prepare the payment, calculate total prices, taxes, get user or shipping information and so on. Once you are done you can redirect user to a capture\authorise step, From here user could be redirected to a gateway side or asked for a credit card, or something else. It depends on what gateway you chose. At “done” step you have to get the payment status and act according to it. Omnipay only partly solves this task.
With a gateway factories you can easily overwrite\replace any parts of the gateway functionally, or add a custom actions, extensions or apis.
Payum has official extensions for most modern frameworks such as Symfony. Laravel, Silex, Yii, Zend.
At the end lets compare the corner stone interfaces from Payum and Omnipay.
Payum GatewayInterface vs Omnipay GatewayInterface
Payum GatewayFactoryInterface vs Omnipay GatewayFactory ups there is not an interface.
Disclaimer: I am the author of Payum
I'm new to PayPal and overwhelmed by all the possible approaches for integrating with PayPal.
As a start I want to implement one single subscription with monthly recurring payment. When the user returns to the site after fulfilling the payment, he/she will instantly be upgraded to "premium" member (digital product only - no shipping involved).
The first alternative I've looked into is the Express Checkout API, which looks ok, but is there any simpler way to do it?
Can I for example create a standard button (JS button or the form based), but still be able to verify the payment details when the user returns, using either the REST API, IPN or something else?
Any hints on best practices are appreciated.
Yes, there are entirely too many ways to solve this problem by now.
You can probably satisfy your requirements via buttons (aka Standard), Express Checkout (aka Pro) style APIs, or RESTful APIs, but there are a few gotchas to know:
First, PayPal has several products to do recurring payments; these products have functional differences and are tied to different integration styles. So (for example) PayPal's product called "subscriptions" (tied to Website Standard aka buttons) has different (and generally less flexible) capabilities than "recurring payments" (tied to Express Checkout) which in turn differs from "billing agreements" (tied to REST APIs, although the term "billing agreements" is also used in the express checkout recurring payments product). Oh, and there's another similar product tied to the Adaptive Payments suite of APIs.
Confused yet? Sorry. But it is important to determine whether the specific product you want to use will satisfy your requirements first before you do any integration, or you might end up redoing that integration work later (and potentially have to migrate customers, if you have already opened your business) in order to get access to specific features of another product later on. E.g., the subscriptions product has very limited ability for sellers to modify the subscriptions after they are set up. If that is OK, then great, use it -- it's simple to integrate. If I can oversimplify a bit: the Standard subscriptions product is the oldest and most limited; the Pro recurring payments is more flexible and mature; the REST billing agreement product is the newest, very flexible, but not yet as widely used; it may lack a feature you need today, but is the most likely to be continually improved going forward. I would not personally recommend the Adaptive product, although it also has its benefits.
Now, to your integration question: fortunately all these PayPal products can use IPNs. Unfortunately, IPNs are not instant. They generally arrive quickly (1-2 seconds) but delays can happen and it is quite awkward to be unable to process the customer. I would use IPNs only when shipping physical goods, not for immediate access to digital goods or in other cases where customers are waiting for a page from you. Fortunately, each of the other methods has a way to instantly determine the success of a PayPal action without waiting for an IPN:
Website Standard Payments will include GET or POST variables when it posts the user back to your site that will tell you about the outcome. If you use the Payment Data Transfer feature, these variables will include signature information so that you can post them back to PayPal & PayPal will verify their validity (so that a would-be thief could not fool you by engineering a post that looks like a PayPal success redirect).
The two API-based methods are even easier: the APIs themselves return all the information you need in the API response. So wherever in your code you make the call to create the subscription/agreement, if you get back a success then do your work to make your user premium.
There is the odd case of a user successfully paying and then getting "lost", as it were, e.g. the redirect failing/browser closing before they return to your site, or your site choking while trying to turn on the user. For this reason many people advise using IPNs, which PayPal will attempt to redeliver until you verify them back to PayPal. Not a bad idea, depending.
And of course you can call search & get details type APIs to get information about your transactions & agreements at PayPal -- although again, you will need to integrate with the right API that matches the product you are integrated with (e.g. Standard-based subscriptions won't show up if you ask the REST interface for billing agreements).
Hope this helps.
Is there a way to use the paypal API to send basic details of a payment without actually creating the payment itself? What I mean is, I'm working with a non profit organization that does not currently employ SSL. They want to use paypal to accept donations, but they want their own branded form on their page, they don't want to use the simple donate button. I had thought I might be able to send basic details, such as name and address along with the amount they wish to donate and a few other details using the paypal API, and then have the actual payment information processed on paypal's secure servers. All the examples I can find on how to use their API however are creating complete payments and sending them to Paypal, something I'm not able to do for obvious reasons. Short of employing SSL, something that we should probably do anyways, and capturing a complete payment, is there a way of sending just select information over the API and handling the rest on paypal's end?
If you want to control the form itself you don't have any choice but to go SSL. Any other route would require sending the user to PayPal, where you would no longer have that control.
I will cut the post short.
I need to accept credit card payment through my Magento Install. Now I thought it should be straight forward where I will get the API from some provider (say Authorize.net) and put in my API details within the admin, but alas.
When I searched, all I find is that people are trying to create Custom Payment Gateways instead of using Magento's own admin. I am new to this and I need help in this.
I will be thankful if you can help me in finding answers for:-
What is the straight forward way (a tutorial may be) to implement payment gateway on my website
What is the best payment gateway company
Do I need to make Custom Payment Gateway?
Thanks a lot
as my knowledge authorize.net gate way is best payment gateway for magento,because it is already used by so many developers and there is a great community forum to help us.So as my suggestion better to use authorize.net.
coming to integration method you,use authorize.net*AMI* method. In Magento Admin System->Configuration->Payment Method You can see Authorize.net payment Method in that you can Customize with your AUthorize.net API Login information.please go through this authorize.net link for more details.
hope this may help you,thank you very much