-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Subscription Object: updateImmediately() only allows account credit #169
Comments
Hey I've got nothing off the top of my head I'll try to dig into this tomorrow morning. |
What does your code for issuing a refund look like? Are you passing |
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. |
I did read through the documentation (many times) and I saw the 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';
} |
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? |
The manual calculation is what I was attempting to do as a workaround. It is not the ideal solution for us. Our previous workflow:
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:
|
I asked around and the only way we send money back to a user's card is:
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. |
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?
The text was updated successfully, but these errors were encountered: