I new to paypal integration in asp.net . I found very difficult to understand the paypal api .
I under stood two types -
inline html form ( i.e is also called buy button )
payflow api
my questions are :
which one must be used for recurring payment ( subcription packages for end user)?
in first type , few sites suggested to use IPN for confirmation of payment. I want to know is it neccessary since without using IPN, also using notify_url we can confirm the payment success (as per my knowledge notify_url returns to your site when payment is completed at paypal site)?
for recurring payment , do i need to store user account details (i.e credt card or paypal account ) in my databas?
please do reply with you suggestion .
Thanks
1) You can do it with both, actually. If you want to stick with basic HTML forms then you'd be using Payments Standard, and they call it "Subscriptions". You can easily create a Subscription button from within your PayPal account.
If you're using the API then they call it Recurring Payments (or Recurring Billing). You would use Express Checkout for the PayPal signups, and Payments Pro if you want to handle credit cards directly on your site without any redirect to PayPal.
IPN is useful regardless of what integration method you're using, however, don't get it confused with PDT. PDT sends data back to your site's thank you page, or whatever final page you setup for it, and it only works with Payments Standard. When PDT is configured on Payments Standard, even with Auto-Return enabled, there is no guarantee the user will make it back to your return URL. IPN is very similar, but data will always be POSTed to your IPN listener regardless of whether or not the user makes it back to your site.
You'll also want to use IPN to handle updates for future payments on a subscription / recurring profile. For example, the actual payments, cancelations, suspensions, reactivations, etc.
The notify_url parameter you mentioned is used for IPN. Again, though, this is separate from PDT. A common mistake I've seen many times is when people have their PDT and IPN both set to the same URL. Then when people do make it back to your thank you page, the code actually runs twice. Once from the user actually hitting it, and once again from PayPal's IPN server hitting it. So make sure to avoid that sort of thing.
3) No, you will never save credit card details to your server. The subscription / recurring system handles that using the data that PayPal saves on their servers.
Related
What's the difference between PayPal buttons and PayPal Express Checkout?
The second one seems more complicated than the first one to integrate in a web site. When I should consider to use Express Checkout rather than Buttons? What are the advantages?
PayPal Standard buttons are indeed quick and easy, but they are limited. One of the biggest issues with it is with regard to Guest Checkout, which allows non-PayPal account holders to pay with a credit card without creating an account.
With Standard buttons this is browser cookie based, so if anybody has ever signed in to a PayPal account using the browser in use, then the cookie will trigger and assume that the user will be logging in to PayPal. This causes the guest checkout option to be less prominent, and buyers often miss it, which results in lost sales.
Express Checkout uses the APIs which gives you more flexibility, including the ability to force the Guest Checkout experience if you want to regardless of any browser cookies. This can lead to increased conversion rates.
Another thing to consider is that with Standard buttons there is no guarantee the user will make it back to your site. Even if you have Auto-Return enabled in the PayPal account there is a delay, and the user could simply close their browser before they are sent back to your site. With Express Checkout the user has to return to your site before the process can be completed, so this gives you the ability to tie more post-transaction processing procedures into your checkout flow.
Adding PayPal buttons to your website eliminates the need to enter your shipping address. You only verify the purchase details and confirm by the user and it gets supplied by PayPal but in case of Express checkout customer still need to supply their shipping address .
Also in case of express checkout you make API call initially to PayPal and in turn PayPal gives you token id for the payment you are going to make and you use the token(which is unique for every payment) to subsequently authorize and capture the amount from PayPal account once the customer confirms the payment after logging into PayPal account.
I'm using the same PayPal merchant account on multiple websites. Currently I'm using old-style PayPal links () with IPN notification.
Now I'd like to start using the PayPal Express API. But at least for a while I would have the old links still online on some sites.
The switch to PayPal Express seems to be per account. Will the old links and IPN continue to work ?
when you implement PayPal express checkout that will not hinder your PayPal links on whatever site you have them on. You can have PayPal Express Checkout with non-hosted button code on the site at the same time; no problem, at least while you're done with your testing, etc.
PayPal Express Checkout can be used across multiple sites; however APIs are only one per account. What this means is that if you want the funds to go to separate accounts for each site then you'll need a new PayPal account per site as you'll have to use different APIs with Express Checkout. That is the UserName/Password/Signature.
However you will have one IPN listener field for each account; so if you don't mind getting pinged for each site using the same IPN listener then you're fine.
You can just create specific prefix # for each site with the products themselves. Like store # 1 = 001Product# | Store # 2 002Product | etc. This will help differentiate IPN pings for each store and help you catalog it better. This is if you decide to use the same APIs for Express Checkout with the same IPN of the account. If so, you will have the PayPal button purchases along with the Express Checkout purchases you all the same data IPN wise and all funds will roll into the same account.
I hope I hit your mark on your question, but let me know if you need additional clarity as I'm happy to help. Have a good one.
I am making a system in which user permits pre-approval of amount. I've used pre-approval with chained payment. But the problem is that my customer gets redirected to PayPal site and also he/she must have a PayPal account or need to create one. So can i make pre-approval payment using PayPal website payment pro? So my customers will not get redirected to PayPal account. And the process becomes more fast? Note :- I don't want to use authorization and capture method. Thanks.
Edit
One more question :- If i make the website in the UK and the currency in GBP, can I still use the American Paypal account for this?
Auth and Capture is what you're asking for, but then you say you don't want it..?? That's what gives you the functionality you're after, though.
You could do a $0 auth and then run DoReferenceTransaction when you're ready to process the payment as opposed to capturing an actual auth if you want.
Those are your only options when working with Pro, though, and it would give you the same sort of preapproval experience for the buyer.
Here are the steps to accomplish what you're after.
Use DoDirectPayment to run a $0 Authorization (card verification). Users will enter their credit card details directly into a form on your site without any redirection to PayPal (and without any knowledge PayPal is being used at all unless you notify them some way.)
Save the transaction ID that you get form this card verification into your transaction history for the customer in your database. This ID is what will be used to process future payments using that credit card.
When you're ready to process a payment for this customer, pull the ID out of the database and use it with a DoReferenceTransaction request to process any amount you need to.
So the card verification is your preapproval, and then running reference transactions are the same as running Pay requests with a Preapproval key. Both methods accomplish the same thing, but one is with direct credit cards and the other is not.
If you're using PHP you can use this PayPal PHP SDK to make all of the API calls very quick and easy for you. If you're using some other language then there are SDKs available for those as well I'm sure.
Please correct me if i am wrong, #Andrew Angell #Ved Pandya
Auth and Capture or Capture payments later method allows you to do direct payment, but it comes with additional charges, which might not suitable for crowdfunding model as refund/ cancel payment is very frequent
Auth and Capture: You are required to pay $0.30 for each "Card Verification Transactions"
Capture payments later: You are required to pay $0.30 for each "Uncaptured Authorization" that you triggered
https://www.paypal.com/us/webapps/mpp/merchant-fees
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 am writing an IPN application for doing theater seat reservations. I place a temporary hold on the seats before going off to PayPal. When the IPN handler is called and detects a successful payment, the seats are reserved permanently.
The "return" parameter for my PayPal brings the customer back to the reservations application. Because the IPN handler may not have been called yet, the customer may or may not see his seats reserved (this is probably not the best application for IPN, but I am too cheap to spring for one of the non-free methods). So I am considering incorporating PDT. The "return" parameter would then specify a URL that would first complete the reservation processing in case the IPN handler has not already been called. Here are my questions:
My understanding is that if the customer does not have a PayPal account so that he instead uses his credit card to pay for the reservation, then PDT is inoperative (why this is unimaginable). What then does PayPal do so far as honoring the "return" URL? Does PayPal ignore it entirely or does it still return to that location but without passing the "tx' parameter? In the sandbox environment, of course, you always have a PayPal account and I am obviously unable to turn on PDT in my production environment production just to see what happens when one uses a credit card to make a payment, hence my post. However, I did specify in the sandbox that I wanted to use my (dummy) credit card to pay for the reservation and the "return" URL was invoked with the "tx" parameter. This was perplexing. So when PayPal says that PDT is not meant to be used with credit cards, will PDT work anyway as long as the customer is logged on to his PayPal account or is this just a peculiarity of the sandbox?
I am in the opposite position here, I have PDT implemented, but because the auto return doesn't work for my users without Paypal accounts, I am looking into adding IPN to my site to supplement PDT.
As I said, auto return does not work for customers/users who do not log into a PayPal account to make a payment. They can still make a payment if you have the "PayPal Account Optional" feature turned on in your Website Payment Preferences. They are given a link to your specified return page after their payment to return to your site, but are not automatically returned, so effectively, PDT doesn't work unless the user manually returns to your site (to the appropriate page) to initiate the PDT process. I have had problems with users not returning which prevents my registration process from completing, which is why I'm also going to be adding IPN.
PDT works with credit card payments as long as the user returns or is returned to your site after the payment to initiate PDT.