I would like my client to monthly subscribe to a product (30 days billing period), with a maximum of 3 years : so 3 * 12 = 36 reccurencies. So after 3 years, his subscription is automatically canceled.
I could find that feature in Paypal, but did not find that feature in the stripe.
regards
When creating a Subscription, if you calculate the exact time in the future that you want it to cancel then you can provide that timestamp via the cancel_at parameter here. However, if you use that approach and don't set cancel_at to the exact end of a billing period, then the final invoice will have a prorated amount.
You can also use Subscription Schedules to achieve this, which are objects that allow you to schedule changes that will be made to your Subscriptions in the future. You could use these to schedule a future phase to set cancel_at_period_end to true for your Subscription, causing it to automatically cancel at the end of that billing period. When creating the Subscription Schedule, you can use phases.iterations to easily set the duration of the phases to match your needs.
You can read more about Subscription Schedules here:
https://stripe.com/docs/billing/subscriptions/subscription-schedules
Related
I'm using separate charges and transfers with Stripe Connect accounts.
So, if I create a transfer of $1.00 to a Connect account, Stripe is going to charge my platform(me) $2.00/month + % fees + $0.25/payout for that active account according to their Connect pricing page
Question - Is there any way to charge the Connect account or pass that $2.00/month active fee onto the Connect account, so my platform doesn't have to pay it? ex. Direct charge, negative balance, invoice, debit custom account, etc. Or is there a way to see the total pending balance that will be sent out to the Connect bank account and "take back" some of it before it gets delivered?
Concern and/or Challenge - When I issue a transfer, I won't have any problems recouping funds (my 5% fees, Stripe's Connect fees 0.25%) from my customers Connect accounts. I won't go into the math explicitly, unless you ask, but I will remove all fees from the transfer before it's sent, then check via "TransferGroup" to look and see if any transfers have been made to the Connect account for that pay period (1/month) and if no transfers have been created yet, I will deduct on another $0.25/payout to be withheld. BUT now I have to do something similar to collect/recoup the Stripe $2.00/month flat rate per active account and this is where my problem arrises. My transfers might all be for $1.00 each! Ex. $1.00x100. So I can't simply deduct $2.00 from a $1.00 transfer to collect this fee.
My idea - The transfers for Stripe are coming from a tipping mechanism I've implemented between students and instructors on my site/app. The students can tip $1,2,3,4,...N tips. I can do a check to see if any tips have been sent for the month and if it's the first tip, force a minimum tip amount of $3.00, for each additional tip a student wants to send, it will only be $1.00. So the first student to send a tip gets forced into a min. $3.00 tip.
Another idea - Check each transfer amount to see if it's >= $3.00, if true, I can take all fees including the $2.00 account fee and still be in the Net positive to transfer, but if this transfer group doesn't receive any $3.00+ transfers in a month, I would then track the amount owed/not collected ($2.00) and try and collect it next month. This might work but seems like a sub par solution. Maybe there's a better way?
Another idea - Allow the Connect account to go into a negative balance , if I had to take $2.00 + $0.25 + %fees out of the first $1.00 transfer. I don't know if this is a good idea or how it would work exactly.
Another idea - I was looking to see if Stripe has a way to look at the total pending balance that will be transferred out to the bank account before the end of the pay period and somehow deduct the $2.00 from the total? I see there is a way to debit accounts, but there are lots of restrictions so I don't think it will work for my scenario (lots of international accounts).
Another idea - Debit custom accounts seems reasonable but it has too many restrictions ex. doesn't work for international accounts.
Another idea - I was looking at Direct Charges where it looks like I can charge a Connect account, but looking at this code, it only creates a "Request". How does it get me the money? Is it automatically sent from the Connect account to me(platform)? What happens if I only transfer $1.00 to a Connect account for a payout, but then send a "Request" for $2.00, does the Connect account go into some negative balance?
var service = new PaymentIntentService();
var createOptions = new PaymentIntentCreateOptions
{
PaymentMethodTypes = new List<string>
{
"card",
},
Amount = 2000,
Currency = "usd",
};
var requestOptions = new RequestOptions();
requestOptions.StripeAccount = "{{CONNECTED_STRIPE_ACCOUNT_ID}}";
service.Create(createOptions, requestOptions);
Stripe only charges the $2.00 fee on active Connect accounts - i.e. ones that you either transfer money to or customers do direct charges to. As such, there is always a monetary transaction before the Stripe Connect charges are accumulated.
In your case (and mine, actually) you are using separate charges and transfers - so withhold an amount equal to the $2.00 charge the first time you transfer to an account each month (a little bit of database/bookkeeping), as well as a "guess" at the payout charges as well (a "guess" because you know when you transferred money, but don't necessarily know how they will be combined into payouts).
2022-01-20
Pseudo-code:
//if using multiple charges to a single vendor
=> collect charges filtered by transfer_group, summing available, pending, fees, then net as AVAILABLE
=> collect existing transfers by transfer_group, summing amounts as ALREADY_TRANSFERED, and gathering transfer Id's
=> we'll use AVAILABLE_TO_TRANSFER = AVAILABLE - ALREADY_TRANSFERED
=> check Connect Account receipt records (your database) for previous transfers in this calendar month (I did mention bookkeeping)
=> if there are no other receipts, then what we'll set BASE = CONNECTED_ACTIVE (currently $2)
=> the amount we will transfer is the AVAILABLE_TO_TRANSFER less reserved fees
=> We know the potential Payout fees will be based on the amount actually transferred (might be less if transfers are collected into a single payout - remember I said pessimistic)
=> The Payout Fee (which we will save as RESERVE) will be based on the actual transfer, FEE = BASE + PER_PAYOUT + PAYOUT_RATE*PAYOUT, with the pessimistic assumption PAYOUT = TRANSFER. PER_PAYOUT is currently $0.25 and PAYOUT_RATE is currently 0.25%.
PLEASE PLEASE PLEASE put the actual values in a database somewhere and use variables to pass into the formula - that way you can easily maintain your code.
=> So now we know AVAILABLE_TO_TRANSFER, and we know that TRANSFER = AVAILABLE_TO_TRANSFER - RESERVE, and we know that RESERVE = BASE + PER_PAYOUT + PAYOUT_RATE*TRANSFER
=> a half-page of algebra, and we can get
RESERVE = (AVAILABLE_TO_TRANSFER*PAYOUT_RATE + (BASE + PER_PAYOUT))/(1 + PAYOUT_RATE)
and
TRANSFER = AVAILABLE_TO_TRANSFER - RESERVE
As mentioned, you do need to keep receipts in your database to know if the Active Connected Account fee needs to be collected. Keep the reserves in your platform account until the monthly Connected Account & Payout fees are charged, reconcile the # of actual payouts against the pessimistic guesses above, and you can the withdraw (payout) any excess from your platform account.
2022-01-20a
you can be even more pessimistic (by a small amount) and just use
RESERVE = BASE + PER_PAYOUT + PAYOUT_RATE*AVAILABLE_TO_TRANSFER
You'll just reserve a tiny amount more than you have to - which we are kinda already doing anyway...
BIG NOTE
This is NOT official advice from Stripe - I do not work for them. This is my approach.
You can specify an application_fee_amount to collect a fee for a Direct Charge.
With Direct Charge, the connected account will pay the Stripe fee, and you as the platform will get the application fee that you specified in the Payment Intent creation.
Here's the use case I am trying to solve for:
Create a new monthly subscription of $1000 that starts on May 20 with the CancelAt field set to June 29.
Expected behavior:
Stripe charges Customer $1000 on May 20
Stripe charges Customer $1000 on June 20
Stripe automatically cancels the subscription on June 29 with no further invoices
Total amount charged: $2000
What I tried:
Create a Susbcription with CancelAt of June 20 and ProrateBehavior=None
Actual Stripe behaviour:
Stripe charged Customer $1000 on May 20 (correct)
I see in the Stripe dashboard an upcoming invoice of $317.97 for period June 21 - June 29 (incorrect)
I see in the Stripe dashboard that Subscription is set to cancel on June 29 (correct)
Total amount that will be charged: $1317.97 (incorrect)
I can't seem to figure out what combination of fields would make stripe behave as I described. Isn't setting the Prorate behavior to None supposed to tell Stripe to never charge less than full amount? Seems like a common use case unless I am missing something?
Thanks for the help!
Stripe Subscriptions are prepaid, so your May 20 invoice actually covers from May 20 to June 20, so this actually makes sense.
cancel_at specifically says:
A timestamp at which the subscription should cancel. If set to a date
before the current period ends, this will cause a proration if
prorations have been enabled using proration_behavior. If set during a
future period, this will always cause a proration for that period. (emphasis mine)
You either want to just cancel the Subscription in June via the API with proration_behavior:none - potentially using metadata to record the 'when to cancel date' and webhooks to check if the subscription needs cancelling this period - or possibly use Subscription Schedules: https://stripe.com/docs/billing/subscriptions/subscription-schedules
I am a G Suite Reseller and I need to create a website where my clients can enter the number of g suite users/licenses they want to add and it will calculate the price for them based on the number of licenses and the remaining period.
I have already searched the reseller API page but didn't find any useful resources.
I don't think you need the re-seller API for that, you can check the G Suite licenses price at gsuite.google.com you can just create your own page and calculate it based on those prices,the re-seller API works just to manage the subscription of your clients but nothing related to billing all the reference about the reseller API can be found here https://developers.google.com/admin-sdk/reseller/v1/reference/.
Now if you want to retrieve the expiration date for the plan then you can use the Rseller API,Reseller API > Subscriptions you will find the JSON with the plan start and end time, I would say you can use them to .
"plan": {
"planName": string,
"isCommitmentPlan": boolean,
"commitmentInterval": {
"startTime": long,
"endTime": long
}
I don't have a reseller account but I would say that the best option is to use the Subscriptions > Get to retreive the start and endtime from the plan. The methods I found are
Plan 'startTime plan.commitmentInterval.startTime', an annual commitment plan's interval's startTime in milliseconds using UNIX Epoch format
Plan 'endtTime plan.commitmentInterval.endTime', an annual commitment plan's interval's endTime in milliseconds using the UNIX Epoch format.(for more information about the UNIX Epoch format check the subscription overview property names)
What I am not sure since I dont have how to test is if these two are linked to an annual plan or can be used to any other plan. I hope this information can be of help, greetings.
At the moment most of the data retained for 90 days by default. I was wondering if there way to change this setting to 30-40 days. I know that I can export them to keep the data longer but what I'm looking for is mainly keep the data for shorter duration for the upcoming regulations.
Update
The default retention for Application Insights resources is 90 days. Different retention periods can be selected for each Application Insights resource. The full set of available retention periods is 30, 60, 90, 120, 180, 270, 365, 550 or 730 days.
Note: If you need to keep data longer than 730 days, you can use Continuous Export to copy it to a storage account during data ingestion.
To change the retention, from your Application Insights resource, go to the Usage and Estimated Costs page and select the Data Retention option:
Reference
Sometimes the only answer is a no. In this case, you can't. From the docs:
Raw data points (that is, items that you can query in Analytics and inspect in Search) are kept for up to 90 days. If you need to keep data longer than that, you can use continuous export to copy it to a storage account.
Aggregated data (that is, counts, averages and other statistical data that you see in Metric Explorer) are retained at a grain of 1 minute for 90 days.
I remember that a long time ago the pricing tier dictated the maximum retention period but it is now fixed to 90 days for all plans.
You can try give your feedback / ask for this feature here.
It is now available as an option in the Azure portal. If not, you need to get in touch with Azure support to get it activated.
We need to rebill x amount of customers on any given day.
Currently, we run a cron every 5 mins to bill 20 people/send invoice etc
However, when the number of customers grows, extending to 100 people per 5 min may result in the cron overlapping and billing customers twice.
I have two thoughts:
Running the cron once, but making it sleep x amount after 20 billed/invoiced so that we dont spam the API.
Using a message queue where people are added to the queue and then "workers" process the queue. The problem is I have no experience in this, so not sure what is the best route to take.
Does anyone have any experience in this?