[D7] Add RecurlyJS PayPal support

I am also interested in this functionality.

We will need to modify the acceptPaypal field on the form, as documented here: https://docs.recurly.com/api/recurlyjs/reference#js-buildSubscriptionForm

Please, take a look my patch

Thanks @mrded! This looks great!! I'll take a look at it soon. The only part that needs visual review is how the new CSS looks, but from a technical side this all looks perfect.

Is there a way to integrate PayPal so that we can actually use that tab theme/layout that's visible in the screenshots above?

Hm, I'm having trouble with this patch. After enabling the option for Paypal, the images for credit cards disappear on the checkout page:

When disabled, the cards come back but there is an unnecessary radio button next to the credit cards, since that's the only option:

So looks like we need a little more investigation here. I installed the latest version of the Recurly.js v2 library to test this.

Same behavior I'm getting (#6).

We need to think up something with CSS, because that version of css looks good on default theme only.
Any custom theme such as Bootstrap makes it really horrible.

We need to think up something with CSS, because that version of css looks good on default theme only.

It's not just the CSS, the markup for individual credit cards disappears when the Paypal option is enabled, so there's nothing to put the background images on. I think this may be an issue with Recurly.js rather than our code, which for the most part is just rendering what Recurly gives us.

It turns out this was a requirement on jQuery 1.7+. Once installing jQuery Update and using a newer version of jQuery, things worked much better. It's surprising that the older versions of jQuery actually worked at all without the Paypal option enabled.

I think it'd be reasonable for us to depend on jQuery Update; it's dangerous trying to depend on external libraries with core using an old version of jQuery. We should update this patch with additional documentation and hard requirements.

Do you want me to add jquery_update as dependencies to the patch? Or make it works on old jQuery?

For the time being, I've added just a check and description on the option itself for Paypal, considering everything else works even without jQuery Update. Considering the need to create a new version of the module anyway for RecurlyJS v3 (#2296401: Recurly.js v3), let's save the additional requirements for the new version.

This patch adds the additional documentation and jQuery Update check. Committed to 1.x branch, thanks @mrded!

Forgot the image in the first commit, sorry about that.

Thanks! :)

Shouldn't the 'update billing information' tab be changed for PayPal customers?

A couple of reasons:

1. The tab shows a blank/nonsense credit card on file when in fact we have no credit card on file.
2. The tab gives the option of updating billing info by adding a new credit card, but it's my understanding that if the user subscribed via PayPal they cannot actually update their billing information by adding a new credit card... they will need to update their information on PayPal, or unsubscribe and create a new subscription to pay directly via credit card (See "limitations" section of https://docs.recurly.com/payment-gateways/paypal-payments)

Screenshot of th eupdate billing tab with PayPal enabled: http://i.imgur.com/ln2OTbN.png

Thanks @JordanMagnuson, good idea. I personally haven't been able to test this beyond ensuring that the widget shows up properly because I do not have access to a commercial Paypal account. Any patches you can provide to correct this appearance would be appreciated.

I think for the billing page, it should probably indicate that current "Card on file" is actually their Paypal account. I imagine the billing information we retrieve has a property of some kind to indicate it's a Paypal account.

You're correct that it seems as though PayPal users can't update their billing information, per Recurly:

If a customer wishes to switch from paying via PayPal to credit card, they will need to terminate their subscription and sign up via the new payment method.

We should indicate as much on the update billing information page, since this does not match user expectations (for which I'd think it'd be quite natural to think you could switch between Paypal and Credit Cards).

I just took a look what Recurly does for 'update billing information' on their hosted payment pages for PayPal accounts, here's a screenshot: http://i.imgur.com/wUpEdLO.png

You have a billing agreement set up with us through PayPal, that allows us to deduct from your PayPal account to pay for your subscription. The ID of this Billing Agreement is [paypal_id]. You can get more information about this billing agreement by visiting PayPal's website and navigating to Profile | More Options | My preapproved payments.

If you cancel that billing agreement, you will need to set up a new one, or you will accrue outstanding charges. You can set up a new billing agreement with PayPal below.

The 'update billing information' button then takes the user to PayPal to set up a new billing agreement.

@quicksketch: like you say, I think we could do them one better and provide some more useful information here, including the fact that the user cannot switch to credit card billing unless they cancel their subscription and start a new one, and also an indication that if their payment is being declined, they should update their payment method on PayPal (e.g. update their credit card details or bank details on PayPal directly), with a link to log into Paypal.

