I have a website where I am using Cart66 that sends orders to PayPal Express.
Assuming the customer does not have nor wish to create a PayPal account:
When going through desktop - the customer gets a chance to add notes to merchant/seller. However, when using mobile, there is no such field.
Cart66 support says it is a PayPal issue... But I have been over all setings I can find... But maybe i am missing something obvious?
Seems like in-context does not support it yet
https://developer.paypal.com/docs/classic/express-checkout/in-context/popup/
https://developer.paypal.com/docs/classic/express-checkout/in-context/integration/
(That said, inspecting the Cart66 - they are not calling the new "In-Context" URL that is specified in requirements, but I still that it the reason)
Related
I am trying for the first time to implement a PayPal Checkout solution (aka PayPal Commerce Platform for Business) in an ASP.NET Web Application, using Web Forms. I've set up a new REST API for the Sandbox and followed PayPal's Set up server-side SDK guidance to install the SDK in my .NET project. PayPal's button demo now lets me log into the Sandbox with a newly created Sandbox user name and make a test payment, which is confirmed as being successful. So far, so good.
My next step was to create a PayPalButton.aspx page containing exactly the same code as used on Paypal's button demo page. All my updated code was then uploaded to my live site. That's when I hit a problem, as the PayPal buttons don't work on my live site (the PayPal log in window just briefly flashes and then disappears). Being a total newbie to the Paypal Checkout process, it's highly likely that I have made some very basic error.
The only thing I can think of is that my problem might have something to do with the section in Set up server-side SDK that refers to modifying HTTP request headers? I didn't understand what that section was asking me to do.
What routes/paths did you implement the create order and capture order functions at? What data do they return? Update your question with this information. For the create order route, is the data a valid JSON object with a PayPal order ID in the id key?
Have you set the paths in your "PayPalButton.aspx" HTML/JS code to call the aforementioned routes? Your question does not include any specific information about what is going on, i.e. your button code and the result (Response body) of the fetch calls from the browser's developer tools 'Network' tab.
This morning, I managed to resolve the problem with my PayPalButton.aspx page just briefly flashing the PayPal login page. As previously mentioned, it contains a script copied from PayPal's button demo. I then realised that it was different from the sample script provided on the Integrate Checkout page.
I created a new PayPalButton2.aspx page containing this alternative script and, unlike PayPalButton.aspx, it worked fine. In both cases, I had substituted my own Sandbox ClientID.
I'm using ASP.Net Membership Provider for logging into the premium content of this web site. The content isn't downloads, it's web pages of information and discounts, etc. That part is done. We want them to also have a PayPal Subscription annual payment to see the premium content. I would like ASP Membership and PayPal Subscription to work together as much as possible, but for the minimum I am thinking they will have to create a MemberId before they pay. Then I will send that MemberId to PayPal to associate the two.
I think I can do that like this:
Set "Auto Return" on in the interface so that it will redirect to return URL when payment is made.
Set "return URL" query string to MemberId. This requires not using the precompiled "Saved" buttons. I'll have to set it in Code Behind with Name Value Pairs, "NVP" to PayPal. I was hoping to just paste the stupid button.
But then, there were those "Advanced Variables" in the Button maker. Problem was they are compiled into the Saved button, so I can't change them for each person. But maybe that one parameter could be separate from the compiled parameters? Is this better than hacking the return URL? Are "Advanced Variables" good for anything?
All the details about the transaction will be POSTed to the return URL if I put in the right code, which might be rm=2. (Right?) Then I can record it.
This process is said to be unreliable, though, and PayPal recommends using a secondary system that they have, "IPN". PayPal sends the transaction details to me. I send them back http 200 code. Then I send it back to them in the same order I got it. Then they send me http 200. Then we all know it's good. This sounds like a few hours research to me, but if you've already done it once, it sounds like copy and paste. I hate reinventing the wheel. Is there a .Net sample of this IPN handshake/dance?
Also, if I do the IPN thing, maybe I don't need Auto Return. Maybe I add MemberId to "notify" URL instead of "return" URL. Then PayPal can handle the confirmation page, email, etc. Is that better?
Assuming we get the Subscription paid for and recorded with the MemberId, at least once per user session, after they log in, I have to check if they have paid their PayPal subscription and if it's up to date. "GetRecurringPaymentsProfileDetails" does this, but it is an API operation. That makes sense, but I was hoping to avoid learning their REST API. (Is there a "NVP" version?)
REST API OAUTH tokens expire every few minutes, but the only way it tells to get one is by using "Bash" to "cURL" some Linux commands. Again, this seems like the kind of thing that would only ever have to be written once. Does this already exist as a sample code somewhere?
(I don't want to use the API to do the Subscribe, because I don't want the Credit Card numbers to ever go to our site. Too much liability. That's why I wanted PayPal.)
Will this even work? I know PayPal has 18 ways to do everything and they all exclude each other, and I'm just getting the feeling that I'm creating a patchwork of unrelated ideas to fool myself into believing there's a light at the end of the tunnel. I've already been researching and experimenting for 10 hours or so. I really thought, going in, I'd just be pasting a stupid button.
If you want to just "copy the stupid button" then you'll have to stick to Payments Standard, and then you'll be limited with what you can do. For example, you won't be able to use GetRecurringPaymentsProfileDetails for a standard subscription.
Instead, you'll need to use Express Checkout and / or Payments Pro. There is indeed an NVP API available for these, and there is also a SOAP/XML version. Details on those can be found here: https://developer.paypal.com/docs/classic/api/
Specifically, for Express Checkout, you'll want SetExpressCheckout, GetExpressCheckoutDetails, DoExpressCheckoutPayment, and CreateRecurringPaymentsProfile. Some of those calls are optional depending on how exactly you're configuring things with the checkout flow.
For Payments Pro you'll use either DoDirectPayment / CreateRecurringPaymentsProfile or PayFlow depending on what version they put you on.
In any case, IPN is definitely the way to go for post-transaction processing.
.NET IPN Sample - https://github.com/paypal/ipn-code-samples/blob/master/paypal_ipn.asp
I have just created my first PayPal button and it is working correctly within sand box. I would like to know the best way (if possible) to issue a unique activation code on my return url ensuring that the user has definitely paid before they receive the code. I could manually email the code but wondered if the was any way of automating this using some sort of return value? Possibly returning to an aspx page which then reads from my database to get the next activation key and displays it?
Thanks
Garry
As you already know that PayPal doesn't provide such facility for delivering activation instantly but it does offer the Instant Payment Notification API (PayPal IPN) which can be used to build such a platform.
Here is a great article for that purpose only. https://www.codeproject.com/Articles/383207/Selling-software-using-PayPal-IPN-as-an-eCommerceenter link description here
The best way to handle that would be to use Instant Payment Notification (IPN).
Any time a transaction happens on your site (whether it's a payment, refund, cleared pending payment, dispute, etc.) the PayPal server will POST details about that transaction to a script you have sitting on your server.
This script can receive the data and process it accordingly allowing you to automate things like updating a database, generating email notifications, hitting 3rd party web services, delivering e-goods, etc.
If you want the activation code to be visible on the return URL you can look at Payment Data Transfer (PDT), which is just like IPN except that it's made for use with the return URL. It is not recommended to use this, though, for post-transaction processing because there is no guarantee the user will make it back to the return URL, for one, and also it wouldn't handle things like e-checks correctly.
I have a Business Site and am using Sandbox to try to get PDT to work.
I set up return URL in selling preferences and turned PDT ON - but my Sandbox buyers do not get returned to the site.
There are warnings that if you do not format the return url properly then it will not work, but I cannot find any instruction as to what that format is. I am not sure if I specify the page I want to return to or just the root address which PayPal will something to.
I want to use it with an https, but I have also tried and failed with a different http site that I have.
Can you suggest what I might have forgotten to do?
It would be great if you could help me get started on this fairly fundamental point!
We have multiple sites that uses PayPal standard with PDT and IPN callbacks, when I switch this to sandbox mode things don't work but works outside of the sandbox. Try connecting to the live urls and see if that works, you can always refund payments if they go through.
In the posting url you can specify &return=XXX where XXX is the url encoded url back to your site
[This will override the setting within PayPal which is handy if you have multiple sites using the same PayPal account]
You can also specify the IPN (which should also be implemented) using ¬ify_url=
I got an auto-return to work in the sandbox!
Not quite sure what I did BUT it might have been that I set up PDT and IPN in the sandbox site, instead of just in the live site.
thanks for replies. I am not out of the woods yet, but I now live in hope.
After paypal updated their interface (sandbox.paypal.com for example is not working, now you have to go to developer.paypal.com) many of the things are not working: 2 of them are particularly frustrating and I was hoping someone here knew how to get around them:
Am I the only one whose sandbox customer test accounts are not able to make purchases? The transaction page says they are not available.
IPN validation is not letting me send a https request. When I do it says there is something wrong with the server name. Yesterday however before the update I could get verified status. If I dont put https, now my handler gives me an invalid responde status, code: 400. What does it mean?
To fix the HTTP 400 error, follow the instructions in https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 and update your code to pass "Host" information. Ideally, things should work with just the recommended changes from the above link. Apparently, thats not the case. Here is a fix from one of the PayPal MTS person - PalPAL sandbox IPN processor rejecting all messages?
Remove the "cmd=notify-validate" option from the validation URL. I tried this and it worked. Though it doesn't return the right string, atleast it doesnt break with the 400 error.
While we wait for a fix from Paypal, I wonder how a company like PayPal can cause such a huge blunder and not post anything on their status page - https://www.x.com/developers/paypal/documentation-tools/site-status/pp-cri. It just makes you think that even smaller companies can do a better job than companies like PayPal.
For the code:400 issue, you have to update the post to version 1.1. That information is located here.
https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 in this bulletin.
However, as I posted before the asp.net example uses a call, that does not exist, so I was only able to get mine partly working. After fixing this, the servers appear to be rejecting calls to https, or the cert they have installed is invalid.
Action Required before February 1, 2013
Merchants need to update their IPN and/or PDT scripts to use HTTP 1.1, and include the “Host” header in the IPN postback script. In addition to this bulletin, these merchants will be notified via a direct email.
Alright, seems to be fixed!
If you are having trouble logging in, like suggested above, clear cache and cookies and try again.
Regarding the error 400, seems to have been solved by paypal!