Create Paypal WPP recurring fee handler

Subscribing. It is the most essential handler for the uc_recurring module!

Here's a first go of this - completely un-tested!

Notice that this patch allows implementing modules to hook into hook_menu() and hook_form_alter()

It is good news! I will test it now.. :)

Re-rolled with a small change to prevent WSOD

univate,

Now that you got #572258 figured out will that be incorporated into this patch?

It seems that recurring fee cancellation isn't working correctly. Now on calling function uc_recurring_fee_cancel() it sets renewal_interval to 0, but does not call uc_recurring_paypal_wpp_cancel() defined in uc_recurring.uc_paypal.inc. So in your drupal recurring fees you will see that fee has been cancelled but really it is not cancelled in PayPal. So it will continue charging.

To solve the problem it seems we need to add 'cancel' => 'uc_recurring_uc_credit' to uc_recurring_uc_credit_recurring_info(). It will cause invocation of uc_recurring_paypal_wpp_cancel():

function uc_recurring_uc_credit_recurring_info() {
  $items['credit'] = array(
    'name' => t('Credit card'),
    'payment method' => 'credit',
    'fee handler' => 'credit',
    'module' => 'UC recurring',
    'process' => 'uc_recurring_uc_credit',
    'renew' => 'uc_recurring_uc_credit',
    'cancel' => 'uc_recurring_uc_credit',  //XLogicSoft: w/o the line recurring payments PayPal cancellation doesn't work
  );
  return $items;
}

This is not a bug, as this is a feature request :)
We need to re-roll this according to the new changes in uc_recurring, I'm quite busy with OG7 upgrade, so I'll appreciate if some one else can do that...

Here are some bugs in uc_recurring_paypal_wpp_process function :

It seems there should be added additional processing of $unit in uc_recurring_paypal_wpp_process because PayPal API require values like Day, Week, Month, SemiMonth, Year and $unit has another format (like: days, weeks, months, years).

To solve it we need to replace the lines

/**
 * PayPal website payments pro process.
 */
