0

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.

ClaytonQ
  • 103
  • 1
  • 6

1 Answers1

0

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

Drew Angell
  • 25,968
  • 5
  • 32
  • 51
  • Thanks Andrew! This is extremely helpful. – ClaytonQ Mar 22 '16 at 00:51
  • My new understanding is: – ClaytonQ Mar 25 '16 at 15:34
  • 1) I will make a normal button, but it won't be pre-compiled. I'll have the page POST back to itself, then in code-behind I will put all the NVP together. The notify URL will have the user's MemberID in the querystring. 2) They will pay at PayPal. 3) PayPal will do IPN at the notify URL. I will get the MemberID and a message whether their Payment is valid or not. 4) They will click a link on the final PayPal page to go back to my site. 5) At that point, and whenever they log in thereafter, I will use the NVP api for Payments Pro to check if their payment is up to date. – ClaytonQ Mar 25 '16 at 15:41
  • I just realized there's a difference between Recurring Payments and a Subscription. The button I have is a Subscribe button. This makes sense to me because they are buying access to the premium parts of the site for a year. But, that means "GetRecurringPaymentsProfileDetails" is probably the wrong command since it is for Recurring Payments and I need a Subscription. What command can I use to tell that their subscription is still active? – ClaytonQ Mar 25 '16 at 16:20
  • I found http://stackoverflow.com/questions/9359442/paypal-subscription-vs-recurring which helps with my latest comment. – ClaytonQ Mar 25 '16 at 16:38
  • My new, new understanding is: 1) I can make a pre-compiled button with a new parameter, then in my HTML I can override the value of the new parameter just by adding an extra hidden input. No code-behind necessary. As explained here: http://www.brianmoreau.com/articles/paypal_buy_now_button_sending_custom_variables.php. Steps 2-5, unchanged. – ClaytonQ Mar 25 '16 at 19:53
  • I would not recommend passing data in your notify URL. That will get screwed up at times. It's better to use the CUSTOM parameter in the payment request and then pull that back out within IPN. In my answer I mentioned that GetRecurringPaymentsProfileDetails would only work with recurring payments. The Standard Subscriptions do not have any API access, unfortunately. – Drew Angell Mar 25 '16 at 22:52