Auto Return Not Working In PayPal Pro Hosted Solution? - paypal

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.

Related

paypal integration types confusion

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.

Issues with processing PayPal Payment

We are using the secure token method to process credit card payments with PayPal hosted pages. We generate the secure token by providing the required information
[TRXTYPE=S, AMT=xxx, TENDER=C, ORDERID=xxxxxxxxxxxx, CURRENCY=USD, CREATESECURETOKEN=Y, SECURETOKENID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, PARTNER=Paypal, VENDOR=xxxxxx, USER=xxxxxx, PWD=xxxxxx]
We get the success result as follows:
{"RESULT"=>"0", "SECURETOKEN"=>"xxxxxxxxxxxxxxxxxxxxxxxxx", "SECURETOKENID"=>"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "RESPMSG"=>"Approved"}
We then send this back to PayPal where the user can choose to pay with credit card and or PayPal.
When someone pays with credit card, all is fine, when someone chooses to pay using "PayPal" it asks user for PayPal credentials and once provided it shows another screen to accept the charges. Once the user accepts, we get the following error message:
{"TYPE":"S","RESPMSG":"Original transaction ID not found: xxxxxxxxxxxx","TAX":"0.00","PNREF":"xxxxxxxxxxxx","TENDER":"P","AVSDATA":"XXN","METHOD":"P","SECURETOKEN":"xxxxxxxxxxxxxxxxxxxxxxxxx","AMT":"1.00","SECURETOKENID":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","TRANSTIME":"2014-01-02 06:09:02","ORDERID":"xxxxxxxx36U1","RESULT":"19","DUPLICATE":"2","TRXTYPE":"S","action":"create","controller":"payment_notifications"}
The help I got from PayPal folks says "Looking at the logs it seems like the transaction was declined with the result code 19 which means that the transaction ID you entered for this transaction is not valid. When searched for the original transaction, I could not find any. So, it seems like the original transaction is not valid. Provide an valid original transaction ID and it should go through fine."
However nowhere in their documentation do they suggest to send this "transaction ID" variable and without it we have been processing Credit Card payments just fine.
My question:
What do i need to change in my process that I can accept Credit Card and PayPal payments?
Any help will be greatly appreciated.
It seems the issue was on PayPal side and they have yet to come back to us with an answer. Once thing which they do not openly advertise is that they have the ability to remove the Pay with PayPal button form the hosted pages so if someone else runs across the same issue they should ask PayPal to remove the Pay with PayPal button from their end, made sure to confirm that you are not disabling the service from express checkout just hiding the button.

PayPal IPN/PDT with credit card

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.

PayPal API - How to keep the payment process on my website?

I run a small marketplace with multiple sellers where buyers can buy items and pay with PayPal. The problem is, when someone makes a payment, they are then displayed the "Payment Confirmation" on the PayPal website and are given a choice to either return to their PayPal account, or return to the website.
Is there any way to keep the payment flow on my website, except for the payment part? I notice when buying on Etsy for example, the buyer goes to PayPal to make the payment and is then immediately returned to Etsy for the payment confirmation. They never see the PayPal payment confirmation page.
I assume it could be because Etsy and PayPal have a special arrangement that isn't available to other sites? Or am I missing something in the API?
Right now, with the normal PayPal API, this is what buyers see:
NAME, you've just completed your payment.
Your transaction ID for this payment is: XXXXXXXXXXXXXXXXXXXX.
We'll send a confirmation email to your#email.com
Go to PayPal account overview.
Go back to "seller#email.com".
I can't even figure out how to change the "Go back to..." link to my website name in the hidden fields. PayPal just chooses to display the seller's (the person that received the payment) email address.
Is there any way to at least set a website name for them to return to with hidden variables? Keep in mind that I have different sellers, so it's not something I could set inside each seller's PayPal account.
Thank you :)
I assume you are using Express Checkout with Set/Get/Do EC API integration. Please check the below document for experience options available with Express Checkout API.
https://developer.paypal.com/webapps/developer/docs/classic/express-checkout/integration-guide/ECCustomizing/
The 'useraction=commit' in the PayPal payment auth url triigers the 'Buy' button. If you do not send that request paramter then it will show 'continue' button and you can complete rest of the process on your site.
However, if you are using Paypal Payment Standard product then you need to use Express Checkout to accomplish the outcome you are seeking.

What if the user doesn't get redirected after PayPal payment?

After adding stuff in shopping cart, clicking some Pay Now with PayPal button, and successful PayPal payment (PP or CC), it is logically possible that a user stays on PayPal website, if for example the Auto Return option isn't activated (or it is but it doesn't work because the user is a guest user without PP account)
The user can return to the site by clicking a link, but doesn't have to. My question is: if he doesn't, how will the site owner be aware that the user paid so that he can now send the items by post? That the site owner gets informed of being paid seems elemental to me, so I find incomprehensible that such elemental thing be left to some obscure Auto-Return option.
Please can somebody explain this to me?
This is a common challenge with any redirected payment gateway, and it's the reason most (if not all) of them implement some sort of asynchronous notification that a payment has been completed. In PayPal, this is the Instant Payment Notification (IPN). You must setup on your site either a generic IPN listener that you link to from your PayPal account profile settings or you can create a more targeted IPN listener specifically for your transactions and use the NOTIFYURL (or related) parameter in the form or API request you use to redirect to PayPal to send IPNs to that listener.
In my integrations, I never perform any order update or transaction logging when the customer returns from the site, preferring instead to wait for the IPN that I can validate and ensure came from PayPal as opposed to a spoofed return from someone trying to hack my checkout process.
For more information, see the IPN documentation: https://www.x.com/developers/paypal/documentation-tools/ipn/integration-guide/IPNIntro
Paypal provide IPN for this purpose through which we paypal send request asynchronous to your site and you can perform whichever action you want
I think the point may have been missed here. Or a problem does exist. If the purchaser uses CC, even if you have IPN set up and it works, but if the purchaser uses CC and does not click a button on the last page, which is not presented when using PP account, it is possible for the funds to go through, but no IPN, and so your website is unaware of the purchase. This last page, is an extra page that CC user gets after the page with the Pay button on it.
In this state, you can even go into IPN history, and the IPN is there, says it is sent, but it hasn't been. It does not get sent until after the purchaser clicks the button on the extra page and then they are taken to the auto return page.