Recurring order

[Will]

We want to be able to offer open-ended recurring orders that our customers can cancel at any time.

Ideal situation:

- Customer chooses "ship me 1 per week" option on the product page
- Customer checks out and pays
- Three weeks later, customer decides to cancel, goes to their account, under "My Subscriptions" and clicks "cancel order"

Can we have a recurring order be open-ended by leaving the "Total Payments" field blank?

I don't see any UI elements allowing a customer to cancel a recurring order. Is this the case? If so, how do you envision a customer canceling a subscription?

Thanks.

[Shopping Cart Admin]

Hello Will,

For security and scalablility reasons we elected to leverage the payment processors recurring billing systems, rather than leave the CC numbers in the hands of mostly novice users and hosts.

All of the top payment processors offer recurring billing and while it was more work to build in support for the various processors, it's so much more secure and scalable than an internal system.

That said. Set the term to 1000 payments, in what ever frequenty you desire. The payment processors send out receipts that include links to cancel at any time and reminders just before billing that there card is going to be charged. If they cancel you will be notified by the processor.

[Will]

When our processor notifies us, what happens on the storefront? Do we need to go in and cancel the order on the backend?

We've got the ability to cancel a recurring order in the backend order management tool. How does that work with the payment processor?

Also, most of our wholesale customers pay by PO or check -- we just need some way for them to be able to go into their account and hit "cancel". Otherwise, they have to call or email.

I definitely don't want to be storing cc numbers either. I do want to provide our customer with feedback that their order was canceled.

Our current storefront doesn't store cc numbers but does allow users to cancel through our store's "your account" interface. For each recurring order that's due, it shows up on our recurring orders due for the day, we then process that individual order w/ the processor.

[Will]

I dug into our existing app a little more. There's an " Import Recurring Order Status From Gateway" section that lets us pull the relevant info from our gateway.

Will we see similar functionality in v7?

Recurring orders are key for us.

[Shopping Cart Admin]

Hello Will,

I'll have to check with the dev team to get more information on this, before I can answer.

[Will]

Thanks. I think this is the final question we need to answer for us to be able to switch over.

[Will]

I think I see where my disconnect is here. We need to create recurring orders, not subscriptions.

It looks like v7 can do subscriptions -- a product with fixed options shipped at a set time each week or month to a list of people who have purchased that subscription. Although, I suppose a recurring order is just a subscription customized for one person.

We need to create recurring orders of a product with options and recurring period chosen by an individual customer. We want them to be able to say: "Ship me a 1-pound bag of French Roast coffee, fine grind, every week, and bill me weekly until I tell you to stop".

I see the flow as something like:

- customer selects an item with a weekly or monthly delivery option (Your sales rep had me set this up in a kit form, where the weekly and monthly subscriptions were parts in a kit -- the UI looks perfect)
- customer submits order through storefront
- storefront passes recurring billing task to processsor
- the processor's recurring billing service lets the storefront know when the next payment has been processed -- we could do a daily manual import, but it would be great if it was automated
- storefront creates a new order corresponding to the new payment
- order appears in the storefront's list of orders to be processed and shipped

Right now it's the fulfillment part I don't see. I can see how the recurring billing would be initiated, but how do our fulfillment folks know when a payment has cleared and they need to send out another shipment -- what to send, and who to send it to?

If the recurring nature is driven by the payment processor, there's no way for us to create recurring orders for wholesale customers who use purchase orders or checks, correct?

Sorry this got so long...

[Shopping Cart Admin]

Hello Will,

Subscriptions and recurring billing are one in the same. I want our recurring billing system to be the strongest out there, so unless your in a terrible big hurry to go live. After we go final on October 31, we'll sit down and put together the mother of all recurring systems and code it for inclusion into 7.1. Which will get to you early for feedback.

One other feature that Neal had suggested, would be helpful and thats the ability to enter a quantity for kitted products.

[Will]

Unfortunately, we are in something of a hurry. End of November.

All I need to know for the v7.0 version releasing Oct 31 is once the customer has initiated the recurring charge with the payment processor, how to we know when to ship them their next installment? How do we get it into the order queue?

As long as I can give my fulfillment folks an interim solution, we're good.

[Shopping Cart Admin]

Hello Will,

We'd make that timeline. What payment processor are you currently using?

[Will]

Right now we're planning on Authorize.net for processing, based on compatibility.

Our payment logistics reseller was recommending eProcessing Network as a gateway, saying they have an Auth.net emulation mode, but I've become wary of these kind of things. Don't know if you have experience with them.

[Will]

Hi Mike,
Any update on this? Is there an interim solution I can use so my fulfillment people can know when to ship out recurring subscriptions?

Thanks.

[Shopping Cart Admin]

Hello Will,

The developer who works on gateways is off til the 17th. So I don't have an update. We'll get a solution together before your go live date. No worries. If you could email me your thoughts on a workable solution, it would be helpful.

[sswilli99]

Hi I was wondering if anything ever came of this? we are currently using your system but sales are gettng to the point that the recurring order feature will force us to switch as your DOES NOT function as Advertised. Are you ever planning to implement this?

Thanks,

Shawn

Hello Will,

Subscriptions and recurring billing are one in the same. I want our recurring billing system to be the strongest out there, so unless your in a terrible big hurry to go live. After we go final on October 31, we'll sit down and put together the mother of all recurring systems and code it for inclusion into 7.1. Which will get to you early for feedback.

One other feature that Neal had suggested, would be helpful and thats the ability to enter a quantity for kitted products.

[praiseintl]

Mike,
has any progress happened with this

I think I see where my disconnect is here. We need to create recurring orders, not subscriptions.

It looks like v7 can do subscriptions -- a product with fixed options shipped at a set time each week or month to a list of people who have purchased that subscription. Although, I suppose a recurring order is just a subscription customized for one person.

We need to create recurring orders of a product with options and recurring period chosen by an individual customer. We want them to be able to say: "Ship me a 1-pound bag of French Roast coffee, fine grind, every week, and bill me weekly until I tell you to stop".

I see the flow as something like:

- customer selects an item with a weekly or monthly delivery option (Your sales rep had me set this up in a kit form, where the weekly and monthly subscriptions were parts in a kit -- the UI looks perfect)
- customer submits order through storefront
- storefront passes recurring billing task to processsor
- the processor's recurring billing service lets the storefront know when the next payment has been processed -- we could do a daily manual import, but it would be great if it was automated
- storefront creates a new order corresponding to the new payment
- order appears in the storefront's list of orders to be processed and shipped

Right now it's the fulfillment part I don't see. I can see how the recurring billing would be initiated, but how do our fulfillment folks know when a payment has cleared and they need to send out another shipment -- what to send, and who to send it to?

If the recurring nature is driven by the payment processor, there's no way for us to create recurring orders for wholesale customers who use purchase orders or checks, correct?

Sorry this got so long...