Is there a dev release that his has been committed to because I don't see it?

Since #2666950: PayPal support has been closed as duplicate but has not been answered here (except the version change), is there an eta on implementing this? What should be the next steps to move this forward?

I have never used this functionality on the 7.x-1.x branch so I am not familiar with the specific functionality that it provides nor can I say that I have an immediate need for adding it. If you (or anyone) is interested in contributing to getting this implemented, I would recommend beginning documenting the specific functional requirements here, or in more granular child tickets if necessary. Then, as they say, patches are welcome!

I'm confused because I am currently utilizing recurly module and have paypal enabled (most of my subscription are processed through paypal). What is it that I'm missing? I am using 1.x version of module. Does this mean Paypal option isn't available in 2.x?

@Kcannick Paypal functionality has not yet been ported to 7.x-2.x.

Dear all,

I am working on a project with Recurly and payment by both Credit card and Paypal. I found a short way to intergrated Paypal with current Recurly module. I am using Recurly JS.

I attached 2 files: recurly-element.js_.txt and recurlyjs.pages_.inc_.txt . Could anyone help me to change it to patch file, or you can change it name to recurly-element.js and recurlyjs.pages.inc then overwrite them to sites/all/modules/recurly/modules/recurlyjs/

My solution is:
1. Create a button "Paypal" in subscription page.
2. Create Javascript function paypal_purchase to handler Paypal button click.
3. The paypal_purchase will go to recurly.paypal by Recurly docs. After process on Paypal, it will return a token id, assign this token id to subscription form. Then, submit this form
4. I make some change in recurlyJSTokenFormSubmit function to verify that: if token id have value then submit the form to next step, else get token from Recurly by normal way.

I tested in Recurly Production mode already and payment process successful.

Hope this solution help anyone needed and module author to make Paypal subscription work.

Any query please contact me.
Thanks!

@nvhcuong: Take a look at the following documentation: Making a Drupal patch with Git

Just for some clarity... Is this patch included in Recurly 3x release. Because I updated to 3x previously and lost ability for users to pay through Paypal. Do I need to install dev release?

@Kcannick Paypal support has not yet been ported to the 7.x-3.x branch (or for that matter to 8.x-1.x). Patches are welcome.

unfortunately I don't have time to participate in issues but I posted a zip of my working 7.x-3.x with PayPal support here: https://www.drupal.org/node/2616832#comment-11971188

This is the major issue holding me back from the 7.x-3.x branch at the moment...

I'd be willing to sponsor some development on this if anyone is interested or has time. Send me an quote to make happen.

@JordanMagnuson would you be willing to go in on this as well?

Yes, I would be willing to sponsor development of working PayPal integration committed to the main branch of 7.x-3.x.

I need PayPal integration with 7.x-3.x ASAP, and am willing to pay for it. If you're interested in making this work, please PM me or shoot me an email via the contact form at https://www.pixelscrapper.com/contact

I got PayPal working with the module, we did a big push on development with the module in this repo so the codebase should largely be the same. The partner that worked on this was InternetDevels so you can ask them for support and integration. https://internetdevels.com/
I'm attaching a copy of my module with no guarantees as to whether it will work, I have no idea what development has happened in this repo since we moved the work forward ourselves to run on sooperthemes.com.
I use it together with the recurlyjs and recurly roles module.

There were quite a bit of changes in the module repo which were not encompassed in the attached zip file. I have tried to limit the diff by excluding what I could identify as changes that had been made in the repo. If I made a mistake, we will have to go back and re-examine the zip in #46.

With that said, there are still many unrelated changes in this patch, specifically in the CSS and JS files. If this is to be pushed forward, someone needs to pick apart what is new and what is relevant exclusively to PayPal support.

@markdorison: thanks for working on this!

