I have a unique use case where I need to build in 14 extra days on top of a Stripe subscription plan but bill the client immediately. So if the plan is a 6 month plan, we really want to give the user 6 months and 14 days.
I originally thought I could leverage Stripe's trial feature for this, but found that the trial feature causes the billing to happen after the 14 days have passed which is not what we want.
I then tried to create plans by number of days (which is not really ideal but was worth a shot) but soon found that you cannot create a plan by days with more than 365 days (a year's plan with our model being 365+14).
I'm now thinking about creating one 14 day temp plan, subscribing a user to that, charging them and then after the 14 days, switching the user's plan over to a real 6 (or 12) month plan. This just feels overly complicated with a lot of overhead for wanting to simply add in extra days. I haven't seen anything anywhere in the docs that addresses this.
I should mention that I intend to use Laravel Cashier with this project and that I will also need to offer multiple plans per subscription.
UPDATE:
I just discovered that you can alter the billing cycle after a subscription has been billed using a trial. Which would mean that I should be able to create a customer subscription with multiple plans for say 6 months and then immediately after, create a 14 day trial on that subscription. If I go this route, it looks like I would need to set prorate to false and this might do the trick.
I still need to know if this will achieve the desired effect as well as work with both cashier and multiple plans.
I'm not sure why this got down-voted as it is a valid question given the limitations of Cashier along with the unconventional use case.
For anyone who might have more custom needs when using Stripe & Laravel Cashier and comes across this question:
I've since had time to explore this and found that Laravel Cashier cannot handle editing the subscription after the fact. There is no update feature there. Only the basic abilities to change/cancel plans. This didn't work for my needs.
What I ended up doing was using Cashier for creating Invoices as well as creating the subscription. Immediately after I am able to use the Stripe API directly to edit that subscription. By adding a trial_end with a date set 14 days after this subscription's current_period_end I can force the billing date of the next invoice to where I need it to be.
So for example, when a user subscribes to a 1 year plan, my update code would look like the following:
$current = Carbon::now();
$BillCycleDate = $current->addDays(379)->timestamp;
$edit_subscription = \Stripe\Subscription::retrieve($subscription->stripe_id);
$edit_subscription->trial_end = $BillCycleDate;
$edit_subscription->prorate = false;
$edit_subscription->save();
Also, I'm not sure if its a bug in the Stripe API, but simply specifying a trial_end date 14 days out on a subscription update causes the invoice to be rebilled right after that trial end date - despite the plan's interval being a year.
Related
We have an issue with customers getting double charged.
Today we noticed that another batch of orders was charged twice in Authorize. We don't see any sign of a second charge in the notes on Magento but the customer did receive a shipment notification from Magento on the day she was charged again. This particular order came into the system on 11/14 and was processed and shipped on 11/18. This customer emailed us today that she was charged again on 12/14/22. No one on our team has opened that order since 11/18.
Does anyone have an idea on this issue? On 11/14 we changed the settings in Authorize that allowed us to have less strict rules for having a matching billing zip and street address so we could allow the order to go through and then check ourselves if we would allow the order to be processed. None of these orders were marked as fraud though.
Given the detail you provided that the identical charge occurred again on the same day of the following month, it seems most likely you may have accidentally turned on a recurring payment option, either as an option on a virtual product of some kind or in one of your specific payment payment processing settings in the Magento Admin Panel.
Depending upon which extensions you may have installed, two other strong possibilities to check would be:
A 3rd party payment processor has given your customer the option to select a recurring charge and they accidentally activated that option.
An extension allowing customers to manage/schedule reorders through the Customer Account Management section of the Magento storefront has been accidentally activated by the customer.
Either of these two options becomes far more likely if this is occurring on some but not all orders.
My problem:
Currently in my project it's required to keep a payment in an uncaptured state for more than 7 days which is the maximum for stripe.
What I came up with atm:
I see that it can be done by remembering customer's card (using stripe's api for this of course), creating an uncaptured payment, refunding it when the 7-day period comes to an end and creating it again until we choose to finally capture it.
I guess this 'hack' will be used only once per a payment as usually we have to hold the payment for about 10 days.
Questions:
Are there any pitfalls besides that a customer will see a second payment?
Any other ways to handle this?
Thanks in advance :)
So we ended up sticking to this method described in the question, but #korben's point is true, it's still hard to handle because even if a bank can release the funds fast, we still don't know when exactly does it happen as stripe can't inform us when the customer actually got his money back whether it's two minutes or two days.
It still works for us, because the payment is not that big and happens in person, so customers can choose whether they want to give a deposit in cash or use this method which seems more comfortable.
For context (because I was recently solving this problem and came across this thread), a number of websites recommend if you have a payment that wasn't captured within seven days, then cancel the order and create a new one. For example, Shopify recommends this and the authorization expiry date is displayed on the Orders page.
However, for all of the reasons #korben mentioned, it's best practise to avoid holding authorizations for over 7 days. Additional fees are also charged when collecting charges after the standard authorization period (depending on the issuing bank of a credit card).
I signed up for a 30 day Azure trial 3 days ago. I have 2 vms. Today, I have 2 messages popping up in my Management Portal.
Your Free Trial expires in 25 day(s). Click here to upgrade now.
Based on your usage history ($21.52/day), you might use your remaining credit in about 3 days.
25 days left $67 credit remaining
I feel like I cut the "speed-up countdown" wire on a time bomb in an 80's movie.
I'd like to fully evaluate Azure and I'm just getting started. Clearly I missed something along the way that is preventing me from getting the full trial period.
Microsoft Support just gives me Azure's sales phone number.
Does someone know what I need to do to get a trial extension and stop the countdown from going too fast.
Thanks!
There isn't a way to extend the trial period. If you have disable the spending limit, you account would operate without any problem, but yet, you would start incurring cost.
These are the ways you cut down costs
Reduce the size of isntance - say small ( A1 )
Recduce the instance count
At any point in time if you are not using your instance, you can stop the instance and you cost near ZERO cost during that time.
If you have MSDN Subscription or BizSpark Subscription would would get $150 everymonth as credits
I have noticed that costs can be quickly used if you keep dropping and creating the database for testing purposes on azure, best to use existing database
I apologize if this is in the correct StackExchange site. I couldn't find a place that seemed perfectly suited for this question. My question is as follows..
Being a Microsoft BizSpark member I have access to free Azure hosting. The hosting provided is 1,500 hours a month of small instances free (this equals out to 2 small instances running 24 hours a day for a full month). The details of the offer go on to state "You can run 2 Small instances full-time or other sizes at their equivalent ratios."
Does this mean I can run one Medium instance for 24 hours a day for a month, for free? If you look at the pricing, a Medium instance is exactly twice as much as a small.
Does anyone have any experience with this that can chime in? Many thanks in advance!
Yes, I know, I use BizSpark subscription and I have advised and follwoing couple of fellow ISV to use it. And yes, you are correct, the BizSpark gives you 1500 small instance hours, which is 1 full month of single Mednium sized instance. This is in terms of compute. But you know that if you run only one instance, you are not covered by the 99.95% SLA! The SLA only takes place when you have 2 or more instances per role!
There is a new trial offer available for windows Azure which gives you 25 hours of small computing instance time a month and other things like 1 GB SQL Azure and more. See link below: http://www.microsoft.com/windowsazure/offers/popup/popup.aspx?lang=en&locale=en-US&offer=MS-AZR-0001P
Now my question: Is there a way to prevent exceeding these limits? I only want to try and don't want to be billed.
I believe you don't need a credit card to use the 30 day pass - the one from here:
http://windowsazurepass.com/
as far as I know there is no automated way to have it turn it off before you get billed. You will need to just be very careful about monitoring your usage manually.
For Doobi's suggestion, I believe you need a promo code to get the free 30 day trial. There is a MSDN blog post with the code MPR001 here.