I have a situation I am unable to fine the answer. I am using Paypal Express checkout method by simple form method not api . when user/buyer reaches the paypal payment page and after successful payment it give user/buyer two button option ( your paypal account ) - ( return to site) If user returns to site good enough get all the transaction details but incase he does not there is no way to capture the transaction result. Is there a return url that can be specified in the html express checkout method also does it require the seller to enable Ipin in his account or is it enable by default .
My issue is its a thirdparty application where seller adds his paypal account to accept payment but one successful payment it needs to return the website . issue cant ask seller to enable any specific things to his paypal account as if he does or does not there is no way for me to verify while he sets up the account to my service or platform .
You need to be using Instant Payment Notification (IPN) to handle that instead of Payment Data Transfer (PDT). They're essentially the same thing except that PDT only works on the return URL (which isn't guaranteed to get hit as you're finding out) and IPN will be triggered in the background regardless of whether or not the buyer makes it back to your return URL.
You can include the "notify_url" parameter in your HTML form code to pass the URL you'd like the IPN's to get sent to. This will override any setting the merchant might have setup in their own PayPal account.
Related
I am using the PayPal Adaptive Payments API in a simple (not chained or parallel) flow: payment is created, payKey is generated, user is redirected to payment approval URL in PayPal. Once approved, PayPal redirects the user back to my app.
The specific API call I am using is documented here - the _ap-payment command. So the URL looks like https://www.paypal.com/cgi-bin/webscr?cmd=_ap-payment&paykey=value.
I have noticed that sometimes the PayPal page the user is directed to defaults to the login view, whereas other times it defaults to the credit card info view (for submitting a CC payment via PayPal w/out logging in to a PayPal acct).
For user experience, I would like to ensure the user always sees the PayPal login view.
Anybody know if there's a way to enforce that?
(or if there's something in how I'm calling the API that triggers one view or the other that I haven't noticed yet)
thanks!
There is a variable in Express Checkout called "LANDINGPAGE" which determines which payment option is the default one shown to the customer.
The two appropiate values for this variable are :
Billing - Pay via debit/credit card
Login - Pay via PayPal account
This is the only API-based variable which would allow you to customize checkout page to decide which landing page was shown to the customer first.
You can have a try.
My client wants us to automatically return the user to PayPal during the Express Checkout process, effectively clicking the "confirm and pay" button at the review stage if the transaction price has not changed during the process.
I can do this, but I am wondering if it is against the PayPal terms of service as it seems to me that this could be used to trick the user into paying more than they are expecting.
I have searched on the PayPal site and had a Google, but found nothing saying it is against their terms. Does anyone else do this or know whether it's acceptable practise?
You mean that you want to change the amount in the DO Express API call against the amount that you specified in SET EXPRESS API call . Yes you can change the amount in the Do Express API call because most of the time Merchant needs the shipping address information from the buyer's PayPal account. And once they get the shipping address via the Get Express Checkout API call ,shipping fee is added to the authorized amount and then DO Express API is called .
That is just fine yes, and for those instances you should set useraction=commit in your redirect URL to PayPal. This will make the button on the PayPal review page say "Pay" instead of "Continue" so the user knows that is the final review. Then back on your site you can make the call to DECP and simply display the final receipt / thank you page when that's done.
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.
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 was trying to use the express checkout php api. Everything is working well in the sandbox environment. My question is regarding security.
After payment the sample code redirects to GetExpressCheckout.php?token=...$PayerID=.....; But after clicking "confirm payment" in my site and logging in to paypal account (did not confirm payment in paypal); I directly opened the same page in another tab, and it showed payment successful (which is not the case). Is there a way to prevent this or am I missing some thing.
I'm not following exactly what you're trying to say here.
The process needs to be...
1) Call SetExpressCheckout to retrieve your token and redirect to PayPal accordingly.
2) PayPal will return the user back to your ReturnURL if they confirm payment, at which point you can call GetExpressCheckoutDetails (optionally) and DoExpressCheckoutPayment to finalize the payment.
Not until DECP is completed does any transaction actually take place. The success message you're seeing probably came from GetExpressCheckoutDetails, which does nothing more than retrieve the buyer/order info so that you can finalize the payment on your site.