After applying the patch I'm getting the following error on the recurly checkout page:
Error: Call to undefined function _recurlyjs_get_countries() in _recurlyjs_append_billing_fields() (line 662 of /var/www/pixelscrapper.com/public_html/sites/all/modules/recurly/modules/recurlyjs/includes/recurlyjs.pages.inc).
(screenshot: https://i.imgur.com/zUpzHZZ.png)

If I comment that section of code out, I then get this error:
Error: Call to undefined function _recurlyjs_append_paypal_payment_method() in recurlyjs_subscribe_form() (line 150 of /var/www/pixelscrapper.com/public_html/sites/all/modules/recurly/modules/recurlyjs/includes/recurlyjs.pages.inc).

I have given the enormous patch in #47 another pass and removed more of what I believe are extraneous pieces of the diff. This is attached, but I believe much more needs to be removed and I can no longer invest time in this approach.

That said, I am increasingly convinced that the patch I created will not easily be moved forward. There is simply too much unrelated code that has been included and I don't have the free time available to pick it apart. If someone does, an alternative approach would be to analyze the code from the ZIP in #46 to understand the PayPal implementation and attempt to manually re-implement them on 7.x-3.x.

I would love to see this pushed forward, and would be happy to review future clean patches made off the HEAD of 7.x-3.x.

Hi mark, it's been a couple of years since we started working on the recurly contrib module but most of what we added, and what I see in the patch, is the implementation of RecurlyJS form validation and styling. All the code was based on the RecurlyJS examples, like this one:
https://github.com/recurly/recurly-js-examples
It's too long ago for me to remember exactly what examples and documentation this is based on but if I'm correct you should see an improvement in automatic form validation on the recurlyJS form from this patch. Unless you also developed this separately from us and that's already in the repo.

Wish I had time to help.
I see many big websites use Drupal and recurly, strange there is not more help coming from them.

Hey guys, I added Paypal support to the module and had issue getting it to work until I realized that recurly client php library needed to be updated. The version that worked with 2.x version of module doesn't retrieve Recurly account object by token. Hope this helps.

SIDENOTE: Recurly is a horrible company to use for SMBs. If you're not an enterprise company they don't really care. I highly regret using them. I suggest using stripe or braintree instead.

#51: Yes, this is an aside, but any thoughts on Fusebill? There are no modules for some of these other providers, which is probably why most of us went with Recurly. But as a community, we should start developing other modules to work with other services if they're good alternatives. (I'm mostly interested in figuring out possible vendors for Aegir Site Subscriptions.)

I'm still willing to sponsor/pay for a proper patch adding PayPal support to the current 7.x-3.x version of the Recurly module. (Still disappointed that this functionality was mysteriously lost between the 2.x and 3.x versions of this module.)

If anyone is interested in working to get this done, please PM me and/or shoot me an email via the contact form at https://www.pixelscrapper.com/contact

Okay, I have gone back to the drawing board and created a new patch from scratch that adds basic PayPal support to the 7.x-3.x version of the RecurlyJS module. This builds on the work of nvhcuong in #32, and documentation at https://dev.recurly.com/docs/recurly-js-paypal .

The patch adds a simple radio option to the subscription form for payment method (credit card or PayPal), and shows/hides the credit card fields and PayPal checkout button accordingly. This radio option only shows up if "allow PayPal checkout" is enabled in the RecurlyJS module admin settings.

No fancy css or styling, but users can easily apply their own css to turn the radio buttons into tabs, etc. if desired.

Screenshots:

• https://imgur.com/I47wMSp
• https://imgur.com/8WIgvjD
• https://imgur.com/ogvJH7i

I have been running the patch successfully on a large production site for over a week now without any obvious problems.

Let's please get this reviewed and applied so that we can finally close this issue!

Let's please get this reviewed and applied so that we can finally close this issue!

Sounds good! We're going to need to get something in for Drupal 8 as well.

Hello Jordan, I think there are some issues with your PayPal implementation, unless I misunderstand the process:

1. Removing the address fields prevents the price in checkout from being updated with the correct tax rate for the country that is entered
2. The address will also be missing in the Recurly backend this way, or not?

I'll try to make a patch today that solves some of the issues mentioned.

I asked Recurly support and apparently there is more working involved in getting billing info with PayPal based accounts, not sure why it has to be this complicated..

Hi Jurriaan,
Thank you for the examples. The Recurly.js/Paypal integration does not pass address information in the billing agreement returned by paypal. The address detail needs to be added into the account as a secondary API request to update billing address information into the account. This is based on a limitation of Paypal where they don't include address information in a billing agreement. Further information on this aspect can be found in the Paypal section of the User Guide here https://docs.recurly.com/docs#section-limitations-of-paypal-payments-in-....

The workflow to add billing address information to the account with Paypal transactions is as follows (in this order):

With information passed from recurly.js to the API:
- create the account, add the billing information (billing agreement token)
- update the account's billing information with the billing address provided through the recurly.js form
- create the subscription

In that way, the invoice will show the billing information address.

To illustrate through an example, the PHP code would follow:

// create account with billing info token
$account = new Recurly_Account();
$account->account_code = 'b6f5783';
$account->email = 'verena@example.com';
$account->first_name = 'Verena';
$account->last_name = 'Example';

$billing_info = new Recurly_BillingInfo();
$billing_info->account_code = 'b6f5783';
$billing_info->token_id = '7z6furn4jvb9'; // From Recurly.js

$account->billing_info = $billing_info;
$account->create();

// now update the billing info with address
$billing_info = new Recurly_BillingInfo();
$billing_info->address1 = '400 Alabama St';
$billing_info->city = 'San Francisco';
$billing_info->state = 'CA';
$billing_info->country = 'US';
$billing_info->zip = '94110';
$billing_info->update();

// Create subscription
$account = Recurly_Account::get('b6f5783');
$subscription = new Recurly_Subscription();
$subscription->plan_code = 'gold';
$subscription->currency = 'USD';
$subscription->account = $account;
$subscription->create();

I hope you find this helpful. Thank you again.
Regards,

Ian
Team Lead
Technical Support

@JurriaanRoelofs: The patch was not designed to collect address information from PayPal customers. Collecting address information from PayPal customers is not Recurly's default behavior (see the screenshots at the top of this page from Recurly's own hosted checkout pages -- the PayPal checkout just sends the user to PayPal, which is what this patch does using recurly.js, based on documentation at https://dev.recurly.com/docs/recurly-js-paypal):

The patch would need to be modified for people wanting to additionally collect address information from PayPal customers (but please make sure we maintain options for this in the admin interface, for people who do NOT want to collect address information).

I have been using the patch in #54 on a large production site (500k+ pageviews/mo) for several months now, without issue, so my recommendation is that:

1) The patch in #54 is committed, as it does provide basic PayPal integration via recurly.js which is consistent with Recurly's hosted pages PayPal integration.