function uc_recurring_paypal_wpp_process($order, &$fee) {
  // Setup variables for the payment schedule.
  list($length, $unit) = explode(' ', $fee->regular_interval);
  list($trial_length, $trial_unit) = explode(' ', $fee->initial_charge);

with lines:

/**
 * PayPal website payments pro process.
 */
function uc_recurring_paypal_wpp_process($order, &$fee) {
  // Setup variables for the payment schedule.
  list($length, $unit) = explode(' ', $fee->regular_interval);
  list($trial_length, $trial_unit) = explode(' ', $fee->initial_charge);
  
/// XLogicSoft BEGIN ///
  // Make sure we have valid values.
  if (
    $length <= 0 || 
    $unit == 'days' && $length > 365 || 
    $unit == 'months' && $length > 12 || 
    $unit == 'semimonths' && $length > 24 || 
    $unit == 'weeks' && $length > 52 || 
    $unit == 'years' && $length > 1
  ) {
    // Get a default SKU if none was supplied.
    if (empty($fee->model)) {
      $fee->model = db_result(db_query("SELECT model FROM {uc_products} WHERE nid = %d", $fee->nid));
    } 
    watchdog('uc_recurring', 'Product @sku has invalid interval settings for PayPal - @length @unit', array('@sku' => $fee->model, '@length' => $length, '@unit' => $unit), WATCHDOG_ERROR);
    return FALSE;
  }
  
  // 'weeks' => 'Week', etc. PayPal API allows billing period to be one of Day, Week, SemiMonth, or Year
  if($unit=='semimonth')
    $unit='SemiMonth';
  else
    $unit = ucfirst(substr($unit, 0, -1));
  if($trial_unit=='semimonth')
    $trial_unit='SemiMonth';
  else
    $trial_unit = ucfirst(substr($trial_unit, 0, -1));

/// XlogicSoft END ///
 

@godewebog,
It's not a bug since it's not committed, it's just a patch. It's also not critical, because the module works. Please keep the issue settings as is.

It would be best if you would re-roll the patch -- http://drupal.org/patch/create

We need this working for a site that is a few days overdue to launch, I've tried to get up to speed, but to save time, can anyone give me a heads up on what needs done to finish this module and I will see if we can push it to done (or at least functional?)

I have the uc_recurring module, but I don't see a uc_recurring.uc_paypal.inc file to patch...

I have uc_recurring 6.x -1.0, and apparently it is not working how paypal expects it to.

From paypal support:

"What I think your system is doing is collecting the customer's credit card number and running a DoDirectPayment with it according to their payment details - which is bad.

You should be doing an initial DoDirectPayment transaction along with a CreateRecurringPaymentsProfile transaction (to create the Recurring Payments Profile) and a SetCustomerBillingAgreement (to set the details of the recurring payment). "

It sounds like the patch described on this thread could be the solution I'm looking for.

What is its current status? How can I implement it to test?

Thanks,
-Trevor

subscribing

subscribing

hey guys,

what's the status on this? is there any patch for the alpha 2 module version? has anyone worked on the remaining issues since the last patch was posted? I wanna contribute on this since we need it for a site that's currently on development. Mainly we are interested in give the ability to the user to update their recurring fees profile and cc information. Any help will be appreciated.

thanks

eric

Find attached a version of the PayPal WPP recurring handler (uc_recurring.uc_paypal.inc). It is not completed version and even not tested. I just have ported an old working version of the handler to recent version of the uc_recurring module.
I hope it will be useful for somebody.

Find attached a version of the PayPal WPP recurring handler (uc_recurring.uc_paypal.inc). It is not fully completed version but already tested and working. Currently it can create Paypal Recurring profiles, cancel Paypal Recurring fees.

Untested.
- Moved code to uc_recurring_hosted
- Code cleanup
- Next I'm going to work on allowing rcurring paypal pro gateway to be the *only* gateway.

Related issue, so PayPal pro will be able to be the payment gateway -- #635070: Allow altering payment gateways - next is having uc_recurring do the altering for all implementing modules.

Keep up the good work, Amitaibu. I'm finishing some features for a client at the moment, but in a week or two I'll jump into testing this and will land a hand as much as I can.

Thanks,
Andrey.

Patch includes implementation of alter from #635070: Allow altering payment gateways. We'll have to copy almost all uc_paypal_wpp_charge() into uc_recurring_hosted() as this part of ubercart is not very flexible..,

Still un-tested, but all pieces are in place!

With the alter we have a callback that either process an order as recurring, or redirects back to the original callback. Some go and push #635070: Allow altering payment gateways forward ;)

A bit more code cleanup - and a call for help to people with more PayPal pro experience than me:

nvp_request

 array
  'METHOD' => string 'CreateRecurringPaymentsProfile' (length=30)
  'DESC' => string 'Order 54 at D6_dev' (length=18)
  'PROFILESTARTDATE' => string '2009-11-20T13:06:57+02:00' (length=25)
  'CREDITCARDTYPE' => string 'Visa' (length=4)
  'ACCT' => string '4012888888881881' (length=16)
  'EXPDATE' => string '012013' (length=6)
  'BILLINGPERIOD' => string 'Day' (length=3)
  'BILLINGFREQUENCY' => string '1' (length=1)
  'TOTALBILLINGCYCLES' => int 0
  'AMT' => float 10
  'EMAIL' => string 'amitai@gizra.com' (length=16)
  'MAXFAILEDPAYMENTS' => int 3
  'NOTIFYURL' => string 'http://localhost/d6_dev/uc_paypal/ipn/54' (length=40)
  'CURRENCYCODE' => string 'USD' (length=3)
  'FIRSTNAME' => string '4012888888881881' (length=16)
  'LASTNAME' => string 'test' (length=4)
  'STREET' => string 'test' (length=4)
  'CITY' => string 'test' (length=4)
  'COUNTRYCODE' => string 'TN' (length=2)
  'STATE' => string 'CA' (length=2)
  'ZIP' => string '0000' (length=4)
  'CVV2' => string '123' (length=3)

nvp_response:

array
  'TIMESTAMP' => string '2009-11-19T11:06:57Z' (length=20)
  'CORRELATIONID' => string '55fbdaa05ac37' (length=13)
  'ACK' => string 'Failure' (length=7)
  'VERSION' => string '3.0' (length=3)
  'BUILD' => string '1105502' (length=7)
  'L_ERRORCODE0' => string '10004' (length=5)
  'L_SHORTMESSAGE0' => string 'Transaction refused because of an invalid argument. See additional error messages for details.' (length=94)
  'L_LONGMESSAGE0' => string 'Invalid argument' (length=16)
  'L_SEVERITYCODE0' => string 'Error' (length=5)

"Invalid argument" -- hmm, thanks PayPal... but which argument? :/

longwave helped me on IRC, and the issue was the VERSION that should be 53.0 or higher -- patch to Uberacrt - #637168: Allow overriding API credentials in nvp request. Now I get "Internal error" - much better ;)

I'm still getting the "Internal error", but one time I got a success - check it out :)

Tested and working! :)
[EDIT - the charge part is working, still haven't tested update/ cancel]

The internal error was solved by changing the dummy credit card number to 4716175559008831

subscribing

subscribing

subscribing

Hmm.. I can't get it to patch correctly.

I just unpacked the latest .zip, placed it in uc_recurring/modules, applied the latest patch from uc_recurring/ and got an error:

patch -p0 < 569300-uc-recurring-paypal-wpp-30.patch 
patching file modules/uc_recurring.uc_paypal.inc
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
File modules/uc_recurring.uc_paypal.inc is not empty after patch, as expected
1 out of 1 hunk FAILED -- saving rejects to file modules/uc_recurring.uc_paypal.inc.rej
patching file modules/uc_recurring_hosted/uc_recurring_hosted.module
patching file uc_recurring.module

Ready to dive into testing and helping the development.

Best,
Andrey.

UPDATE: Nevermind, got it. The latest dev of uc_recurring already comes with uc_recurring.uc_paypal.inc, I just needed to patch it.

Hmmm...

I went to developer.paypal.com and registered. I then created a new business and personal accounts. I got the API credentials, and put them in Payment Gateways, selecting:
- Authorize and capture immediately
- Enable this payment gateway for use.
- USD
- Api Server: Sandbox
I then enabled Credit Card -> PayPal Website Payments Pro under the Payment Methods.

I created a simple product, and when I try to submit the order I get this error:
We were unable to process your credit card payment. Please verify your card details and try again. If the problem persists, contact us to complete your order.

I check the logs, and it says:
Payment failed for order 484: <b>Authorize and capture immediately failed.</b><br /><b>Error:</b> 10558: Your processor is unable to process the Card Type in the currency requested. Please try another card type.<br /><b>Error:</b> 10567: A Start Date or Issue Number is required.<br /><b>Address:</b> An unknown error occurred.

So I tried disabling the card type on the Payment Methods -> Credit Card settings page, then enabling it for visa and mastercard, and no go either way. Same message.

What is the deal with the Start Date or Issue Number? I tried using Start Date, still the same error.

Any ideas?

Best,
Andrey.

UPDATE: Finally got it all figured out with PayPal. Turns out they need to enable WPP and Recurring Billing manually. Now to actual testing...

* Non-recurring billing product purchase works fine.

* Does PayPal WPP allow for remembering the user's CC info? Can we enable it on regular orders, so people don't have to put their CC info every time they buy something?

* When I get to the checkout page on a recurring fee order, I get the following errors:

# There are no payment methods configured for orders with recurring fees, enable one from recurring fee admin settings.
# Checkout cannot be completed without any payment methods enabled. Please contact an administrator to resolve the issue.

I go to admin/store/settings/products/edit/features, make sure the Credit Card (paypal_wpp) is selected on Recurring fees and Save. The error remains.

Any ideas?

Best,
Andrey.

So...

uc_recurring_form_uc_cart_checkout_form_alter() is where this check is being done, and specifically using this code:

    // Remove invalid payment methods from the payment pane.
    $valid = variable_get('uc_recurring_payment_methods', array());
    if (!empty($form['panes']['payment']['payment_method']['#options'])) {
      foreach (array_keys($form['panes']['payment']['payment_method']['#options']) as $key) {
        if ($valid[$key] === 0 || !uc_recurring_payment_method_supported($key)) {
          unset($form['panes']['payment']['payment_method']['#options'][$key]);
        }
      }

However, uc_recurring_payment_method_supported($key) returns nothing, which is unexpected. Let's look at that function a little closer...

function uc_recurring_payment_method_supported($payment_method) {
  $info = uc_recurring_get_recurring_info();
  return !empty($info[$info[$payment_method]['fee handler']]);
}

Curious that $info is repeated twice.

$info is an array:

 default  (Array, 6 elements)

    *
      name (String, 15 characters ) Default handler
    *
      module (String, 12 characters ) uc_recurring
    *
      fee handler (String, 7 characters ) default
    *
      process callback (String, 28 characters ) uc_recurring_default_handler | (Callback) uc_recurring_default_handler();
    *
      renew callback (String, 28 characters ) uc_recurring_default_handler | (Callback) uc_recurring_default_handler();
    *
      menu (Array, 3 elements) 

credit (Array, 7 elements)

    *
      name (String, 11 characters ) Credit card
    *
      payment method (String, 6 characters ) credit
    *
      module (String, 12 characters ) uc_recurring
    *
      fee handler (String, 10 characters ) paypal_wpp
    *
      process callback (String, 22 characters ) uc_recurring_uc_credit | (Callback) uc_recurring_uc_credit();
    *
      renew callback (String, 22 characters ) uc_recurring_uc_credit | (Callback) uc_recurring_uc_credit();
    *
      cancel callback (String, 22 characters ) uc_recurring_uc_credit | (Callback) uc_recurring_uc_credit();

If replaced by:

function uc_recurring_payment_method_supported($payment_method) {
  $info = uc_recurring_get_recurring_info();
  return !empty($info[$payment_method]['fee handler']);
}

... it returns "paypal_wpp" as expected.

Bug? Does it clash with other recurring fees modules? I've had Authorize.net CIM set up before, and it worked. Maybe this is a recent introduction?

Now the CC input shows up just fine with no errors. However, when I go ahead and fill out the order I get the following error on clicking "Submit order":

Your order cannot be completed, because we could not process your recurring payment. Please review your payment details and contact us to complete your order if the problem persists.

It generates nothing in the logs.

Looking at where the error message comes from...

function uc_recurring_order($op, &$arg1, $arg2) {
  switch ($op) {
    // TODO: Allow admin to create a recurring order from "create order" page.
    case 'submit':  
      if (variable_get('uc_recurring_checkout_process', TRUE)) {
        if (uc_recurring_process_order($arg1) === FALSE) {
          return array(array('pass' => FALSE, 'message' => t('Your order cannot be completed, becau$
        }
      }
      break;

... it appears something is not clicking in uc_recurring_process_order()

The "FALSE" that it picks up is after this one:

      else {   
        // We have an error, so break. No fee object was saved.
        return FALSE;

... and this is the function that didn't quite go through:

uc_recurring_invoke($fee->fee_handler, 'process callback', array($order, &$fee))

Let's check it out.

function uc_recurring_invoke($handler, $op, $params = array()) {
  $info = uc_recurring_get_recurring_info($handler);
  $function = $info[$op];
  if (function_exists($function)) {
    // Add the op argument to the params, in case the handler will need to use
    // it to identify the operation it is in.
    $params[] = $op;
    return call_user_func_array($function, $params);
  }
}

$handler = "paypal_wpp", but $info is empty! That won't do... let's see uc_recurring_get_recurring_info()... Ah, it's a hook definition.

Hmmm... the latest patch removes uc_recurring_uc_paypal_recurring_info(), which hooks into uc_recurring_get_recurring_info.

Am I missing something here?

Best,
Andrey.

UPDATE: Aha. Looks like Recurring Fees - Hosted needs to be enabled. It says that it's PalPal WPS, but with this patch it's also WPP.

This becomes a giant patch... Has to merge #658628: Add API for uc recurring hosted.

@univate, ping me when you got time, so we can review the patch together and maybe commit parts of it...

@mr.andrey, Thank you for the efforts. Try to use a debugger and follow the code. It should work :) Make sure you applied the patches:
#635070: Allow altering payment gateways
#637168: Allow overriding API credentials in nvp request

OK, did a fresh UberCart 2.2 install, patched with #635070 and #637168, latest dev (Dec.3) of uc_recurring and patched with wpp-40 patch.

Now it gives me this error with nothing in the logs:

Your order cannot be completed, because we could not process your recurring payment. Please review your payment details and contact us to complete your order if the problem persists.

Ideas?

Andrey.

P.S. How do you use a debugger? I've been doing it the manual way of inserting dpm() here and there to get the info. What's a better way?

UPDATE: I just looked on PayPal, and the order does go through, even with the error.

UPDATE: And now, somehow, magically, the order just went through and no errors were given... must be fairy dust or something *puzzled*

... and, the recurring fee got added twice!

12/13/2009
8:52:53 AM	5	Recurring fee 5 added to order.
12/13/2009
8:52:53 AM	5	Authorize and capture immediately failed.
Error: 10748: This transaction cannot be processed without a Credit Card Verification number.
Address: An unknown error occurred.
12/13/2009
8:56:52 AM	5	Recurring fee 6 added to order.
12/13/2009
8:56:54 AM	5	Authorize and capture immediately
Success: 10.00 USD
Address: Address and postal code matched
12/13/2009
8:57:01 AM	-	Customer granted user role [-] Subscribed To Sweet Vinyasa.
12/13/2009
8:57:01 AM	-	Order created through website.

Shouldn't it only create on payment success?

@mr.andrey,
Thank you for the help, but those long comments with "UPDATES" just distract the development. Regarding the debugging, I don't know which system you use, but here's one for Windows http://drupal.org/node/147267 -- although I now use Ubunutu ;)

Fixed cancellation of recurring fee.

Ok, it is time for testing, so I'll explain how to set it up, but before.

This patch needs review - so please try to review it, it shouldn't become a support issue...

1) Create a paypal account and make sure you have enabled recurring payments.
2) Patch Ubercart DEV with #635070: Allow altering payment gateways and #637168: Allow overriding API credentials in nvp request
3) Patch uc_recurring DEV version with this patch.
4) Add you API credentials to admin/store/settings/payment/edit/gateways >> PayPal Website Payments Pro settings
5) Create a product and add a "Recurring fee" feature.
6) Buy the product. Make sure to fill the billing and shipping address/ country.
7) I use the dummy credit card 4716175559008831 ; CVV = 123 ; expiration = any future date.

If you get an error check your logs (admin/reports/dblog) - usually the PayPal response will give you a hint about what you are doing wrong.

minor fixes.

@Amitaibu,

(by the way, why do people add the @ in front of a username?)

Followed your instructions...

Initial order created successfully, but the subsequent recurring fee failed:

12/14/2009
9:00:20 AM	5	Recurring fee 7 added to order.
12/14/2009
9:00:23 AM	5	Authorize and capture immediately
Success: 10.00 USD
Address: Address and postal code matched
12/14/2009
9:00:23 AM	-	Customer user role [-] Subscribed To Sweet Vinyasa renewed.
12/14/2009
9:00:27 AM	-	Order created through website.
12/14/2009
9:15:20 AM	-	Error: Recurring fee 7 for product failed.
12/14/2009
9:15:20 AM	-	New recurring fee failed on order 555.

The logs don't show anything useful, just this:

	Failed to capture recurring fee of 10.000 for product on order 554.

I checked paypal, and no $ ended up in the account from the transaction.

Any ideas?

Andrey.

P.S. Not sure what you mean about the UPDATEs, is it the length or just the fact that it's posted after in the same comment that's confusing?

subscribing

@univate,
I think it's safe enough to commit this, as it will not be triggered unless Ubercart is patched with #635070: Allow altering payment gateways (which is the only issue really needed to get this going - For #637168: Allow overriding API credentials in nvp request we can make our own custom nvp_request() function if needed).

Multiple products (recurring and non-recurring are now possible). There's still seems to be an issue as I see multiple profiles created for a single product. Anyway, that's what I have time for today.

Depends also on #661096: Clone fee object correctly and #661054: Capture the payment done with a recurring fee

Move #661054: Capture the payment done with a recurring fee code into this patch.

All patched with the latest everything, I get the following error:

We were unable to process your credit card payment. Please verify your card details and try again. If the problem persists, contact us to complete your order.

... and the logs show this:

Payment failed for order 567: <b>Authorize and capture immediately failed.</b><br /><b>Error:</b> 10525: This transaction cannot be processed. The amount to be charged is zero.<br /><b>Address:</b> An unknown error occurred.

The order log:

12/17/2009
1:55:01 PM	-	Customer user role [-] Subscribed To Sweet Vinyasa renewed.
12/17/2009
1:55:01 PM	3	Recurring fee 9 added to order.
12/17/2009
1:55:02 PM	3	Authorize and capture immediately failed.
Error: 10525: This transaction cannot be processed. The amount to be charged is zero.
Address: An unknown error occurred.

The order status gets set to "payment received", whereas it actually never happened. I checked PayPal, and recurring billing profile is created, though with no charge.

The recurring fee is set as follows: "When this product is purchased, add a fee for the same amount as the product selling price charged first after 1 days and every 1 days after that unlimited times." And price is set to $10.

Andrey.

Thanks univate.

Guys,
If no-one will review the Ubercart patches, they won't be committed...

Downloaded the latest uc_recurring dev (Dec.19).

Created a product with a recurring fee feature as follows: "When this product is purchased, add a fee for the same amount as the product selling price charged first after 1 days and every 1 days after that unlimited times."

When I add the product to cart and click checkout, I get this:

Fatal error: Cannot redeclare uc_recurring_paypal_wpp_process() (previously declared in /dev/sites/all/modules/ubercart/contrib/uc_recurring/modules/uc_recurring_hosted/uc_recurring_hosted.module:789) in /dev/sites/all/modules/ubercart/contrib/uc_recurring/modules/uc_recurring.uc_paypal.inc on line 31

This now also happens every time I go to the modules page.

Andrey

I'm seeing the fatal error, too. Given that uc_recurring.uc_paypal.inc appears to be just commented-out and stub functions, I assume that the module author meant to remove this file from CVS and forgot, maybe? Here's a patch which does that, at any rate.

Though something I noticed when I was comparing the files is this:

Old code:

-  $items['paypal_wpp'] = array(
-    'name' => t('PayPal website payments pro'),
-    'payment method' => 'paypal_wpp',
-    'fee handler' => 'paypal_wpp',

New code:

   // PayPal website payments pro.
    $items['paypal_wpp'] = array(
      'name' => t('PayPal website payments pro'),
      'payment method' => 'credit',
      'fee handler' => 'paypal_wpp',
 

Is the payment method being changed to 'credit' as opposed to 'paypal_wpp' by design?

Drawing a bit more attention to the situation. :)

Awesome, thanks. I'll try to take a look at those two issues later this week.

webchick? in D6 contrib? how 2007! ;)

Duplicate function was removed -- #664290: Remove duplicate functions

Applied the patch in #59, the error in #54 went away.

Recurring fee is created as: "When this product is purchased, add a fee for the same amount as the product selling price charged first after 1 days and every 1 days after that unlimited times." The product price is $10.

Upon order submission, I get the following error:

Payment failed for order 568: <b>Authorize and capture immediately failed.</b><br /><b>Error:</b> 10525: This transaction cannot be processed. The amount to be charged is zero.<br /><b>Address:</b> An unknown error occurred.

AND

The order status gets set to "Payment received", which is not true because the card was not charged.

I see no issues with #635070: Allow altering payment gateways and #637168: Allow overriding API credentials in nvp request just poking around Ubercart. If you want some specific testing done, let me know what you need me to do.

Andrey.

Here's a more detailed troubleshooting:

(skip to the summary below if you don't feel like reading the details)

TEST #1

1. I add recurring fee to a product as such: "When this product is purchased, add a fee for the same amount as the product selling price charged first after 1 days and every 1 days after that unlimited times." The product price is $10.

2. Using a test user, I add this to my cart and check out

3. Upon submission I get the following error message: "We were unable to process your credit card payment. Please verify your card details and try again. If the problem persists, contact us to complete your order."

4. I check the log and it says: " Payment failed for order 577: Authorize and capture immediately failed.
Error: 10525: This transaction cannot be processed. The amount to be charged is zero.
Address: An unknown error occurred."

5. I check the order, it says: "Authorize and capture immediately failed. Error: 10525: This transaction cannot be processed. The amount to be charged is zero. Address: An unknown error occurred."

6. The order status is set to "Payment Received".

7. I check PayPal, it says:

	Dec 23, 2009 	  	Recurring Payment From 	Test Test 	Created 	Details 	  	...

No mention of the actual payment.

8. I click on Details, and this is what I get:

Payment activity Payment type 	Initial Payment
Amount due 	$0.00 USD
Amount received 	$0.00 USD
Payment type 	
Payment cycle 	
Total cycles 	
Cycles remaining 	
Amount due per cycle 	 Details
Amount 	
Shipping 	
Tax 	
Total amount per cycle 	
Amount received 	
Payment type 	Regular Recurring Payment
Payment cycle 	Daily
Total cycles 	Indefinite
Cycles remaining 	Indefinite
Amount due per cycle 	$10.00 USD Details
Amount 	$10.00
Shipping 	$0.00
Tax 	$0.00
Total amount per cycle 	$10.00 USD
Amount received 	$0.00 USD
Payment summary Total received 	$0.00 USD Details

9. I open phpMyAdmin, go to uc_recurring_users and set the next_charge timestamp to a previous date. I then run cron.

10. I get the following errors: "Failed to capture recurring fee of 10.000 for product on order 577" and "0 recurring fees processed successfully; 1 failed"

11. I check PayPal, no record of any additional transaction.

Some of the previous orders, however, are getting charged in PayPal, so I try another test.

TEST #2

This time with product charging after 0 days rather than 1.

Everything is the same, with errors and all except that a new entry shows up in PayPal:

Dec 23, 2009 	  	Recurring Payment From 	Test Test 	Completed 	Details 	  	$10.00 USD

And when I click on details, I get this:

Payment activity Payment type 	Initial Payment
Amount due 	$0.00 USD
Amount received 	$0.00 USD
Payment type 	
Payment cycle 	
Total cycles 	
Cycles remaining 	
Amount due per cycle 	 Details
Amount 	
Shipping 	
Tax 	
Total amount per cycle 	
Amount received 	
Payment type 	Regular Recurring Payment
Payment cycle 	Daily
Total cycles 	Indefinite
Cycles remaining 	Indefinite
Amount due per cycle 	$10.00 USD Details
Amount 	$10.00
Shipping 	$0.00
Tax 	$0.00
Total amount per cycle 	$10.00 USD
Amount received 	$10.00 USD
Payment summary Total received 	$10.00 USD Details
Initial amount received 	$0.00 USD
Trial amount received 	
Amount received 	$10.00 USD
Trial total shipping amount 	
Trial total tax amount 	
Total shipping amount 	$0.00
Total tax amount 	$0.00
Total amount received 	$10.00 USD
Last payment activity Payment type 	Scheduled Payment
Date 	Dec 23, 2009
Amount received 	$10.00 USD
Payment Status 	Success

It did charge this time, very interesting. The product's actual price ($10) didn't work, but the $10 for the initial recurring payment, which was processed at cron run time, did, even though it said that it failed.

I ran cron again and no recurring billing was attempted.

TEST #3

Another test. Set the product price to 0, and recurring fee as follows: "When this product is purchased, add a fee for $10.00 charged first after 0 days and every 1 days after that unlimited times."

All the errors are the same, including "Payment failed for order 583: Authorize and capture immediately failed.
Error: 10525: This transaction cannot be processed. The amount to be charged is zero.
Address: An unknown error occurred."

Except now, PayPal created two new lines:

	Dec 23, 2009 	  	Recurring Payment From 	Test Test 	Completed 	Details 	  	$10.00 USD
	Dec 23, 2009 	  	Recurring Payment From 	Test Test 	Created 	Details 	  	...

Both for order 583, showing the same thing when I click details:

Payment activity Payment type 	Initial Payment
Amount due 	$0.00 USD
Amount received 	$0.00 USD
Payment type 	
Payment cycle 	
Total cycles 	
Cycles remaining 	
Amount due per cycle 	 Details
Amount 	
Shipping 	
Tax 	
Total amount per cycle 	
Amount received 	
Payment type 	Regular Recurring Payment
Payment cycle 	Daily
Total cycles 	Indefinite
Cycles remaining 	Indefinite
Amount due per cycle 	$10.00 USD Details
Amount 	$10.00
Shipping 	$0.00
Tax 	$0.00
Total amount per cycle 	$10.00 USD
Amount received 	$10.00 USD
Payment summary Total received 	$10.00 USD Details
Initial amount received 	$0.00 USD
Trial amount received 	
Amount received 	$10.00 USD
Trial total shipping amount 	
Trial total tax amount 	
Total shipping amount 	$0.00
Total tax amount 	$0.00
Total amount received 	$10.00 USD
Last payment activity Payment type 	Scheduled Payment
Date 	Dec 23, 2009
Amount received 	$10.00 USD
Payment Status 	Success

The Low Down (Summary):
* Normal order price doesn't get processed, and returns "amount to be charged is zero", whether it's zero or not.
* Recurring fee gets processed on cron run, but displays Ubercart errors saying otherwise.
* Even if recurring fee doesn't get processed, the order status gets set to Payment Received.

Hope this helps the debugging and development process.

Best,
Andrey.

subscribing

> I see no issues with #635070: Allow altering payment gateways and #637168: Allow overriding API credentials in nvp request just poking around Ubercart. If you want some specific testing done, let me know what you need me to do.

These patches need to be reviewd and RTBC so they will be committed to Ubercart...

RTBC?

RTBC = Reviewed and tested by the community

All -

As part of my work with a client, I was asked to fix this, and it appears I've got it working correctly.

The problem is that the paypal_wpp attempts to override the handler for the gateway. In doing so, it wrecks havoc on the process, because it prevents the original product price charge from going through.

Instead, the charge callback in paypal-wpp only charges products that are non-recurring, which breaks the product price which is charged originally. If the gateway alter hook is removed, then all works well.

I applied both of the patches to ubercart - and I believe one of those patches actually enables the gateway callback to be edited - however - why is this needed? Authorize doesn't seem to use this method, so why does wpp?

In any event - mr. andrey, see if this patch works for you and causes everything to be charged correctly.

Forgive me, as I'm new to this thread - if I'm off base, but it seems to be working now for me, which is what the client needs :)

@trevorwh,

The patch is wrong - that line is the key to WPP recurring payments. If you don't need WPP recurring payments, then you don't need to activate uc_recurring_hosted at all.

@trevorwh,

It should be noted, that the WPP is _suposed_ to work also when there are non-recurring items, if it doesn't then there's a bug ;)

