Chapters
35 Chapters
|
3:22:53
|
This course is archived!
This tutorial uses an older version of Symfony of the stripe-php SDK. The majority of the concepts are still valid, though there *are* differences. We've done our best to add notes & comments that describe these changes.
Login to bookmark this video
-
Course Code
Subscribe to download the code!Compatible PHP versions: >=5.5.9, <7.4
Subscribe to download the code!Compatible PHP versions: >=5.5.9, <7.4
-
This Video
Subscribe to download the video!
Subscribe to download the video!
-
Course Script
Subscribe to download the script!
Subscribe to download the script!
25.
Upgrade: Processing the Upcoming Invoice
Scroll down to the script below, click on any sentence (including terminal blocks) to jump to that spot in the video!
Subscribe to jump to this part in the video!
Keep on Learning!
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
This tutorial uses an older version of Symfony of the stripe-php SDK. The majority of the concepts are still valid, though there *are* differences. We've done our best to add notes & comments that describe these changes.
What PHP libraries does this tutorial use?
// composer.json
{
"require": {
"php": ">=5.5.9, <7.4",
"symfony/symfony": "3.1.*", // v3.1.10
"doctrine/orm": "^2.5", // v2.7.2
"doctrine/doctrine-bundle": "^1.6", // 1.6.8
"doctrine/doctrine-cache-bundle": "^1.2", // 1.3.0
"symfony/swiftmailer-bundle": "^2.3", // v2.6.2
"symfony/monolog-bundle": "^2.8", // v2.12.1
"symfony/polyfill-apcu": "^1.0", // v1.3.0
"sensio/distribution-bundle": "^5.0", // v5.0.22
"sensio/framework-extra-bundle": "^3.0.2", // v3.0.26
"incenteev/composer-parameter-handler": "^2.0", // v2.1.2
"friendsofsymfony/user-bundle": "~2.0.1", // v2.0.1
"stof/doctrine-extensions-bundle": "^1.2", // v1.2.2
"stripe/stripe-php": "^3.15", // v3.23.0
"doctrine/doctrine-migrations-bundle": "^1.1", // v1.2.1
"phpunit/phpunit": "^5.5", // 5.7.20
"composer/package-versions-deprecated": "^1.11" // 1.11.99
},
"require-dev": {
"sensio/generator-bundle": "^3.0", // v3.1.4
"symfony/phpunit-bridge": "^3.0", // v3.3.0
"hautelook/alice-bundle": "^1.3", // v1.4.1
"doctrine/data-fixtures": "^1.2" // v1.2.2
}
}
3 Comments
Hey! In case we have a plan that has price ranges (depending on the units). Imagine a user who has a subscription with 150 units. He wants to modify his subscription and take only 100 units but for the same plan (or else for another plan with units, or just change plan for another plan with a fixed price, without quantity), in this case we must specify the quantity in our function, what that it happens.
So, should I have something that looks like this:
Now, in my controller, on the <b>previewPlanChange function</b>
It works if I increase the quantity. On the other hand, if I decide to decrease the quantity, then, systematically, the "amount_due" will be equal to 0 while the "total" will have the good value taking into account the prorations.
The point is if I change :<b>$total = $stripeInvoice->amount_due;</b> by<b>$total = $stripeInvoice->total;</b>
I'm not sure if it's "correct".
Note that I only have this problem in the preview of the invoice. If I confirm, Stripe will do the prorations, the calculations according to what I have to pay, what I have left in my balance, etc. The problem really lies in the preview of the invoice when changing plans
Hey Kiuega!
We do some pretty advanced stuff like this in our site too with the number of "seats" on your team (you can increase/decrease them). To be honest, this stuff is VERY complex, and we have learned how to do it through trial and error - much like what you're doing. In other words, make a change, look at the API response, and reverse-engineer which "properties" appear to be the ones that you want. Stripe's docs are good... but sometimes things are so advanced, that it's not perfectly clear what to use. While it's very strange for there to be 2 different properties depending on an increase vs decrease, it doesn't surprise me too much. The BEST thing about Stripe is how stable their API is. If you find that this situation works for you today, it will continue to work for you tomorrow. We add a lot of logging to our codebase in these types of situations: if we find that an assumption "looks" wrong, we log an error that goes to our Slack channel so that we can look into it and, if necessary, tweak the codebase. That doesn't happen often - you get to a pretty stable situation pretty fast. Also, we're on a different API version that you're using - so I can't compare the exact fields you're using with the one's we're using - there could definitely be differences across API versions.
Sorry I can't give you a better answer... but I *do* think what you're doing is the right direction.
Cheers!
Hello weaverryan
I think I have found the right solution that can work in any case!
From now on, instead of recovering the "amount_due" value which can sometimes be problematic, I recover the "total" which corresponds to the price to be paid (without counting the balance of the user).
In StripeClient.php I created a function which returns the amount of a customer's balance. And another function which will calculate the real price from a total price taking into account the balance of the user.
And it works !
I also take into account the trial periods. This means that a trial user who wants to test with more seats can. But when previewing the next invoice, I tell him "You have X trial days left. After that, you will be debited with X €".
Now, I don't know if the "total" attribute also takes into account a reduction coupon that would have been applied. Otherwise, this fact must still be taken into account.
EDIT : The reduction coupon is taken into account! No need to code more, everything seems operational!
"Houston: no signs of life"
Start the conversation!