I am setting up Paypal Payments Standard for a website; I am using the Buy Now button that, when clicked, takes the user to Paypal for them to enter their payment information.
Now here's the rub - when the user makes a successful payment, I want to send them to a partner website and I want to pass along the key they just purchased.
So in a nutshell there would be this interaction:
User visits my site and a Buy Now form is generated with a hidden field like so (along with the other requisite Paypal-specific fields): <input type="hidden" name="key" value="xxx" />
The user clicks the Buy Now button and is taken to Paypal.
a. If they cancel the purchase they are returned to my website. (Ideally in this case the key value would not be included in the return URL.)
b. If the payment is successful the user is redirected to www.someothersite.com/payment.aspx and in either a POST or the querystring the key that was in the hidden field is passed along.
I am aware that such a scenario could be handled using the Paypal API via the Payments Professional product (rather than the Standard product), but that's not an option for a variety of reasons.
Thanks
You could add the value to the return URL you include in the button code, and that would work (usually), but it's not recommended...because of the usually part.
Even if you have Auto-Return enabled in your PayPal account there is no guarantee that your user will actually make it there. You'll end up with people closing their browser before the redirect, for example, so they'll never see the final page and any code on that page won't get run for that order.
Instead, you need to use Instant Payment Notification (IPN). This will be triggered every time no matter what, and you can process the data in the IPN however you need to: send email notifications to parties involved, updating databases, hit 3rd party web service API's, etc.
So you'll actually use your own basic return URL similar to your own cancel URL, and use IPN to handle post-order processing.
Related
I need to match the user who triggered the initial Http message sent to paypal, to the IPN i'm receiving on my backend when the transaction is completed. Since Paypal is unaware of my user database I'm looking for some kind of transaction ID.
the thing is, when a user clicks on a paypal hosted button, Paypal opens another window and processes the buyer login and every other payment steps there.
I've had a look at the URL of that new Paypal window and there is nothing there that will also be stated on the IPN.
Is there a way to check the initial http message sent to paypal from my frontend?
You can use the custom parameter to pass your own unique ID into the payment request. This would then be returned in the same custom parameter included in IPN.
The field is literally called custom and you can pass anything you want in it up to 256 characters.
You should be able to add it as an additional hidden field in your HTML form for the hosted button. If it doesn't pass as expected that way, though, you'll need to use a non-hosted button.
I'm currently trying to implement a mechanism whereby i can return a customer to a success page containing an activated PIN allowing access to a piece of software. The process is a straight forward PIN purchase without any kind of user accounts or login system involved.
I have the payment buttons and IPN script in place and working fine, but this only allows me to email the PIN after a successful payment via the IPN script, since of course the two sessions are completely separate to maintain security.
My problem with this is that i can't be sure the customer has access to the same email they used to pay with via Paypal. I had the idea of asking the user to enter which email they would like the PIN sent to prior to the Paypal redirection and then sending it as a custom value.. but then came visions of a mammoth backlog of support emails where users have entered the wrong email. I would really like to be able to redirect to a success page containing the PIN.
Thanks in advance.
I would recommend using the Express Checkout API. The payer experience is very similar to standard payment buttons, however, the user is always guaranteed to return back to your site, so you can display whatever you want on your final page.
That documentation can be a little scary, but it's really just a matter of utilizing 3 API calls.
SetExpressCheckout - This is used to setup a new transaction and will return a token that you'll append to the end of a redirect URL to PayPal. The user is sent to PayPal, they login and agree to pay, and are then sent back the ReturnURL that you specify in this request.
GetExpressCheckoutDetails - Now back on your site/application, you use this API to obtain information about the buyer like their shipping address, address status, payer status, payer ID, etc. You will need the Payer ID for the final API call.
DoExpressCheckoutPayment - This is very similar to the SetExpressCheckout request, but no transaction is completed until this call is completed. Only then does the money move.
Again, those final calls are done on your site so you can use the API response data to update your database and display details on the final page however you want to.
Keep in mind that payments could still be pending for one reason or another, so you'll want to check the status (returned in the DECP response) and display appropriate information on the final page.
IPN's will still be triggered with Express Checkout so you can adjust the IPN script to handle pending payments or anything else you may want to automate outside the checkout flow.
If you happen to be working with PHP my class library for PayPal will make these calls very quick and easy for you.
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.
I'm implementing a simple Buy Now button and I'm using IPN (not PDT) to verify the transaction.
A thing that bugs me is that I don't understand how come only after I set the notify_url field to the button I also get the transaction variables to the success URL, as GET params. It would seem normal to be the other way around.
Since the user could or could not choose to "return to the merchant's website" there's not way I should rely on that data. It does however seem to be identical to the one sent to the notify URL.
Some clarification would help. Thanks!
I know what you mean, after the user has finished paying and chooses to return to the sellers website (button in paypal page) they are redirected to your thankyou page.
I don't think it used to do this back in 2009 but now paypal will issue the redirect with all sorts of parameters in the url query string.
I'm just ignoring this information and relying on the backend IPN post which is verifiable by paypal
In my previous experience with IPN, I defined the location of the notify URL in the control panel. Once the payment is processed, PayPal sends a POST notification to this URL independent of any user behavior.
In any case, even if you define the notify_url parameter in the button, I believe PayPal will still send the payment notification seperate from the user behavior - they spawn a new process to send the data. As to why they are using a GET rather than a POST, that is odd behavior. However, in your IPN script you should still have logic that verifies the call with PayPal before you continue processing.
The payments we gather on our website are for online subscriptions and registrations for conferences. In both cases, we want to gather absolutely all information other than the payment information ourselves, and ideally pass some of it on to PayPal (so users don't have to fill in name, address, etc. twice).
I know there are solutions where the information is gathered by the server itself and then redirected to PayPal via a web services call but that's not an option, unfortunately. All secure payment information gathered has to happen off-server due to network policy.
In addition, not every form will need to be processed using PayPal. Some people will be paying via check, etc. so they shouldn't be sent to a payment page at all. Most solutions I've looked at have a "Pay with Paypal" button, so I assume a form post is necessary to go to the PayPal site, but ideally we'd want to get there via a 302 redirect. Is that at all possible? (I'm aware we could do something like a form that was auto-submitted by JavaScript but I'd prefer to not go down that route).
Whichever system we implemented would need to handle recurring (periodic) payments also.
Paypal has something called Payflow Pro. They bought it from VeriSign a few years ago.
You can use it to do a full integration with the paypal api. So that the user enters their payment details on your site, and your backend code submits the transaction to paypal's servers. Paypal will then give you a transaction id back. Keep the transaction ID, chuck everything else (like the card number) out the window.
We have several clients that use Payflow Pro. It's very good and easy to use api.
I'm not entirely sure I understand the full scope of your question, but I think I do. I've coded a number these conf. registrations (though I have not interfaced with PayPal...rather iTransact and Plug'NPay) and in my applications, I had to read through the API documentation for the system being used (PayPal in this case). Then I logged into the payment gateway and usually they have an html form generator. All this does, of course, is returns an html form with the fields labeled appropriate to their API (so the billing name and address carry over from your system to PayPal's and the user doesn't have to re-enter their information), shows you what hidden fields you'll need(like cutomer_id, etc) and the form POST path.
Then what I do is I have the user register, preview their order details on another page (where you can choose to drop their info into a DB or wait until AFTER their credit card is processed) and then upon confirmation, they go to PayPal, pay with either credit card OR check (the options always exist) and when they hit confirm, the passback URL you put into a hidden var somewhere, takes you to a custom Thank You page (and hopefully processing script to capture successful transactions) which can be hosted anywhere on your servers.
It's pretty simple, just a bit labor intensive at first as you try and figure out the new form variables specific to a payment gateway API.
Hope this helped!