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.
Related
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
Is this the real behavior of Paypal. I am using the Paypal REST api (payment api's), and it is working fine and customers can use it. The only problem is when a new customer (one that has not visited paypal.com once) tries to buy our product, paypal seems to require him to create an account.
Here's the procedure:
First time to visit paypal.com (meaning no cookies / not cached or anything).
Customer Buy Product (Our website creates the payment transaction then redirects him to paypal.com)
Customer click Pay with my credit or debit card (He does not want to create a paypal account).
The country set is Philippines (I think paypal detects this so it is initially set to where I am) and I can proceed paying with my credit card
I tried changing the country to somewhere else
Here's comes the problem, on some countries, I am shown a different form, a form for creating a new account in Paypal.
Hope you understand what I am saying. Thanks.
It’s important to remember that guest checkout is not guaranteed for every transaction. PayPal runs a risk check to determine eligibility for guest checkout. There will be times when guest checkout is not available. This is intended. Here are a few things to make sure guest checkout is offered as often as possible.
-Verified PayPal account
-Confirmed email address
-Guest Checkout enabled - To see this, log in, go to Profile and click 'My selling preferences', click on Update next to Website preferences - scroll down the screen and find "PayPal Account Optional" section - you can enable/disable PayPal Account optional here.
-With Express Checkout their cart must pass “SOLUTIONTYPE=Sole”
Unfortunately, there are few parameters which are still incompatible with REST API including SOLUTIONTYPE which works only in Classic API.
If all of these are met and it’s not available then our system has decided to disable the guest checkout option for risk reasons. This is not a permanent decision and it will be available in the future.
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.
I am using the new PayPal Pro Hosted Solution on a new site, and all seems to work 'OK' apart from auto return does not work?
I have auto return enabled in my paypal account along with IPN and payment data as I have the auto return working with normal Paypal on my old site (So I know its setup correctly). And I have all the correct fields INCLUDING the 'return' variable set and sent to PayPal on this pro-hosted form.
After successful payment I just get the standard Paypal pro hosted thank you page (There is no delay redirect, I left it on the page for over a minute)??? There is a return link on the page, which if pressed returns me to the correct page.
BUT I need the users auto returned? Or this solution is useless to me as I won't be able to track conversions? I can't be the only person needing this surely?
I solved this. it IS possible with credit cards and PayPal. Just make sure you add the following variables
return with your return url in it
showHostedThankyouPage with a value of false
Was the buyer paying with their PayPal account or credit card. With Auto Return, the buyer is automatically returned when the buyer pays with their PayPal account, however if the buyer pays with their credit card they are not automatically redirected. They are given time to write the information down or print the page. Unlike someone that pays with their PayPal account, they can not always get back to the transaction details. The buyer that pays with a credit card will have to click the link to return back to the merchants site. This is why it is better to rely on IPN than auto return. IPN will take place regardless if the buyer returns to your site.
I'm having some trouble choosing between PayPal's Instant Payment Notification (IPN) and Payment Data Transfer (PDT).
Basically, users buy a one-off product on my site, pay on PayPal, and return to my site. I understand how IPN works but I'm now seeing that I might be able to trigger the various actions that take place after a successful purchase more easily with PDT, as the data gets returned there and then (as opposed to needing a separate listener).
However, PayPal's PDT documentation contains this cryptic line: "PDT is not meant to be used with credit card or Express Checkout transactions." ... but I can't find anything further whatsoever on the topic.
Are credit cards REALLY not meant to be used with PDT? I would like more than a sentence.
Does that mean that a user must have/create a PayPal account to pay?
Does it mean that if I want to allow users to pay with their PayPal accounts AND/OR with credit cards directly, I must implement IPN?
Could anyone who's gone through this kindly shed some light?
The APIs for PDT and IPN are similar. The main difference is when you receive the notification. For that reason I would recommend implementing both.
With PDT you get the notification instantly and can do any additional processing required and show the user a confirmation page.
With IPN you are guaranteed to be notified that the payment was received even if the user's computer explodes before it can send you the PDT.
Implement both and get the best of both worlds. But if you're only doing one, IPN is the reliable one.
One catch: if you implement both then there's a chance your payments could be processed twice. Take care to ensure that doesn't happen. The application I wrote handles the PDT and IPN almost identically (the backend part is the same) and that code acquires a per-web-user lock in the database, so that if the same user tries to submit the exact same payment multiple times it can only be processed once. Once processed the result of that process is re-used for any subsequent attempts to process it.
Edit
One more thing: IPN carries more information than PDT. There are lots of different messages that you can receive from IPN, such as chargeback notification, etc, and thus you really should implement it.
PayPal's PDT system sends order confirmations to merchant sites that use PayPal Payments Standard and lets them authenticate this information. Such sites can then display this data locally in an "order confirmation" page.
When to Use PDT?
IPN provides the same capabilities described above. So, when should you choose PDT instead of IPN?
With PDT, your site is notified immediately when a customer completes payment. With IPN, however, there is a material lag between the time a customer completes payment and the time your site receives notification of this event.
So, use PDT if your site includes a feature that requires immediate payment notification.
For example, consider a digital music store. With PDT, this store can let customers download their purchases right away since PDT sends order confirmations immediately. With IPN, such immediate order fulfillment is not possible.
Advantages of IPN
PDT has a a major weakness: it sends order confirmations once and only once. As a result, when PDT sends a confirmation, your site must be running; otherwise, it will never receive the message.
With IPN, in contrast, delivery of order confirmations is virtually guaranteed since IPN resends a confirmation until your site acknowledges receipt. For this reason, PayPal recommends that you implement IPN rather than PDT.
Another advantage of IPN is that it sends many types of notifications, while PDT sends just order confirmations. So, using IPN, your site can receive, for example, chargeback notifications as well as order confirmations.
Note: If your site must be notified of payments immediately, you can implement both IPN and PDT. However, if you do, your site will receive two order confirmations for each sale. As a result, you must be careful to take action (say, ship a product) on just one copy of a given confirmation message.
Documentation Here
Re 1. PDT is meant to use with Auto Return for Website Payments feature. Auto Return redirects to PDT site after paying money to seller. Unfortunately it's not possible to use that feature along with PayPal Account Optional - used to enable Credit Card payment. Here is note from PayPal: 'If you have turned on Auto Return and have chosen to turn on PayPal Account Optional for new users, a new user will not be automatically directed back to your website, but will be given the option to return.'. User will have an option to go back to your site(PDT step) or stay on PayPal site. To sum it up when paying by Credit Card user can skip PDT step if user will not click 'return to store link'.
Re 2. It is up to you what paying options do you want to allow. If you want to allow paying without a PayPal Account you can enable Account Optional. If you want to allow only users with PayPal accounts disable that feature. There might be more options.
Re 3. In your case you need to trigger action after successful purchase. Recommended way would be to implement IPN. PDT doesn't work for all cases and doesn't guarantee message delivery. Here is link to doc covering that topic PDT vs IPN.
This is an old question, but my simple answer would be - Why not use both PDT and IPN? They will work fine for card transactions.
PDT can provide the immediate transaction status to your website, where you can quickly check the payment success or failure status and provide the user with appropriate message.
Meanwhile, you can await the full verification from IPN in the background. Once received, you can use this to further update your DB and process the order.
You can follow this step-by-step guide which I found to be very clear and helpful - and it's still valid in 2018.
https://www.codexworld.com/paypal-standard-payment-gateway-integration-php/