I get your pain ShopGentei.
In implementing carts for other customers in similar situations, the same point was brought up but in the end they decided they wanted to enable registrations for future usage ... like if they ever came up with another…
You DEFINITELY have a tester waving his hands wildly saying "pick me!" ... if that doesn't work I'll shake your hand with some extra bills stuffed in the exchange. I was just reviewing the QB Web Connector last night and was really hoping it is goin…
My vote would be for purchases on the 31st to always be billed on the last day of the month, meaning the 29th for leap years in February.
For those on the 30th or 29th, the 30th/29th except for the last day of February.
Any other day, just use…
I'm gonna strongly strongly disagree with permanently moving the order date forward. Some folks get paid on the last day of the month. They place an order for a recurring subscription item to correspond with the pay day. They're habitually running o…
Here's some rough pseudo-logic for figuring out the billing date:
if (original subscription day = 29) & (current year mod 4 = 0) & (current month = 2) then bill on Feb 29 for current cycle // handles Feb in leap year
elseif (original s…
If you store a pointer to the original subscription record then you should be fine so that's good (I think you do). I can't reiterrate enough though about how uncool it is at least for a products company selling monthly subscriptions to mess with EO…
I would cache rates weekly. In the event their API fails to return a valid result 2x use the cached rates.
How often do rates change? Until you can use your contract/discounted rates, I'd probably just update the rate tables whenever changes occu…
I tend to think re-evaluating coupons on each subscription is a good idea. It would be particularly cool if you were able to give a customer the ability to modify an existing subscription easily too, and to be able to add new coupons when upgrading,…
Hi Brett, basically duplicating your front page as a demo would be a fine tutorial. The CSS will likely need to be customized on a per-store basis anyway. It would be cool to show an order comment in the mini-cart too. For me, we'd like to use this …
You'll note that that key is not nearly long enough to be a UOE key by any stretch. 1Password is there for a reason! Yeah it's definitely just an obscure flag to show/hide some stuff and that can be quickly changed from time to time.
And if it w…
How are multiple payment methods handled; is it per category?
What does "true guest checkout" mean?
When do you anticipate active development to cease? I mean it's nice and all that we can test, but not being able to use it in production and r…
@rthrash: Payment methods are per store, but could be easily forced per category (or anything else) using the JSON and javascript on the checkout.
Glad this is easily forced. Can you elaborate on the recommended way to do this given the future…
By the way, I wasn't wanting heavy lifting either, just more of a discussion of good business practices in general. For example, what types of dunning process make the most sense for cancellation, how frequently contacts should be made, how to hand…
Hi @fc_adam,
If we were looking for something similar, but only allowing PO Payments if a custom field "enterprise" were passed in with the cart (shockingly, to indicate an Enterprise customer was checking out), what would that look like? Is there …
A secure endpoint would actually be ideal, and I don't think too hard to sort out, if that means you post back to use to ask if the customer is an Enterprise user or not. Happy to hop on Skype if need be for clarity or to answer any questions.
What…
