In Paypal, I m trying to implemen t a Auto payment system using paypal. Where user can save their card details then whenever the invoice is generated using card details invoice can be paid automatically.
I read the document of paypal but not found regarding that.
Please let me know how can I implement Auto payment system using PayPal.
There's quite a bit of information on the Subscriptions page, but most of that is a generic overview. However, there is link to the Integrate Subscriptions page that gives more links to specific API and SDK instructions.
Follow through the step-by-step information to get all this set up. It'll take a while to get everything correct, so definitely use their testing APIs so you aren't doing a bunch of tests on their production APIs and spending your own money doing it.
Once you get the subscriptions created and someone subscribed, PayPal does the rest. You just need to create the subscription and allow people to subscribe.
Also, PayPal keeps track of credit cards and other payment forms for you, so you don't have to go through all the PCI security procedures for storing that information yourself. That gets real involved and can cause you to get in serious trouble with fines and lawsuits if you aren't certified. It's much easier to use a payment processing gateway such as PayPal for this than create your own, especially since you are going to be using PayPal for processing the payments anyway.
Related
I've been developing a marketplace type platform. Implementing PayPal Payouts seemed to be perfect for dealing with commissions. Especially being as PayPal will be handling all payments too.
I've successfully developed this part of the system. Inc. the webhook and verifying transmissions.
Now I wish to get my eBay sales info into my system. So that we can see it all in one place and have the system work the commissions out for those sales too. Having just invested the time into learning and implementing this PayPal API integration, it would be nice to use it for getting this data too.
So having tested the sandbox app thoroughly for the Payouts, I configured the live one. This is in my PayPal developer account where the app settings are. I've done nothing in my main Paypal account. Am I meant too?
My live webhook URL is just set to log all received data from PayPal. So I waited for a eBay sale and went to check the log but no data received? Am I misunderstanding this? The webhook is subscribed to all events.
The Drupal Commerce shopping cart I'm using already implements a IPN. Is it the IPN that I need to be thinking about? I'd prefer to not interfere with it to be honest, to keep future security updates safer. That said, I suspect there will be a way to extend it.
I guess the actual question is - what is the easiest way to get eBay sales info through PayPal?
Any help would be much appreciated.
eBay has their own system for that called Platform Notifications.
If I'm working with payment data, and I just need extra data from eBay, I will typically start with PayPal IPN / Webhooks and then use the eBay APIs within my IPN app to pull and push data as necessary.
Of course, depending on the scenario, you may decide to build out your primary solution inside of an eBay Platform Notifications app, and then make calls to PayPal APIs within that if you need to pull/push data.
I have one requirement in which I need to develop Facebook messenger bots and implement payment for product from bots.
Has anyone experience with payment with bots and its approval by Facebook?
As I know currently it only has a receipt structured message that you can use for sending receipt. But there is no any API supports for the payment, you could either make a series of messages between the bot and customers by using postback, but it's very inefficient and stupid, also insecure. So I recommend using an external link that customers can click it and go to your payment system.
I have developed a bot that has integration with Stripe Payments (which is really fantastic btw). I created a WebView that redirects to my payment processing page. I didn't have any issues with the approval. All I did was send them a demo of how I get card information and showed them that I'm not storing any specific payment information because stripe hides the actual info and gives me a token to process a payment.
I find Bot approval in Facebook is stringent but straightforward as long as you give them the information they need. That means giving them a DEMO on how you're going to collect information and make sure that everything is clear.
Our terms and condition also have some payment terms (cancellation, refund, etc). Although they never checked it, I would highly suggest to clearly state these items on the T and C - and of course, make sure they tick a box specifying they agreed to such terms.
Good luck!
I am working with paypal first time.
I have a product and I want to integrate paypal with it.
I want to achieve the following tasks :
Client comes to my website and select a plan,which is a monthly recurring plan.
Then client is redirected to Paypal for payment.
Client makes payment.
Return backs to home page.
I have gone through the documentation of paypal and I have the following questions.
What should I use REST API or Classic Sdk, as I want to create Recurring Profile,Work with EXPRESS-CHECKOUT and REFERENCE TRANSACTIONS.
I have customers all over globe and it is stated in the documentation that, for the customers in Germany and China , I have to use REFERENCE TRANSACTION.
Some where in the documentation of Merchant SDK it is stated that the classic API's will be deprecated, so is it a good approach to use Classic SDK
I also wanted to track the transactions(payment) made by user, so that I can show him the amount that is deducted in each month in his profile details.
Please suggest a feasible solution to my problem.
Thanks in advance.
Here's what I use. I went to Web Payments Standard and created a Subscription button. (I like the unencrypted variety, but you can encrypt if you want.) In there, you set the terms of the subscription, as well as where to post the IPN message. When the IPN message comes back, you deal with it. You'll get a subscr_signup at the start along with a subscr_payment. Then, on renewals, you'll get a subscr_payment again. What I like to do is store every verified IPN message in the database for my customer.
For handling the management of those subscriptions for things like tracking info, refunds, subscription cancellations, and voids, you'll need to use NVP API, which is a very simple API. If you stored in a database every IPN message with all those fields, then you should be able to pass certain fields of those to the NVP API in order to get what you need done.
If you're worried about longevity of the APIs, then don't. All they do when they deprecate APIs is stop giving you good docs on them. They still let those older versions run. If they didn't, there would be major upheaval on the web with web commerce products breaking all over the place. However, that said, if you want to prepare for the future, then get on the Braintree Payments API because PayPal bought Braintree and that's the future of their API.
I am building website which requires customer to update paypal account.
Is there anyway to check the reality of customer's account?
When my customer fill out their paypal account in my site, I want them to be directed to paypal login page to login and paypal will return the result.
Does paypal api support this situation?
Pretty much any implementation of PayPal you choose would follow the flow you mentioned.
Payments Standard would allow you to create basic buttons or create an HTML form and POST directly to PayPal to process. It would send the user to PayPal for login and approval to complete the payment. The transaction details would include the payer status (verified or unverified) as well as the address status (confirmed or unconfirmed) and lots of other details about the order.
Express Checkout is basically the API version of Standard, but it's much more advanced and open to integrate in the way that works best for your site or application. In this case, some of buyer/transaction data is available during the process within your app through API requests and responses, and then you can also get to it via transaction details after the fact just like payments standard provides.
Another option would be to use Adaptive Payments, but if you're doing a general payment of any kind you probably don't need that. That's what you would use if/when you start wanting to split payments among multiple receivers within the same transaction, setup preapproval profiles, etc.
If you happen to be working with PHP my class library for PayPal will make the API calls very simple for you.
You could do what PayPal itself does when you register. Send them a few cents and have them tell you how many when they get it. The payment itself will fail if the account doesn't exist, and telling you how many cents proves that they own the account.
I'm trying to integrate a payment mechanism to my site. The scenario that I need is not trivial and can be explained by the following example:
User pays upfront for a subscription program (i.e. receiving Netflix). User is able to make changes to the subscription (i.e. change number of movies checked out each time from 4 to 2)
User is able to buy additional one time purchases via the provider's site (Netflix) supplied by 3rd parties. These items (i.e. popcorn, snacks) get billed to the same credit card as the subscription without having to go through the process of resubmitting the credit card information.
Of course, my site takes also a small fee for the transactions :-)
I was wondering if this is supported by PayPal, Google Checkout or someone else.
Thanks.
The Paypal api can handle all of those processes.
I seem to have dropped the ball on what kind of answer you wanted so I'll leave it at that.
If you have some feedback, more direct questions I will try to answer as much as I can
--
The money would best go through you first, unless somehow you can convince your customers its normal to bill them per item. Also if they pay by credit card you should only bill them once as you would incur fees on every payment. I don't know of anyway to bill once but distribute the payments.
As for the paypal docs..
Very good resource, there is also some sample code for most major web languages
Also this will get you started if you don't have a developer login
Their developer support is also pretty good. One thing a lot of people seem to screw up when starting out with the paypal api is not setting the latest version in the configs so don't forget to update that to the latest release. :)
Disclaimer..
Yea I know there is a lot of bad press about paypal and crazy stuff happening, but they do get the job done most of the time, its not my fault the customers love to use it.