@Amitaibu

Why is that line key to WPP recurring payments? The module doesn't need to modify the gateway to be invoked - instead, it's invoked by the uc_recurring module, which looks like how it was designed to work. The result appears to be that the paypal process function is actually invoked twice. I get that it is also setting the subscription ID, but it seems to be doing the same thing twice.

Let me know if I need to clarify - I've edited multiple times as I continue to work on this, and I know it can get confusing.

Try it for yourself - my only point was that it runs correctly and seems more in line with the way authorize.net gateway is setup within this version of uc_recurring_hosted.

This patch fixes all issues related to the gateway. It doesn't require modifying the gateway callback, and instead simply uses the built in logic in UC Recurring.

In addition to this, it takes care of saving the RFID and subscription information. It has been fully tested and is working for me - please let me know if it works for others as well, or if there are any issues.

It also fixes bugs with saving the admin comments regarding payment to the recurring order, as $order_id doesn't exist.

As I continue to work on this I'll update the patch.

@trevorwh,

Haven't tested your patch yet, but does it take care of the case when you have 2 different recurring products and 1 non-recurring product in the same cart?

+ thanks for working on this trevorwh :)

@Amitaibu

I know for sure that it works in the case where you have non-recurring and recurring products together. I'm not sure about multiple recurring products in the same cart - but I believe it should, as the uc_recurring module loops through and processes all the fees separately if they are recurring.

