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.
Related
For Express checkout, when I create a payment with intent=authorize.
after calculate shipping and tax, if the shipping + tax is greater than 15% of the original payment amount I got the error "AUTHORIZATION_AMOUNT_LIMIT_EXCEEDED".
It is very common that shipping + tax exceeds 15% of the original total especially for smaller and heavy items. What will be the way to go around it?
thanks,
Additional info:
when I look at classic PayPal express checkout's first step, It's not required to set any amount to log in to PayPal in order to retrieve shipping address, how do we do this with REST API?
https://developer.paypal.com/docs/classic/express-checkout/integration-guide/ECGettingStarted/#id084RM05055Z
That you may consider the PayPal InstantUpdate API, which allows you to update the tax & shipping calculation on the PayPal order review page (with AJAX).
Or alternatively, the common practice is to make the calculation before your payment request API call, on your website checkout flow (when customer fills in the shipping address and select shipping method), submit the precise amount to PayPal and then make the redirection.
You are not getting this error from DoEc, but later when you are later calling DoCapture on the authorization you generated in DoEC, right?
If so, then you are up against one of PayPal's protections for its consumers, which is that they don't allow merchants to get agreement for one price but then charge the buyer a much higher price. This is to avoid bad buyer experiences.
You basically have three options:
1) You can call PayPal CS and ask them to give you special permission to exceed the 115% limit. If you have enough history & volume with PayPal without generating disputes from users, then they may give you this permission. But this permission is usually only extended to large/trusted brands.
2) You can add an estimated tax, shipping and handling charge to the auth in Express Checkout. You would still tell the user that precise tax and shipping will be calculated when the item is shipped and their exact cost will vary. But your estimated charge should get you within 115% of the total. (Note: you usually should be able to get tax precisely at time of sale....)
3) You can decide on a fixed shipping and handling charge that allows you to cover your costs in aggregate and charge that in the EC flow. Yes, on one item that is larger/heavier than you expect you may loose $5, but on another that is smaller & lighter you will come out $5 ahead. This is what most people do.
I'm new to PayPal and overwhelmed by all the possible approaches for integrating with PayPal.
As a start I want to implement one single subscription with monthly recurring payment. When the user returns to the site after fulfilling the payment, he/she will instantly be upgraded to "premium" member (digital product only - no shipping involved).
The first alternative I've looked into is the Express Checkout API, which looks ok, but is there any simpler way to do it?
Can I for example create a standard button (JS button or the form based), but still be able to verify the payment details when the user returns, using either the REST API, IPN or something else?
Any hints on best practices are appreciated.
Yes, there are entirely too many ways to solve this problem by now.
You can probably satisfy your requirements via buttons (aka Standard), Express Checkout (aka Pro) style APIs, or RESTful APIs, but there are a few gotchas to know:
First, PayPal has several products to do recurring payments; these products have functional differences and are tied to different integration styles. So (for example) PayPal's product called "subscriptions" (tied to Website Standard aka buttons) has different (and generally less flexible) capabilities than "recurring payments" (tied to Express Checkout) which in turn differs from "billing agreements" (tied to REST APIs, although the term "billing agreements" is also used in the express checkout recurring payments product). Oh, and there's another similar product tied to the Adaptive Payments suite of APIs.
Confused yet? Sorry. But it is important to determine whether the specific product you want to use will satisfy your requirements first before you do any integration, or you might end up redoing that integration work later (and potentially have to migrate customers, if you have already opened your business) in order to get access to specific features of another product later on. E.g., the subscriptions product has very limited ability for sellers to modify the subscriptions after they are set up. If that is OK, then great, use it -- it's simple to integrate. If I can oversimplify a bit: the Standard subscriptions product is the oldest and most limited; the Pro recurring payments is more flexible and mature; the REST billing agreement product is the newest, very flexible, but not yet as widely used; it may lack a feature you need today, but is the most likely to be continually improved going forward. I would not personally recommend the Adaptive product, although it also has its benefits.
Now, to your integration question: fortunately all these PayPal products can use IPNs. Unfortunately, IPNs are not instant. They generally arrive quickly (1-2 seconds) but delays can happen and it is quite awkward to be unable to process the customer. I would use IPNs only when shipping physical goods, not for immediate access to digital goods or in other cases where customers are waiting for a page from you. Fortunately, each of the other methods has a way to instantly determine the success of a PayPal action without waiting for an IPN:
Website Standard Payments will include GET or POST variables when it posts the user back to your site that will tell you about the outcome. If you use the Payment Data Transfer feature, these variables will include signature information so that you can post them back to PayPal & PayPal will verify their validity (so that a would-be thief could not fool you by engineering a post that looks like a PayPal success redirect).
The two API-based methods are even easier: the APIs themselves return all the information you need in the API response. So wherever in your code you make the call to create the subscription/agreement, if you get back a success then do your work to make your user premium.
There is the odd case of a user successfully paying and then getting "lost", as it were, e.g. the redirect failing/browser closing before they return to your site, or your site choking while trying to turn on the user. For this reason many people advise using IPNs, which PayPal will attempt to redeliver until you verify them back to PayPal. Not a bad idea, depending.
And of course you can call search & get details type APIs to get information about your transactions & agreements at PayPal -- although again, you will need to integrate with the right API that matches the product you are integrated with (e.g. Standard-based subscriptions won't show up if you ask the REST interface for billing agreements).
Hope this helps.
I use paypal express checkout on my website which adds specific postage amounts dependent on how much is spent by the client wherever they are in the world. However with the recent increase in overseas postage I am looking to add another postage amount dependent on where in the world the client is?
Many thanks in advance
Steve
If you are using Express Checkout, you could utilize the Callback API to calculate the shipping and taxes and have it correctly displayed on the checkout page. Your server would be performing the calculations and then sending it over to PayPal to update the checkout page based on what shipping address they select from their PayPal account. Some merchants will even tie this in with other API's through 3rd party shipping to get accurate shipping charges. You can find more on the Callback API in the Developers Guide, on page 55. And there is some information here as well.
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.
I am trying to use the Recurring payment API offered by PayPal.
I have a scenario which I am not able to address directly. It goes like this.
We have a website where we sell some services. Now the services are charged per user license. A user can buy/cancel user license in between. We want to offer the customer a recurring billing option. We have to notice here that the amount may vary each billing cycle based on the number of user licenses the customer uses during that cycle.
Is there any way I can achieve this using PayPal recurring Payment API's.
I realize this is a very old post, but it still shows up for Google searches, so I thought I'd add:
Paypal does allow you to do this now, using their new adaptive payments api.
Authorize.net also has a service that might work called Customer Information Manager.
The recurring payment option is a fixed amount that the customer pre-agrees to pay each month (or period). To do what you're trying to do, a customer would have to pre-agree to pay whatever amount you decide to charge at a later time. This means pre-authorizing an unknown payment amount, which will not be allowed by any payment service.
Your only options are:
Bill the variable amount each month (i.e. no subscription).
Set up a subscription where the monthly amount is the maximum that could potentially be billed, and then refund the difference each month.
Good luck with #2 - I would never agree to such a thing as a customer, personally.
What you're looking for is covered in the UK by the Direct Debit system, however given the potential for abuse it's very tightly controlled and there are a lot of restrictions and regulations governing it.
I'd strongly suggest you just set up a monthly invoicing system that just bills the client each month.
I don't know its meaning full or not as it is a very old post.
Instead of creating recurring profile on PayPal Server, You can store the customer's credit card on the PayPal using REST API: https://developer.paypal.com/docs/api/#vault then every month you can fetch it and charge it like recurring Payment Or When client is no longer with the services then just remove its card from PayPal.
I suppose Authorize.net SIM method also does the same.
Hope this make sense.