Subscription Object: updateImmediately() only allows account credit

[merauluka]

With the change from transactional to invoice-based refunds, I've been trying to refactor our client's code to allow them to function as they did before. They were allowing prorated, immediate refunds when a client changed their plan in such a way as to require a credit.

After the change all refunds are automatically applied as account credits instead.

I have successfully applied a line item credit for a previous invoice in hopes that Recurly would be smart enough to figure out what to do next. The credit is processed but only up to the amount of the invoice, not the amount of the line item. And if I update the subscription quantity and then run updateImmediately(), Recurly processes the refund again and still makes it an account credit.

How, without rebuilding the functionality of the updateImmediately() function, can I get them back to the way it was?

[drewish]

Hey I've got nothing off the top of my head I'll try to dig into this tomorrow morning.

[drewish]

What does your code for issuing a refund look like? Are you passing "transaction" to the $refund_apply_order parameter? That option was just added in the last release in #161. It doesn't look like the relevant docs have been updated so if you want to paste your code in I'm happy to help you get it updated.

[merauluka]

We're doing some basic checks as to whether or not the transaction is being refunded now or at the next renewal. Then we're taking the subscription object, updating the quantity, and processing updateImmediately on the subscription object.

Are you saying that it's possible to pass a a parameter into updateImmediately? Because that would solve a lot of my problems.

[merauluka]

I did read through the documentation (many times) and I saw the refund_apply_order setting. Hoping this would give me the tools I needed, I updated my Recurly PHP library to 2.4.4. But I see that's only for direct refunds on line items. I tried a few iterations but wasn't able to get the functionality I needed.

For reference, here is a screen shot of our form and then the code that is fired after it is run.

function custom_module_subscription_edit_form_submit(&$form, &$form_state) {
  $quantity = $form_state['values']['quantity'] + 1;
  $renewal = $form_state['values']['renew'];
  // This is the Recurly subscription object.
  $subscription = $form_state['values']['subscription'];
  // Reset the quantity on the subscription to the one requested by the form.
  $subscription->quantity = $quantity;
  if ($renewal == 'now') {
    $subscription->updateImmediately();
  }
  else {
    $subscription->updateAtRenewal();
  }
  global $user;
  $form_state['redirect'] = 'user/' . $user->uid . '/subscription';
}

[drewish]

Sorry it sounds like I might be misunderstanding what you're trying to do. Can we step back for a second lay out how things were working with transaction based refunds. Were you manually computing the proration doing partial refunds?

[merauluka]

The manual calculation is what I was attempting to do as a workaround. It is not the ideal solution for us.

Our previous workflow:

1. User requests a plan change via our custom form (see screenshot from my previous comment).
2. Our custom form runs its submit handler (see code snippet from my previous comment).
3. If the user has chosen to apply the change immediately:
   • Run the provided updateImmediately() function and allow Recurly to handle the plan update and credit or charge as necessary.
   • If a refund was necessary, Recurly would automatically refund the credit card on the user's account for the necessary amount.

Workflow after the invoice-based refunds change:

Everything works the same except when a refund is necessary, Recurly now applies the funds as an account credit instead of refunding the money back to the user's card on file. This is what we're trying to fix.

What would be absolutely amazing is if we could choose the refund method in the function call:

$subscription->updateImmediately('transaction');

[drewish]

I asked around and the only way we send money back to a user's card is:

• refunding a transaction (deprecated method)
• refunding a line item

So I'm not quite sure how the previous workflow you described would have worked. Could you send an email to support@recurly.com (or use https://support.recurly.com/) with the link to this issue and the subdomain of the Recurly site you're working on. If you've got a specific invoice or subscription where the old flow worked that'd be really helpful in figuring out what was happening.