If the fees aren't recurring, it's simply charged normally through the uc_paypal gateway, and no recurring profile is setup.

Hope it works for you :) Let me know when you've got it tested. I'm still working on bug fixes for this module, so if anything else arises I'll continue to patch.

-Trevor

@Amitabu,

Can you reroll your patch against the latest dev? It doesn't work with Dec.31 release.

Andrey.

@Andrey,

Amitabu's patches I believe were already incorporated in the latest release, which is why they wouldn't patch. To my knowledge, they only patch the alpa3 version - did you try patching the dec 31 release with the patch I provided above?

@trevorwh,

I just tried your patch in #70, and this is what I get:

user@box:~/dev/sites/all/modules/ubercart/contrib/uc_recurring# patch -p0 < wpp-70.patch
(Stripping trailing CRs from patch.)
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: uc_recurring_hosted.module
|===================================================================
|--- uc_recurring_hosted.module (revision 8)
|+++ uc_recurring_hosted.module (working copy)
--------------------------
File to patch:

Maybe I'm supposed to apply it from a different folder? I'll try.

Ah, here we go, I applied it from uc_recurring/modules/uc_recurring_hosted, and it worked, though gave some weirdness first.

user@box:~/dev/sites/all/modules/ubercart/contrib/uc_recurring/modules/uc_recurring_hosted# patch -p0 < wpp-70.patch 
(Stripping trailing CRs from patch.)
patching file uc_recurring_hosted.module
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] y
Hunk #1 succeeded at -323 with fuzz 2 (offset -360 lines).
Hunk #2 succeeded at 893 with fuzz 1 (offset 175 lines).
Hunk #3 succeeded at 541 (offset -360 lines).
Hunk #4 succeeded at 1141 (offset 175 lines).

