PayPal states:
Note: 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.
But if some of the customers don't get "Auto Returned", how do I handle them programmatically?
Paypal does not guarantee autoreturn especially when Paypal Account - optional setting is on.
The right way to handle the integration is with Instant Payment Notification (IPN) option. Using IPN Paypal will make POSTS to your page notifying you of payment events. The following link explains the IPN process pretty well.
To summarize, you will write code that will trap posts from Paypal and then make sure to update your billing data accordingly.
Also, IPN messages might be slightly delayed.
Create a script (cron or what) that does check for such payments at paypal perodically (e.g. every hour).
Is this what you mean?
https://www.paypal.com/cgi-bin/webscr?cmd=p/mer/express_return_summary-outside
If not, you may need to be a little more specific with your question. Like - are you using paypal pro? How are your customers checking out? etc. And now that I read the answer below mine, I wonder if you are even talking about the payment process and not something else.
Related
I have a question about Paypal IPN, I was wondering when does the IPN activate and send it's message to my website.
I currently have my website that has a buy button. When the client buy the service, he is directed to paypal. Once he pay the service, nothing happen. In order for me to receive the IPN notification, the user has to click "Return to merchant website" or whatever the link is, then I receive the IPN notification.
Is it normal, does it work like that for everyone?
Cause right now, most people when they are done with the payment, just close the website and I don't receive any notification.
Thanks for any help !
Your question leaves a lot of missing information so I will go through each option for you:
Read here about how to setup a sandbox account if you don't already have one: https://developer.paypal.com/docs/classic/lifecycle/sb_create-accounts/
Bare in mind that your sandbox account is entirely separate in every way from your live paypal account. All settings will need to be checked and customised as needed.
Set up your IPN URL on your sandbox account Here: https://www.sandbox.paypal.com/uk/cgi-bin/webscr?cmd=_profile-ipn-notify
Once set up, you then need to download and set your code (PHP or something else) to the listener (referenced in the above sandbox profile link). You can find IPN code examples here: https://github.com/paypal/ipn-code-samples
When that's all set you need to set your listener to using the sandbox mode and then log in to your live account and then run the IPN simulator from here: https://developer.paypal.com/developer/ipnSimulator/
Paypal will send messages to your IPN listener and you need to do something with the messages, typically output them into some sort of log file. Any issues, you can read Paypals feedback and IPN data/delivery information here https://www.sandbox.paypal.com/uk/cgi-bin/webscr?cmd=_display-ipns-history&nav=0.3.4 [Found from History->ipnHistory on the Paypal menu] and it should list them out. You can resend any failed or queued or undelivered messages.
Paypal is a terribly documented and terribly structured system for coding with. I hate it. Use Stripe.
I love bullet points.
Paypal claims they will try and resend failed/queued IPNs 16 times over 5 days. I have yet to see this, you need to resend them manually (at least, sandbox ones)
Please remember all the settings and changes you have made to your Sandbox account will need to be also made to your live account before you make your payment system live!
Solution
My return_URL is the location of my IPN.php file which take care of the data sent and received. My problem is that the IPN is only firing when I click the "Return to merchant website" and not when the payment is actually completed
What you have done, from reading your comments, is set your IPN page to being your return from paypal page, this is NOT the way IPN is supposed to work, the IPN page should never be visited by the customer, only ever by Paypal.
Read through my anwser (points 2,3,4) and set up your IPN web link as I have described above, your return_url value should be a basic page to say to the customer "transaction complete". The IPN page is defined on your paypal accounts (sandbox and live) as I stated above.
This will fix your problem.
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 integrated PayPal in my web shop in order to allow instant payments with automatic product delivery (already had this before but only with instant wire transfers via sofort.com). I integrated it with the help of the example provided by PayPal (I'm using ReviewOrder.php, GetExpressCheckoutDetails and DoExpressCheckoutPayment).
It's working great if they pay with PayPal balance or a linked credit card. However, some customers from Germany don't have balance in their accounts but only a bank account linked to their account. The payments go through and they receive their product, however I noticed the payment status would remain "Pending" for 1 month and change to "Expired" afterwards, so effectively no money arrives.
Why is this happening? Or is there any way to deny such payments? (Payments from backup funds)
Any help would be appreciated.
Its hare to day with out looking at the transaction specifically. But there are several things that can cause your payment to be pending, such as your preferences that you may have set in the account. Check to make sure you dont have your preferences set to ask me before accepting a payment in a currency that you do not hold. Did the buyer pay with an eCheck? If so, it could be waiting for the payment to clear. If this is in the sandbox, you have to manually clear the payment. If you are still not able to determine the cause of the pending payment, if you provide the transaction id, I will check it on my end.
Hey guys I managed to find a solution to this odd problem after all.
It turned out I had the following code in my implementation where I actually initialized the payment process:
$_REQUEST['paymentType'] = "Order";
This was a mistake though, since this payment type won't place a hold on the funds and if the DoCapture call is never called this payment will remain pending for about one month and then expire entirely (as described in my question, so this is what actually happened to me). The bad thing is that it's impossible for such payments to even accept them manually from within PayPal (not even the local PayPal phone support was able/wanted to accept these payments for unknown reasons because they told me they'd come up with a solution and contact me via Email within 24 hours but they never did).
So in order to fix this issue I changed the payment type to Sale which instantly captures the payment rather than waiting for sort of approval or a capture call. It worked fine for two weeks now and I think I'll leave it like this now.
$_REQUEST['paymentType'] = "Sale";
I lost about 110€ because this stupidly trivial detail but at least it's working fine now and I was able to re-enable PayPal as a payment form. I hope they'll at least add an option to manually accept these payments if the DoCapture call was not implemented because it worked fine without it for most of the payments as well and after all this is still about real money, so this absolutely would be an essential thing to have....
This can happen also if you are trying to accept a payment in a different currency of your account. To avoid that you must create a "PayPal balance" in the currency of the payment.
IPN is also giving hints on the pending reason in this case:
[pending_reason] => multi_currency
Problem: I've implemented "partial authorizations" (pg 72) but whenever I try to run a transaction that could use it, the result is a decline.
Setup: I'm handling transactions with the API with PayPal Payment Pro Payflow Edition (aka, PayFlow Pro Gateway & PayPal Merchant Account).
Cards use in Transaction: Visa Gift Card & American Express Gift Card. This feature was made for gift cards and other prepaid products. Gift Cards are specifically cited in PayPal's documentation example.
Transaction Logs:
Here is the log for a declined partial authorization. The original amount requested is $25.00, even though this visa gift card only had $2.00 on it. I should have received a response with an approved amount for $2.00. Instead I got a decline.
-> PARTIALAUTH:Y TENDER:C ACCT:**** VERBOSITY:HIGH TRXTYPE:A EXPDATE:0618 AMT:25.00
<- RESULT:12 CARDTYPE:0 PROCAVS:G IAVS:N PROCCVV2:I EXPDATE:0618 RESPMSG:Declined: 15005-This transaction cannot be processed. LASTNAME:NotProvided ACCT:**** AMT:25.00 PNREF:************ AVSZIP:X AVSADDR:X HOSTCODE:15005 TRANSTIME:2012-12-14 12:43:04 CVV2MATCH:X
For comparison, when I run the same card for an amount that is less than what's on the card, it goes through no problem:
-> TENDER:C VERBOSITY:HIGH ACCT:**** AMT:.11 TRXTYPE:A EXPDATE:0618 PARTIALAUTH:Y
<- AMT:0.11 AVSZIP:X PPREF:***************** ACCT:**** AUTHCODE:111111 TRANSTIME:2012-12-14 12:41:46 LASTNAME:NotProvided IAVS:N PROCAVS:G RESPMSG:Approved PNREF:************ RESULT:0 EXPDATE:0618 PROCCVV2:I CARDTYPE:0 AVSADDR:X CVV2MATCH:X CORRELATIONID:*************
-> TENDER:C ORIGID:************ TRXTYPE:D
<- RESULT:0 PENDINGREASON:completed PNREF:************ FEEAMT:0.11 PAYMENTTYPE:instant RESPMSG:Approved PPREF:************ CORRELATIONID:*************
I believe the API calls should be and in fact are the same in both cases. The point of Partial Authorizations is that you don't know when you need it, so if you want it, it should be enabled for all transactions -- meaning you always append the two extra parameters of VERBOSITY=HIGH and and PARTIALAUTH=Y.
Any ideas why this isn't working. The feature is very important to my application and is one of the main reasons I'm using PayPal.
I hope I'm missing something simple, like a setting in manager.paypal.com.
From what I can see you're doing everything correctly. When something like this happens the only thing you can do is contact PayPal directly.
You can do so via www.paypal.com/mts or if you login to your PayPal account and go into the contact by phone section you should see a separate phone number for tech support directly.
I would recommend submitting a ticket to MTS and then also calling, but when you call, refer them to your ticket. They're going to want you to post one anyway, but if that's all you do it probably won't get answered for awhile, unfortunately. I've had good luck catching them on the phone, though, and can get things done much more quickly that way.
The only thing I can think of that might be an issue here is that you're using the PayFlow gateway with PayPal as your merchant. While the PayFlow gateway supports this, PayPal may not. It may only work if you're using a 3rd party merchant account on the PayFlow gateway.
That's something they will need to confirm or deny as I haven't specifically tested this myself, but again, I don't see that you're doing anything incorrectly.
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/