Is it possible to collect user billing detail after successful payment how?
You can collect any information you want at any time, but you might be slightly limited based on PayPal features you're using.
For example, if you're using a standard payment button you could setup a form for them to fill out on your return page after they've completed. There is no guarantee they'll even make it to this page, though, and even if they do they may choose not to fill out your form. As such, it's generally recommended to collect any necessary data prior to sending the user over to PayPal for payment.
That said, one of the benefits of using PayPal for buyers is that they don't have to fill in forms and don't have to share billing information with you, so you might actually lose sales if you do that.
PayPal will send you an address via IPN (or GetExpressCheckoutDetails, for example) but they only consider that a shipping address. If I'm working with a system that requires both a billing and a shipping I usually just use that same address for both.
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.
Unless I'm missing something there doesn't seem to be a way to calculate shipping based on the customers address using the latest express checkout.
I'm aware that it can be done using the old legacy nvp instant api callback.
Just seems to be slightly ridiculous to not have this if this is the case.
It's one of those things to account for. Sales tax is another - also dependent on "where".
You'll get the address after a Paypal user "accepts" (aka "approves") your Paypal payment request. You can make adjustments not exceeding 115% of the original total of the payment originally requested.
Usually ok for sales taxes, but depending on your needs, may not work for shipping (e.g. can't do "flat" shipping rates, international shipping or if US, outside of continental US) so may need to account for it in your checkout flow e.g.
ask user for zip/country (data you can use for "estimate") prior to payment flows
perhaps restrict and/or make adjustments, if needed (along the 115% limit).
Hth...
I've made contact with Paypal who have advised they are working on a solution similar to the instant callback api that will work on the latest express UI.
This is probably a stupid question, I think I'm having a mental block.
I want to use Paypal's express checkout for buyers to make purchases with as few steps as possible (also using Paypal's optional account feature). The problem is: for me to direct the user to paypal, I will need to have calculated shipping costs, which depends on the country they're in. Obviously I cannot know this unless I have been told one way or another. What are common solutions to this problem?
Ideas:
Use their IP address. Not reliable - various types of proxies, VPNs, anonymizers etc.
Have the user select their country from a drop-down box before I redirect them to paypal
Force them to log in using Paypal's Identity service before calculating postage
Use 1. or 2. and once payment is received, if country is different to expected,
Refund buyer the difference in postage cost or request an additional payment. (Hardly ideal)
Similar to 4., instead of "Sale Payment Action for Express Checkout" Use 1. or 2. in conjunction with one of Paypal's delayed express checkout payment methods and if necessary reduce or increase the amount charged:
Authorization Payment Action for Express Checkout
Order Payment Action for Express Checkout
I'd like to know what solutions other developers have chosen - maybe I've missed an idea. As a consumer, I cannot remember seeing solutions to this.
The general way people do this is simply to use GetExpressCheckoutDetails to obtain the buyer's shipping address, apply any shipping/tax as necessary, and display a final review page on your site that the user would confirm before calling DoExpressCheckoutPayment.
If you want to eliminate the additional review page (PayPal's and then your own) you can use the Instant Update API.
In this case you would include an additional parameter on the URL when you redirect to PayPal (useraction=commit) and this will change the button on the PayPal review page to say Pay instead of Continue.
Also in your SEC request you'll include the CALLBACK parameter and include a URL to your callback listener. PayPal's review page will POST the buyer's shipping address to this callback URL so that you can receive the data, calculate shipping and tax accordingly, and send a response of those options back to the PayPal review page. This will populate the PayPal review page's drop down menu for the shipping option and the user can choose accordingly.
This method allows you to utilize the PayPal review page entirely and finalize the payment there so that the only thing the user sees once they're returned to your site (after you call DECP) is a final thank you / receipt page.
I working on an e-commerce site where I need to do something like this.
When the users is on payment page, he should be doing the following things:
- pays a fee
- authorize the payment of an amount (which could vary, but not with a big amount...)
Up to here, everything goes find with PayPal Direct payment system.
But I need more. I need that the authorized amount at some point to be directly charged by another seller (or transferred)
Any chance I can do this with PayPal Direct (such the the payment would still be made in site)? Or is there any other method?
If you're receiving the money via DoDirectPayment you could use MassPay or Pay to send funds to a 3rd party. If you want the split to happen within the original payment you can use Pay by itself and set it up as a parallel or chained payment. See the Adaptive Payments documentation for more details on that.
(Disclaimer: I am employee) Balanced will work for your use case
capturing cards directly without sending user to a third party site
paying out to a merchant of your choice via ACH payout at a later point in time.
The caveat is it's US only so if your outside the US let me know and I'll see if I can find any other options for you.
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!