So I am using stripe to allow my customers to do recurring billing (on-demand cleaners), the problem I have that at the moment there are 30+ plans a user could be assigned to depending on their inputs. For example:
User 1:
Cleaning interval = every 4 weeks
House size - 4 bed
plan = A
User 2
Cleaning interval = every 6 weeks
House size - 2 bed
plan = B
The above example has loads of permutations, so obviously as we get bigger and we move countries the permutations become greater.
Now my solution to scalability was to create a plan per user (would this scale to 100k plans in stripe)?
The second solution was to do token based payments and setup a cron or something similar to process it (how easy would it be)
I am using PHP, so any solution would more than likely be done in this
I would love some feedback or even case studies on how to solve this
Oliver
Stripe does not restrict the number of plans you can create, so you could potentially have tens of thousands of different plans.
However, that doesn't seem like a very good solution. What you could do instead is use the "metered billing" payment flow:
Create a plan for $0 / month (or whatever interval you want to use)
Create subscriptions to bind customers to this plan
At the end of each billing period, a new invoice will be automatically created and an invoice.created event will be sent. Using webhooks, you could catch this event on your server and create invoice items for the actual amount you want to bill.
Approximately one hour later, the invoice will be closed and payment will be attempted. Depending on the result, either an invoice.payment_succeeded or invoice.payment_failed event will be sent.
If the payment fails, it will be retried according to your subscription settings.
Since it seems you have different billing intervals, you might need to create a few different plans (all for $0, but with different intervals), but the general idea still applies.
Related
Here is an example of what is going on and what I need to do.
Lawyer pays for legal services monthly website for $39. A second product of the website is to monitor legal cases (like a divorce so the lawyer knows what is filed). Each monitored case is $4.99 but the first 5 cases are free as part of the $39 subscription. The lawyer can use the $4.99 as a client expense with a receipt specific to that client. Creating a separate subscription specific to each client name is easy and does the proration when started in the middle of the billing cycle. But when I start a subscription for the first 5 cases, that's an additional $24.95 (4.99 x 5). The total should still be $39, not $39 plus $24.95.
I tried coupons, but that didn't prorate the base $39 for the time left. Is there a way to apply the coupon back to the beginning of the month?
My other thought was to adjust the price of the underlying subscription for $39.00 and make the new one $34.01, then take off another $4.99 when 2 cases are monitored and finally on the 6th case, that's beyond the amount included so the 6th case would be charged $4.99 and so on for any additional cases.
What would be the best way to structure this pricing model in Stripe?
So I was wondering if this is possible on stripe starting a trial period for two months after a paid month for $xx and when the trial ends It will unsubscribe them automatically to the plan.
I don't know if this is the method I'm looking for, I'm open for suggestions like after the first invoice of the subscription I will add Discount Coupon for 100% for the next 2 month then unsubscribe right after the third invoice.created.
It would probably be simpler to set the recurrence to 3 months. Then you could add a webhook subscriber to invoice.created events, which occur about an hour before payment is taken, and cancel the subscription when an event (with maybe some logic if this only applies to certain plans) is received. Your logic is significantly reduced in this way.
As you mentioned, you could apply a 100% discount, with a repeating duration with max_redemptions set to 2. I have a feeling that this will be more complex to manage - though possible.
I'm not sure about retrospectively adding trial to an existing subscription - I think it's only available on creation.
I am new to PHP. I am creating a system which shows customers, subscription package, and balance amount.
I have created user CRUD system and Packages CRUD System. What I want to have is to increase balance amount every 30 days, basically like recurring subscription. What I need is basic guideline.
This works like this -
Created a customer
Assigned him a Package
Balance amount increases every 30 days
(I'm Stuck on 3rd Point)
Well, the basic approach would be to:
Do NOT keep track of a "balance", but register the "end date" of the subscription. You can both keep track of the last month paid as the end date of the contract. Actually you can register more dates and make this as complicated as you want.
The "basic guideline" is that in the database you store dates and not balances. This allows you to only make changes as part of a transaction (like paying changing/adding a contract).
Hope this different approach helps you.
So I am dealing with Authorize.net's ARB, and I have a situation where the user is applying for usage of our service for eg. 3 months. We charge the user for this period - 3 months, but we don't make a subscription immediately. The thing is, we don't want to automatically charge them again once the membership expires after 3 months, but only if they go to account settings and set that option (extend membership automatically). So if they don't select it, there is no need to establish a subscription, so that's why we aren't doing it in starting point, once the user applies for this service.
So the question is, should I create a new subscription once user selects "Yes" for that option, and delete the subscription when he selects "No" ?
Is there another way to do it?
It's really hard to find some answers by Google, and I was hoping someone with more experience will have an answer here.
Thanks in advance.
When the user selects "Yes" for the new subscription just create a new ARB subscription with a start date of three months past their three month trial period. The three month subscription will run its normal course and terminate after three months. Then the new subscription will start at that point.
But here's the catch with that solution: you need the customer's credit card information in order to recreate another subscription. Unless you store it somewhere (bad idea) you can do that. So you would need to ask for it again. That's a large hurdle to overcome and will negatively affect conversion rates.
Alternatively you can automatically create the three month subscription at the point where the user starts their three month trial. As they approach the end of the three month trial you should make them aware there subscription will automatically start unless they cancel it. This solves the creation of the subscription problem but isn't very popular with users as nobody likes being automatically enrolled in a subscription.
Third option is to use Authorize.Net's CIM API to create a payment account for that user. Then you can charge against their card whenever you want. The problem with that is CIM does not support subscriptions. So you'd have to write your own subscription engine to make this work.
So there is no ideal solution for this. You just need to pick the one that you think works best for you.
I have been looking at setting up web applications that rely heavily on the ability for users to frequently and substantially modify subscriptions. I may be using marketplace features as well, and I need a system that supports both seamlessly.
I have seen multiple horror stories about the complexity of modifying subscriptions, including double billing, or cutting users off at the wrong time.
I sincerely hope, for instance, that this article http://talklikeaduck.denhaven2.com/2007/09/02/how-to-cure-the-paypal-subscription-blues
is out of date. The use cases that I have in mind are even more complex than the ones that he mentioned. For a sampling of what I would like to do:
Support multiple subscriptions and
subscription types/levels. For
instance one user might have 1 Plan A
billed monthly at $10 and 10 plan C
billed at $50 per month and 1 Plan D
billed at $100 per year.
Support changing of arbitrary payment amounts. For instance, user was on the $40 per month plan, but then changes that to a $100 per month plan. Then cancels, then signs up again at $50 per month before the $100 period was up. The user should still get $100 of service for the month that he paid $100 for, and then should change to the $40 per month plan.
Allow for payments of subscription amounts between my users. So one user might initiate a payment of 50% of whatever amount he has paid into the system so far. My application will be handling these types of marketplace style operations and these payments should work in the context of subscriptions...
It does not appear that there is an Open Source PHP library that does what I need either with Amazon or Paypal. So I am looking forward to coding this myself. (be glad to be proved wrong here, perhaps a Freemium for PHP?). I cannot use the various subscription services that are available. Because they generally do not support the features above, and because I need to have direct access to the PayPal or Amazon FPS API for later cleverness via marketplace issues.
Which brings me to my question. Which payment platform should I choose for ease of managing subscriptions? Please send me in the right direction, I only have so much time. But I also do not have time to make the wrong decision. Please provide evidence for your preferences, and if possible detail your work comparing the two systems. Google has the only other payment platform and currently their subscription system is in beta.. If you propose some other better system, please provider tons of good reasons, because I need a popular payment engine that people will feel comfortable with!
-FT
I see you asked this question back in December... if you haven't found an answer yet, I have some suggestions based on my experience with a business problem almost identical to yours.
Which PayPal API are you thinking of using? In using the PayFlow XML API, I found it was thousands of times easier to just roll my own subscription service. If the API you're using supports creating 'reference transactions' based on the previous successful transaction ID, you may save yourself a headache by keeping track of users' subscription amounts, keeping track of what's been paid, and creating a billing script that runs on a daily cronjob, checking each user to see if they need to pay (and how much), and then creating a reference sale for each of them.
Of course, don't forget that you have to explicitly ask for users' permission before you start billing them on a recurring basis, and there should be a good recurring billing and privacy policy. One trouble with this setup is that you pretty much need to create your own scripts to manage people's subscriptions and payments -- fortunately, I was tacking PayPal recurring billing onto a web app that already had subscriptions and accounting built-in.
Let me know if you need any suggestions on how to go about this!