A.

@andrey

Glad to hear it applied correctly for you - go ahead and test that out to see if it works.

Sorry about the file confusion - I probably should have done it from the root UC Recurring directory, but instead I did an svn diff just on the file itself.

I set product price to $10, and recurring fee to: "When this product is purchased, add a fee for the same amount as the product selling price charged first after 1 days and every 1 days after that unlimited times."

Error:

Your order cannot be completed, because we could not process your recurring payment. Please review your payment details and contact us to complete your order if the problem persists.

Nothing in the logs.

Order is created, status is set to "order in checkout".

I checked PayPal, nothing there either.

Another test: product price $10, recurring fee: "When this product is purchased, add a fee for the same amount as the product selling price charged first after 0 days and every 1 days after that unlimited times."

Same result.

Ah, I just checked the order log, and see this error:

failed.
Error: 10002: You do not have permissions to make this API call
Address: An unknown error occurred.

Andrey.

@mr.andrey

Did you patch the dec 31st release, and not the alpha-3 release? Basically, that error message is telling you that it can't find the paypal callback.

Do you see anything in the logs of the order? If it is able to find the process callback for paypal_wpp then it should be saving a comment no matter what is the order log.

Thanks.

Hmm, interesting - let me check. Looking into that now.

Mr. Andrey,