2) We create a new issue for adding additional functionality like address collection, for those who want it.

This particular issue has been open for way too long. We should commit the patch and close the issue and create new issues as needed/desired.

Marking #54 as RTBC based on my experience running it on a large production site for several months now without issue.

#54 is a very basic patch. Please let's commit this, then open new issues to build additional functionality, so that we don't keep losing forward progress. This issue is over FIVE YEARS old!

Right now it breaks Recurly's default behaviors related to calculating sales tax. Recurly uses the postal code and country fields to calculate tax so you shouldn't remove them.
If you really want to remove these fields for a quicker checkout you can do so after retrieving the RecurlyPlan and checking that plan.tax_exmpt property = false.
Today I'm working on a patch that adds support for Recurly addons, I'll also try to update this patch so that it won't break Recurly's tax calculation.

The patch in #54 does not remove any fields. Sales tax calculation is not enabled in Recurly by default, and neither is address collection for PayPal payments.

Sales tax calculation did not even exist in Recurly until relatively recently (a long time after this issue was created!), and depending on what you are selling and where you are selling it (esp. digital goods), this functionality may or may not be required (or it can be handled on a separate layer).

The patch in #54 adds default PayPal processing via Recurly.js as indicated in Recurly's documentation at https://dev.recurly.com/docs/recurly-js-paypal .

IMHO, address collection for Recurly.js PayPal payments should be addressed in a separate issue, such as: "Add sales tax / address collection support to Recurly.js PayPal payments."

Otherwise this just goes on and on, and eventually work that was done to solve part of the problem is lost, and then we have to start all over again.

Just my two cents. (I agree with you, JurriaanRoelofs, that this functionality should be added. I just think it could happen in a separate issue thread.)

Fixing tag.

Just putting in my plea once more that the patch in #54 be committed to the D7 branch, before all the work is lost. See comments in #58 and #61.

The patch in #54 works. It has been in use on a large production site for two years now. It adds basic, default PayPal support to RecurlyJS.

Why can't we just commit this, and open new issues for followup/adding additional features?

