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?
Related
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.
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.
Requirement:
We want to have a base subscription which is X/month, done via recurring payments, and give clients the ability to choose extra "add-ons" as they please. An "add-on" will be Y/Month and should last the remainder of the base subscription. For example, the base subscription is 10/month and feature X is extra 5/month and feature Y is an extra 7/month. I choose to have the base subscription with feature X and Y so my total monthly payment for a year will be 22/month. Now, if I chose only the base subscription for the first 6 months and want to start using feature X for the final 6 months of my subscription, the final 6 months should be 15/month opposed to the previous 10/month. In further terms, add-on features subscription should last the duration of the base subscription.
Is there a simple way to do this via the PayPal API?
Actual recurring payments profiles (setup with Standard or Express Checkout) have a limit on how much you can raise the amount of a profile. You can only raise it by 20% every 180 days. If you create a recurring payments profile with Payments Pro, though, then there is no such limit and you can change the amount at any time to whatever you need. I wouldn't recommend going without EC, though, as lots of people prefer to pay with PayPal.
What you could do, though, instead of using the recurring payments APIs would be to use billing agreements / reference transactions. This way you'd save the billing agreement / auth ID in your database and then you can use the DoReferenceTransaction API to process any variable amount you need to at any time.
So in that case you would basically be building your own recurring payments system where you'll save the "next payment date" in your database, and then you'll have an automated script run each day to process all of the payments that are due that day via a reference transaction.
Reference transactions work with Payments Pro, too, so if you're using that everything would still work the same.
Since you're working with PHP I'd recommend taking a look at my class library for PayPal. It will make all of these API calls very simple for you.
I'm trying to change the order grand total programmatically for purpose of allowing users to pay portion of the payment. I tried editing core file Mage_Payment_Model_Info method getMethodInstance
if (method_exists($instance,"getOrder")){
$order = $instance->getOrder();
}else{
$session = Mage::getSingleton('checkout/session');
$order = Mage::getModel('sales/order');
$order->loadByIncrementId($session->getLastRealOrderId());
}
$total=$order->getGrandTotal()/2;
$order->setGrandTotal($total);
I know this is not the best way, but was experimenting to find the best way . How to achieve this? I plan to put the changed in a custom module. so not going to keep changes in core files. thanks
I had to do something similar recently and there were some big problems, but first the good news.
The amount charged is based on invoices, invoice for the portion and the order's paid amount will increase appropriately.
An order may have many invoices.
You don't need to alter the grand total. Leave that intact as a record of what they need to pay.
However,
The order items each need to be marked as invoiced. When an order is half paid then you must work out which items are accounted for intelligently. If an order has one $10 item and one $100 item which are paid by the first $20?
An order cannot be overpaid. Thanks to a false assumption the difference between amount owed and amount paid (the "due") will not show negative numbers, this is a fallacy and makes it really hard to pay two pending orders at once.
One way that I didn't think of in time would be to have credit accounts for each customer. When a payment is less than the entire order add it to the account instead and leave the order unpaid for now. Allow arbitrary (pre)payments to the account. Once the account is great enough use it to pay the order, you might want to make a payment module for this bit.
Or it could work in reverse, pay all orders immediately and leave a negative balance in the credit account to be paid at a later date. I suspect this would be the least painful way of all.
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!