Did you apply the NVP patch to ubercart? The error you are getting suggests that paypal is rejecting the credentials the module is sending.

This is the patch: http://drupal.org/node/637168

Yep, I applied both of the patches:
http://drupal.org/node/635070
http://drupal.org/node/637168

Ah! The credentials got erased somehow, how odd.. I'll put them in and try again.

OK, the last test order went through.

PayPal shows:

Jan 2, 2010 	  	Recurring Payment From 	Test JanThree 	Completed 	Details 	  	$10.00 USD
Jan 2, 2010 	  	Payment From 	Test JanThree 	Completed 	Details 	  	$10.00 USD
Jan 2, 2010 	  	Recurring Payment From 	Test JanThree 	Created 	Details 	 

It charged both the regular and recurring payment. This is great!

I'll run some more tests with various scenarios and post back my results here.

Thanks,
Andrey.

Excellent.

I'm glad to see it is working for you as well as it is working for me! Looking forward to any additional testing as well as testing from others.

There are a few minor bugs (like even the error you received should be a bit better) and then hopefully this can get committed to 6.x-2.x.

I just did a regular (non-recurring) product test, and got this error message in the order log:

Authorize and capture immediately failed.
Error: 10748: This transaction cannot be processed without a Credit Card Verification number.
Address: An unknown error occurred.

Interesting that it didn't come up when I was doing the test on the recurring.

I enabled CVV, and the order went through OK.

I also tried an order with both a regular and a recurring products. Everything looks OK.

01/02/2010
3:34:12 PM	3	Recurring Payment Setup
Recurring Success: 10.00
01/02/2010
3:34:12 PM	3	Recurring fee 9 added to order.
01/02/2010
3:34:14 PM	3	Authorize and capture immediately
Success: 20.00 USD
Address: Address and postal code matched
CVV2: Match

Andrey.

@Andrey,

I'm not sure about the CVV issue, as it comes from the main uc_paypal gateway.

Glad to hear recurring/non recurring products are working correctly.

What about storing the person's profile, so when they buy something again, they don't have to enter the CC info?

We had it set up with Authorize.net as a gateway before, and that was one really nice thing about it. Can we reproduce that with PayPal as well?

At the moment it just displays last four digits where the card # is supposed to be and gives an error on submission.

Andrey.

The automatic recurring fees seem to be processing OK. They show up on PalPal and new orders are created.

However, the new automatic recurring order (renewal) status gets set to "pending", even though the payment went through OK.

Any ideas on that?

Andrey.

Hmm - I don't actually know on this one.

Are you using a conditional action to set them to complete?

In the conditional action, one of the conditions on successful renewal completion is the order balance of $0.

A renewal (automatic recurring fee) creates a new order automatically, but doesn't register the actual payment in that renewed order, so the balance is always in the positive by the amount that was charged.

Instead, the payment gets registered with the original order, offsetting it's balance by that much into the negative.

I would imagine that the correct behavior would be to either change the balance of the original order instead of the new one, or register the payment with the renewal order rather than the original.

Andrey.

Another question...

I noticed that PayPal ends up automatically charging, even if the recurring fees do not get processed by ubercart/cron. Ubercart sets up the schedule, but PayPal seems to follow it regardless afterward. What happens if cron gets lagged behind, and Ubercart ends up trying to charge after PayPal already charged? Is there any danger of double-charge or something odd like that?
Thanks.

In regards to your second question, the UC_Recurring module never actually makes a call to PayPal after the initial transaction - at least this is my understanding.

So, PayPal follows the renewal schedule automatically until you cancel - regardless of what happens. This is probably why the transactions are logged in the original, and not the new order created.

This is probably something that also needs to be addressed in uc_recurring instead of in the gateway.

I'm open to thoughts?

@univate,

What happens though if the recurring agreement with PayPal contains the original order ID, and is processed regardless of a cron run?

So, even if the new order is created, PayPal doesn't care/doesn't know about it, because it only has the original order id. How would I determine a new order has been created and apply the payment there instead once we receive the IPN request?

... and also, wouldn't PayPal and cron gradually drift out of sync?

Let's say the order was created at 12:05 on the 1st. PayPal will forever after (until canceled) rebill every 30 days at 12:05.
Assuming cron runs once an hour, the next recurring fee will not be run at 12:05, but at 1:00, thus setting the following fee to around 1:01.
The next time, cron runs the fee at 2:00, and schedules the next fee for 2:00:15, etc.

Thoughts?

And what happens when the credit card expires?

So just to summarize, the still sanding issues are:

* Original order records the payment, while the new (renew) order gets the balance offset, resulting in both producing incorrect balance.

* Let users update their CC info.

* Sync issues between PayPal and Ubercart/Cron - gradual drift.

* How to handle credit card expirations.

Thanks for all the great work so far!

Andrey.

I asked PayPal about the credit card expiration, here's their reply:

If the buyer signs up using express checkout than they will be notified through their PayPal account of credit card expiration and will have an opportunity to change it within their account. However if they signed up through the Direct Payment API method without opening/logging into an account that this would need to be handled by your own system as they will not have an account to log in to edit this information and PayPal will not notify them. In that case you would need to log the expiration and offer them the opportunity to edit in using the UpdateRecurringPaymentsProfile API.

subscribing

Okay, I have some good news.

So basically, in the recurring fee settings, you need to disable triggered renewals. (/admin/store/settings/products/edit/features) Triggered renewals aren't valid with both paypal wpp and wps.

In addition, I've patched this file (it's a bit clunky, but it definitely works) so the new orders work correctly, and payments are applied to those new orders.

In terms of updating credit card information - it's probably needed, but since my client has now switched to WPS, I can't support this functionality, as everything is handled on PayPal's end.

Try the attached patch for recurring issues.

Hey @trevorwh,

I tried applying the patch to the latest dev, but got errors:

File to patch: uc_recurring_hosted.module
patching file uc_recurring_hosted.module
Hunk #1 succeeded at 22 with fuzz 1.
Hunk #2 FAILED at 590.
Hunk #3 FAILED at 606.
2 out of 3 hunks FAILED -- saving rejects to file uc_recurring_hosted.module.rej

I tried this with and without the patch from #70. I also tried to use your patch manually, and couldn't find any of the things the patch is referring to past the first change.

Do you think you can reroll this against the latest dev?

Thanks,
Andrey.