If others disagree, they can of course change status, etc. But wanted to poke this issue again, because it has been here for way too long without resolution.

#63: While I'm semi-actively maintaining the D8 branch, I'm not interested in maintaining the D7 one. And there doesn't appear to be an active D7 branch maintainer currently. If you'd like to volunteer, I'll happily make you a maintainer.

@colan: I'd be willing to help maintain the D7 branch. My company relies on both Drupal 7 and Recurly, and that's likely to be true for a while yet.

@JordanMagnuson: Congratulations! You're now a maintainer. Thanks for offering to get D7 cleaned up.

Okay, thanks. I will try to get some of these patches applied in the next few weeks. Cheers.

I would like to 2nd that I have been running this on two production sites for several years with no issues.

I'm currently working on migrating them to D8 and will provide a patch shortly.

Here is a patch with the same changes in #54 for D8. Should I start a new issue for this?

@JordanMagnuson Maybe i missed it in the conversation above, but I'm wondering if there is a particular reason for adding the paypal submit input button as #markup instead as a normal form element. Is this so it doesn't validate the main form when clicked? Is there a better way to do that?

May as well keep it here as folks have lost interest in D7. Fixing status as RTBC was for D7 (which the D7 maintainer can still commit).

Sorry for being MIA. Crazy last few months (as I'm sure it has been for many). I am still using the D7 version of this module, and still plan to commit the patch when I, quote, have a moment. :\

@Ioze: I would imagine there was a reason for the #markup choice, but I can't remember offhand why this was chosen over a normal form element.

Okay, I have committed the patch in #54 to the 7.x-3.x dev branch! (With a couple of slight adjustments).

I just committed the accepted patch to the 7.x-3.x branch, and am marking this issue as fixed. I think a separate issue should be started for a D8 forward port, as was done for [D8] Support 3D-Secure / PSD2 / SCA.

Justification:

• This was originally a D7 issue.
• This issue has been open for EIGHT YEARS. If we keep the same issue for D8, then D9, then D10, it will simply never be closed.
• An issue has been created for Plan for Recurly 7.x-3.1 release but we can't effectively track forward progress on D7 issue resolution if 7.x issues are tied up with 8.x forward-port needs.

Others can obviously weigh in, but it seems like best practice should be:

1. Mark issues with committed patches as "fixed,"
2. Tag the issue with "needs forward port" (or back port)
3. Open a separate issue (with link) for any other major versions that still need to be patched.

Might be simpler to just do this?

@colan: up to you. I really think it makes more sense to open a new issue once a patch is committed to one branch, as the amount of time it will take to patch the other branch(es) is indeterminate, and people should get credit for a patch that was applied to any branch (which can only happen if the issue is marked as fixed). Especially for an issue like this that has been open for several years.

Another reason is that it is not immediately evident when looking through the issue queue which fixes have been applied to which branches. If you see an open issue like this, titled, "Add RecurlyJS PayPal support", with dozens of replies, with version 8.x-1.x-dev, it is not immediately clear if the issue is still open for 7.x and 8.x, or if it has already been fixed in 7.x: you have to scroll through the comments and try to find the relevant commits and comments.

By contrast, if this issue is labeled "[D7] Add RecurlyJS PayPal support" and marked as fixed, with another open issue labeled "[D8] Forward Port: Add RecurlyJS PayPal support", and the issues are linked, it is immediately clear what the situation is: something has been fixed in the 7.x branch, but still needs a forward port to the 8.x branch.

And a final reason, again, is that combining issues that are in different states for different branches makes it difficult to track release targets for a given branch, as we are trying to do in Plan for Recurly 7.x-3.1 release. You can see that in our list of issues there, this issue is still indicated as open, since you re-opened it--even though it has been fixed for our branch.

If we want to keep this issue open, I will probably create a dummy issue to mark as fixed so that we can track it properly for our 7.x-3.1 release goals, and so that people can get well-deserved credit for helping with the D7 patch.

Just my two cents.

You convinced me, especially with the credit point. But let's at least open new issues before marking these as fixed. Otherwise, they could close before anybody creates the new ones, and those threads are lost.

Good point. Okay, I've created an issue for the D8 forward port here: https://www.drupal.org/project/recurly/issues/3205884

@Ioze: please add your proposed D8 patch to that issue when you get a chance.

Added patch in #70 to the new issue.