In PayPal Express Checkout, _express-checkout-mobile seems to auto-detect the browser and show the correct page at all times.
Are there scenarios where the mobile UI will be improperly displayed? Is there a reason to ever pass _express-checkout instead?
I've always used _express-checkout and it automatically detects which experience to use. I think if you use _express-checkout-mobile it will use the mobile experience regardless of the platform the user is on, but I haven't tested that specifically.
I've just tested it with _express_checkout, and on my mobile phone I am forwarded to the mobile payment design.
There does not seem to be a difference.
Related
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 am using PayFlow Pro hosted checkout Template C. I cannot get a mobile version of the template. I have tried putting the template, mobile in the key / values pairs on the initial request for the token and also putting the template='mobile' in the iframe request.
Neither seems to work.
Thanks for any help.
For Layout C, PayPal does not automatically redirect mobile users to a mobile-optimized flow. The reason is that if PayPal automatically showed a mobile optimized embedded template, within a merchant web page that may not be mobile optimized, this can create unexpected and undesirable results. To display the mobile checkout pages for Layout C, the Partner or Merchant must detect the supported mobile browser and then explicitly pass the form post parameter: template=mobile...however...I was just informed that there may be an issue with this feature on our end. I'll update this answer via comment shortly.
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.
It has been some time since I last set up PayPal payments on a website.
After I opened the new PayPal API and honestly, I am a little bit confused. At the moment, there is each new website considered by PayPal support?
On the following page, https://developer.paypal.com/webapps/developer/applications, I found Test credentials, but I want to set up Live credentials.
In the block with Live credentials, it is written:
Live credentials (currently for U.S. businesses)
We'll email you when your live credentials are ready.
How much it usually takes? And also, what everything is needed for being approved? Is there any way to make it faster or the only thing I can do is to wait?
Thanks
The first part of your question about new websites is unclear. But I would guess that the Classic APIs might be a better choice for your use-case, as the new RESTful API is still in a beta stage with limited features.
I see this is tagged as paypal-adaptive-payments. Adaptive Payments is its own separate API and you can read information on going live with it here: https://www.x.com/developers/paypal/documentation-tools/going-live-with-your-application
For the second part of your question, I am not sure how long it takes but my best guess from similar processes is two business days (Monday-Friday)
Live credentials are only available for US accounts right now as we currently only support America.
I have a paypal button on my site and I have a custom value that is returned from paypal to my site on completion of the transaction.
It works fine on desktops but for some reason it wont work on mobile devices like an android phone or an Ipad. the payment goes through but the value doesn't seem to be passed to my page.
thanks
Thank you for reaching out to me. We found there was an issue with the mobile flow not returning data when using RM=2. To retrieve the data you opted to switch to Payment Data Transfer (PDT) to collect the information.
We'll continue working on the issue of returning no Post data while using RM=2 in the mobile flow but at least we got your goal accomplished.
It looks like when payments are coming back through from mobile.paypal.com, any get parameters on the 'return' url are being unencoded first, so if there's a %2B in the url I pass to paypal, when it comes back, it's a + (meaning, you're decoding them on your side after the post, then encoding them, instead of simply encoding them). Same for %3D coming back as =, and I'd assume all sorts of other invalid stuff. This is not true if the 'return' comes from www.paypal.com. I'll report a bug, but I'm assuming others will want to know this information.
Chris
Update: I just got one of these malformed urls from www.paypal.com/ca/cgi-bin/webscr, so it's not just the mobile site...