Manual transaction authorization

[merauluka]

We have a custom integration with Recurly we've built. I'm currently troubleshooting some behavior where a user attempts to upgrade their plan from one to another. The upgrade options are handled in our custom code. However we are running into an issue where if the user's payment method has become invalid where it will be declined, then the user will be left without a plan. This is because when switching plans, Recurly will first cancel their current plan and then attempt to activate their new plan.

While this logic is sound, if a payment authorization was first attempted before the current plan is cancelled, then the issue with the payment method would be discovered and we could return a message to the user to let them know what to do.

As of now, I haven't been able to find a way to perform a transaction of type "verify" using the API. All I can do is a one-time charge and then an immediate refund. Not that this wouldn't work, but it would be nice to be able to perform this in a more standard way.

Am I missing something? Is there a way to do a test transaction before making any plan changes?

[drewish]

For the subscription change how are you handling those changes? Are you using the subscription change method? Or are you manually terminating and creating the subscription?

[drewish]

Oh also are you using the "Require Successful Transaction On Upgrades" or "Require Paid Invoice to Downgrade" options on the Invoice Settings page (/configuration/invoice_settings/edit)? You can read more about them at https://docs.recurly.com/docs/invoice-settings#section-modification-enforcement but they might help achieve your goal.

[merauluka]

Thanks for the direction on the account invoice settings. That helped with the auto upgrade process.

For our custom upgrade process, it would still be helpful if there were a way to set which kind of transaction we were creating. Something like:

$transaction->action = 'verification';

Would be amazing.

[drewish]

I'm not sure I totally understand the difference between the "auto upgrade process" and your "custom upgrade process". I guess the former is creating a subscription change for renewal but the later is your method of creating a new subscription?

It sounds like you might be working against our system in this case. To minimize transaction fees we only trigger a verification transaction when first saving billing info. The exception to this is when creating a subscription and new account at the same time we use the purchase transaction to verify the billing info.

I'd encourage you to switch over to the subscription change method. Using that and requiring successful transaction for upgrades should keep your customers on a plan while they go through the email dunning cycle. They'll be able to update their billing info and continue with the updated subscription.

[aaron-junot]

Closing this issue due to inactivity. Please feel free to comment or reopen if the suggestion of using the subscription change method was unsuitable