P.S. Not sure what you mean about the triggered renewals. I went to admin/store/settings/products/edit/features and didn't see any mention of them. I don't have WPS enabled, so I'm assuming they come from there.

Ah crap, I uploaded the wrong patch. Try this one after applying #70.

Sorry about that...

(Stripping trailing CRs from patch.)
patching file uc_recurring/modules/uc_recurring_hosted/uc_recurring_hosted.module
Hunk #1 succeeded at 22 with fuzz 1.
Hunk #2 succeeded at 79 (offset 1 line).
Hunk #4 FAILED at 590.
Hunk #5 FAILED at 609.
Hunk #6 succeeded at 542 with fuzz 1 (offset -185 lines).
2 out of 7 hunks FAILED -- saving rejects to file uc_recurring/modules/uc_recurring_hosted/uc_recurring_hosted.module.rej

This is the part that didn't work, the other stuff is just empty/commented lines:

+             if($payment_status == 'Completed' || $payment_status == 'Pending'){
+               //set a flag for when we call the renew handler
+               $fee->pp_payment_accepted = TRUE;
+             }else if($payment_status == 'Denied' || $payment_status == 'Failed' || $payment_status == 'Reversed'){
+               $fee->pp_payment_accepted = FALSE;
+             }
+             

Hmm, okay, apparently I need to re-roll this against the latest dev.

Will do that and re-release.

Any update on this?

Thanks,
A.

Wondering if anyone is working on this? Is there sponsorship for this project at all?

I'm helping @trevorwh troubleshoot this over email.

There is no sponsorship for this that I know of. If you want to throw some money at Trevor, he would probably appreciate it. My understanding is that his clients switched to WPS and nobody is funding this for him now.

I called PayPal Integration department to try to get them involved somehow, but haven't received any follow up yet.

That's kind of where it is at the moment.

Best,
Andrey.

Okay, it seems like we have renewed interest in this.

Let me see what I can do on writing a proper patch and fixing some of the outstanding issues. Any sponsorship is obviously appreciated, but I'll take another look for the sake of the community and getting a proper patch out so others can use this functionality.

This still needs a bit of work, but the patch has been re-rolled against the latest dev version.

It patches two files, both the uc_recurring_hosted and the paypal IPN file. Please test it and see if it's working correctly - keep in mind I had to re-roll this from the old version which didn't separate out the paypal IPN functions.

Latest dev ubercart/uc_recurring + patch. Recurring order as follows: "When this product is purchased, add a fee for the same amount as the product selling price ($10) charged first after 1 days and every 1 days after that unlimited times."

When I click "submit" on the order review page, I get this error:

Your order cannot be completed, because we could not process your recurring payment. Please review your payment details and contact us to complete your order if the problem persists.

On the order page:

failed.
Error: 10004: Invalid argument
Address: An unknown error occurred.

Nothing on PayPal admin.

Andrey.

Andrey,

Error 10004 is a paypal internal error: https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=develo...

Try it again later today and see if you get the same result. That part of the code hasn't changed from the old patch I wrote.

Thanks.

Tried it yesterday again and today, same thing.

Andrey,

Has this file remained patched throughout the process? Just trying to think of things that could be wrong.

http://drupal.org/node/637168

Let me know. If it doesn't work I'll setup a paypal dev account and we can continue working through it. I'm not sure why it isn't working though, since the code hasn't changed.

Woops, that was it. Forgot to do the nvp patch.

02/18/2010
9:54:32 AM	-	Customer granted user role [-] Subscribed To Sweet Vinyasa.
02/18/2010
9:54:32 AM	3	Recurring Payment Setup
Recurring Success: 10.00
02/18/2010
9:54:32 AM	3	Recurring fee 8 added to order.
02/18/2010
9:54:37 AM	3	Authorize and capture immediately
Success: 10.00 USD
Address: Address and postal code matched
02/18/2010
9:54:40 AM	-	Order created through website.

I'll do some more testing and report back.

Thanks,
Andrey.

OK, here is some preliminary testing... skip to the bottom for the concise summary.

Environment: Ubercart Feb.15 dev + UC Recurring Feb.11 dev + nvp patch + patch #110

Recurring product TestFeb18: $10 + $10/day after 1 days
PayPal charges $10 product price and creates a schedule for $10/day.
Ubercart balance gets set to -$10 (incorrect)
Payments tab displays the following:

02/18/2010 09:54:303Credit card$10.00$0.00Recurring fee payment ID 8.
02/18/2010 09:54:373Credit card$10.00-$10.00PayPal transaction ID: 4FF107713D233853W

The recurring fee has been scheduled for 1 day ahead, and should not register as a charge just yet.

Recurring product TestFeb18a: $10 + $10/day after 0 days
PayPal charges $10 and creates schedule for $10/day, charging the first $10.
Ubercart balance gets set to -$10 (incorrect)
Payments tab displays this:

02/18/2010 11:27:053Credit card$10.00$0.00Recurring fee payment ID 9
02/18/2010 11:27:113Credit card$10.00-$10.00PayPal transaction ID: 7RX172024B8996142

While the recurring charge amount is correct, the overall balance should be compensated by the amount charged, as to remain at $0.

Non-recurring product TestFeb18b: $10
PayPal charges $10 as expected
Balance is $0, which is correct

Recurring product TestFeb18c: $0 + $10/day after 0 days
Error: 10525: This transaction cannot be processed. The amount to be charged is zero.

Combination order of a recurring product and a non-recurring product ($10 and $10 + $10/day after 1 days) TestFeb18d
PayPal schedule created correctly ($10/day after 1 days), and charged $20

Summary:

What works

• Saved address
• Charging single non-recurring fee
• Charging non-recurring fee AND recurring fee together
• Combination of two products: one regular and one recurring
• User cancellation of a recurring fee

What needs work

• Remembering user's credit card profile, so they don't have to enter it for every new order
• On admin interface, "charge card" has "(Last 4) 1234" in the input field. Upon trying to charge the amount, an error is given: "This transaction cannot be processed. Please enter a valid credit card number and type." My understanding is that the profile should be remembered and called with an option to change the card manually if necessary.
• If product price is $0 and recurring fee is $10, an error will be given about charge amount being zero. I'm not sure if there is a way to fix it, but it should be an option for free monthly trials.
• Balance of orders with recurring fees is not registered correctly.
• Even if the initial recurring charge is set to delay for 1day, under the order payments it's marked as if it was charged.
• User being able to change their credit card information (for expirations, etc)

I'll do more testing tomorrow when the automatic recurring orders will kick in.

Best,
Andrey.

One important bug that I overlooked is that in the order that failed because the charge amount was 0, the order status was set to "Payment received". It should stay as "Pending". This is especially problematic with role renewals based on order status.

TestFeb19a - two of the same recurring product ($10+$10/day after 1days)x2
PayPal collects $20, and sets up one (instead of two) schedule for $10/day
We probably should make it so people can't purchase more than one of the same recurring fee product.

TestFeb19b - two separate recurring products ($10+$10/day after 1 days)
PayPal correctly charges $20 and adds two separate schedules for $10/day
Ubercart, however, only adds one $10/day recurring fee (message shows up twice for the same recurring fee)

02/19/2010
7:43:20 AM3Recurring Payment Setup
Recurring Success: 10.00 02/19/2010
7:43:21 AM-Customer user role [-] Subscribed To Sweet Vinyasa renewed. 02/19/2010
7:43:21 AM-Customer granted user role [-] Subscribed To Stiff White Guy. 02/19/2010
7:43:21 AM3Recurring Payment Setup
Recurring Success: 10.00 02/19/2010
7:43:21 AM3Recurring fee 13 added to order. 02/19/2010
7:43:21 AM3Recurring fee 13 added to order. 02/19/2010
7:43:23 AM3Authorize and capture immediately
Success: 20.00 USD
Address: Address and postal code matched 02/19/2010
7:43:25 AM-Order created through website.

Are you sure PayPal WPP doesn't remember people's CC profiles (not numbers) so a merchant can charge them later? It seems like an obvious feature to have for orders that didn't go through the first time around, etc... And yes, we are currently using Auth.net CIM, and it does have that feature.

Best,
Andrey.

The first recurring fee just kicked in and created a "Renewal" with a status of "Pending" and balance of $10. It should really be balance of $0 and status set to "Complete". Otherwise role renewals will not work.

The next scheduled billing was set to the time of the original order plus a day, which is good.

PayPal didn't charge the recurring fee yet (I imagine they have their own queue kind of thing).

Questions:

• What happens in Ubercart when the card expires?
• What happens in Ubercart if the card gets canceled for some other reason before the entered expiration date?

Best,
Andrey.

Subscribing. (Thanks for posting your progress Andrey.)

Andrey -

I had spoken with Paypal support and was informed that we were generating new orders for each recurrence and sending the credit card number each time. Paypal was not handling the recurring payments.

This would seem to indicate that the uc_recurring logic is storing and sending CC # for each charge. It looks like the encrypted data is stored in uc_recurring_users.data

Can anyone confirm?

Thanks

Faisal

As to the TestFeb19B - the extra ubercarts hooks may have solved that problem - but created numerous other problems.

I can look into handling multiple recurring products.

I'll also look into issue #4 so we can get this committed to dev. Thanks everyone for the assistance in testing.

I believe I had the renewals working - Andrey, are you seeing a payment entered into the new order, or a note in the original it was processed correctly and a new order was created?

Thanks.

Actually, I did another order test and it's interesting what happens:

Initial order is created no problem, then the following recurring order actually fails:

02/24/2010
9:01:40 AM	-	Customer granted user role [-] Subscribed To Sweet Vinyasa.
02/24/2010
9:01:40 AM	3	Recurring Payment Setup
Recurring Success: 10.00
02/24/2010
9:01:40 AM	3	Recurring fee 14 added to order.
02/24/2010
9:01:42 AM	3	Authorize and capture immediately
Success: 10.00 USD
Address: Address and postal code matched
02/24/2010
9:01:56 AM	-	Order created through website.
02/27/2010
8:57:18 AM	1	Error: Recurring fee 14 for product failed.
02/27/2010
8:57:18 AM	1	New recurring fee failed on order 581.

Order 581 has no comments, status of "Pending" and balance of $10.

The logs just show "Failed to capture recurring fee of 10.000 for product on order 580."

PayPal has the schedule set up and is continuing to charge as it's supposed to.

Best,
Andrey.

Subscribing

@Univate - Testing your patch now. Thanks.

trevorwh, I'm actively building something where we're hoping to use this piece as well.
How is your patch testing going?

thank you,
adam

We've setup the fees, I just need to check with my employee who is working on this how the testing is going. I'll report back later today/tomorrow. Thanks.

All,

I have good news on several fronts. First off, I've tested univate's patch, and things seem to be looking good on that end.

Additionally, I have implemented the functionality to update a credit card with paypal wpp. I've tested it, and it's working, much in the same way that the update card functionality was working with the auth.net CIM integration.

I'm going to post a patch for this probably tomorrow.

I have been following this for a while now hoping that the recurring payments functionality for paypal wpp will be possible.
I have a site set up where I need this functionality and I am crossing my fingers and hoping for your success.
Does this mean that it works?

I've been watching this for a client. It tests nearly perfectly. When I make the purchase it shows a -$25 balance.

This is a purchase of a product kit containing 1 non-recurring $0 product and 1 recurring $25 product +$10.7 shipping so total initial charge was $35.7.

I'm obviously using wanting to do role grant product kits any ideas as to what this is/where I should look? Is it still necessary to disable triggered renewals or has that been written into the hook already?

Also anyone else testing will still need the patch from #637168: Allow overriding API credentials in nvp request unless you use ubercart-dev

This doesn't work correctly if you have more than one recurring item in your cart. (It submits both fees to paypal, but only creates a single fee for the first item.) This is because the wpp_process callback generates a rfid for the fee, and uc_recurring's uc_recurring_process_order assumes it doesn't.

To fix this, you'll have to move the creation of $fee inside the looping-over-each-product loop in uc_recurring_process_order. If I have time, I'll make a proper patch, but if not, I hope this helps someone.

I am experiencing what jder is seeing as well. I created a 'support' issue for this: #763150: Multiple Recurring Fee IDs Per Order Not Supported, but now I see maybe it belongs here. I worked around the problem by unsetting the rfid variable immediately after the fee object is cloned. [EDIT - I now see that my code changes don't work...the $return array returned by uc_recurring_process_order() appears to have unique rfid's, but not the fee objects themselves] I stopped short of creating a patch because I didn't know if my solution was near-sighted. I was curious to see if any of this behavior was by design / for some reason I wasn't seeing.

The callback must generate the RFID, because we need to save the profile information from paypal, IE the subscription id which we use to modify future payments. Whatever you do, you can't change the saving of that - that's why I saved the variable earlier in the process. I thought I'd provide some input as to why it was done that way

trevorwh,

Are you saying you "can't change the saving of" the rfid, the subscription_id (mapping to PayPal's PROFILEID) or both? Isn't only the subscription_id needed to modify future payments (through PayPal's API)?

thanks,

jared

Well - here's the thing. You need to have an RFID to save the subscription ID. I suppose one can come up with a work around, but the reason I saved the rfid first is so that we can insert the subscription id once we receive it from paypal. If there's a better way, feel free to submit a patch :)

If there is anyone available to help us make uc_recurring work with PayFlow Pro, please contact me via my contact form. We are trying to launch a site and need help getting this to work properly. Thank you.

Great work everyone on adding WPP to Recurring!

I wanted to double check on a couple of things to make sure I am understanding correctly:

1) Does this require the merchant to add the additional Recurring Billing add-on/subscription to the the WPP service in PayPal?

2) My understanding was that creating a new Order ID on a recurring payment was an optional feature? Is this not the case? I.e. if one does not want a new Order ID but simply needs to original Order ID to be updated (success, cancel, fail) ....

Thanks!

Please let me know what is the status on this. Please replay jder.

Please update the recurring payment for multiple recurring product