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!
35.
Displaying All the Invoice Details
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
}
}
11 Comments
Hello ! I just finished training!
I have a few questions for the rest.
1) Could I create a panel to be able to add subscription plans?
2) What happens to customers if I change the information on a plan? (Like the price or the trial period or the plan id). Will this create errors?
3) Can a malicious user send any type of request? Like a refund request or a dispute?
Thank you !
Hey Kiuega !
> Hello ! I just finished training!
Nice work! And thanks for sticking with us despite the tutorial using older an old API :). I hope it was still very useful!
> 1) Could I create a panel to be able to add subscription plans?
Yep definitely! There is a "plan" API. We have very few, specific plans (monthly, yearly, team monthly, team yearly [more or less]) and our UI is specifically built around this small set. That's why we didn't make them dynamic. But you can definitely use the Stripe API to create "plans".
> 2) What happens to customers if I change the information on a plan?
Good question :). Reference: https://stripe.com/docs/bil...
So basically, this is not allowed :). And that's probably a good thing - imagine how complex it would be if you changed a plan's price!
> 3) Can a malicious user send any type of request? Like a refund request or a dispute?
They cannot. The reason is that using the Stripe API requires you to set your private key - https://symfonycasts.com/sc...
Your public key *is* something that's embedded publicly (like on your checkout page) and that allows the AJAX request to be made in JavaScript to send the credit card info. However, no other API calls can be made without having the private key. For example, if someone tried to make an API request to make a refund, they won't have your private key and so they will get rejected. So, keep that private key secret ;).
By the way, this is one of the nice things about Stripe: they are experts in payment & security, and they make it VERY difficult to do something that would leave your site insecure.
Cheers!
Super thank you for all this information! Awesome !
Super that! Yes it is true that using the Stripe API is simpler, but imagine if we really create a large component to be able to manage everything from our application. It would be very useful for our own projects but also if we work for clients who would like to benefit from it. It is the bet that I gave myself in any case. Currently I have no job and therefore I spend my time coding to gain experience and to be noticed. Doing such a panel will definitely benefit me
Usually you can only change the name and the trial period. It should have no impact
Okay awesome !
Hello, I followed the tutorial, everything works well for the majority of customers, my for some customers the subscription does not succeed:
`"message": "This customer has no attached payment source",
And the customer comes across a 500 error page
Do you know how to avoid this problem?
Thanks !
Hey Camille,
Hm, you need to figure our why some customers have no attached payment source. Check your customers who have this problem, does they have credit card linked? You can't create a subscription without CC linked to customers, it's required. So, it's your job to make sure customers have credit card attached before creating a subscription for them.
Basically, try to figure out steps to reproduce. There should be some regularity pattern. Then, when you have steps to reproduce - you can research on it more deeply and hopefully find the root of the problem.
I hope this helps!
Cheers!
Oh, I just saw your answer. Thank you Victor
I do not understand why the customer does not have a card attached to his account (there is no card attached to his account on Stripe) yet the registration page is the same for all customers, for some it works and for others (fortunately minority), it does not work, the card is not attached. The code is therefore the same (the same as in the tutorial) but, for some, the card is not saved ..
At first I thought customers were trying to register without entering a card, but the form cannot be sent if no card has been entered
I'm not sure how to reproduce the problem.
Hey Camille,
> At first I thought customers were trying to register without entering a
card, but the form cannot be sent if no card has been entered
Are you sure it's not possible? Probably they don't have JS enabled? Try to disable JS in your browser and send the form again. Also, you may want to disable HTML5 validation as well to see if the form could be sent then. So, it might be a client's browser issue. Maybe some of your clients trying to do this registration from Internet Explorer or other bad old browser, that in turn cases the losing of CC credentials... I'm not sure, but that's a valid theory, especially if you use some new JS syntax in your code but does not use Webpack Encore with Babel that transpile that code into legacy code. You need to think about some edge cases that might happen during the registration, looks like in some edge cases CC credentials just not saved, but difficult to say something more without debugging.
I hope those ideas help!
Cheers!
Yes it helps! Thank you !!
Wow I've made it through all 2 Parts :)
Now my last questions will be:
1. What should I do/change to run all in production?
2. What is important to know about the right security in symfony?
3. How should I setup Stripe? Should I Only delete all testdata and change to live mode and change the api keys in the config.yml? or is there something else i should know when switching to live?
You guys are amazing. It is worth spending my time on your tuts, cause they are easy to understand and easy to follow :)
Keep up that great work.
Hey Blueblazer172!
First, congrats! This were 2 BIG tutorials... I remember well when I recorded them :).
1) There's nothing specific to Stripe that you'll need to change in production, besides changing your Stripe API key to be your production key, and making sure you're forcing https (which of course you are - since we've been talking about that elsewhere!). If there's anything else, it's specific to Symfony, and it's related to performance. We've got some details about that here: http://symfony.com/doc/curr... - but it's nothing mission critical.
2) Symfony itself is secure (we handle security patches, etc), but of course it doesn't mean that code we write in Symfony is secure :). Thanks to Doctrine, you're already safe from SQL injection attacks (unless you're working around Doctrine in some weird way). And in the tutorial, we've been very sensitive to *never* submit the credit card information to our server. In Symfony, the easiest way to mess up security is... well... to forget to secure sensitive pages. For example, if you have a /admin section... but you forget to check to make sure the user is an admin, then there's your security hole :). Make sure each endpoint is properly secured - that will do a lot. Here in KnpU, we also make sure not to save any personal data we don't need to - e.g. we don't store a user's address anywhere. Obviously, the less data you can store in your server, the better.
3) Yep, the biggest things is to change the API key to live mode (though you'll do this actually in parameters.yml - http://knpuniversity.com/sc.... You'll of course need to make sure your "live mode" is activated on Stripe - iirc they have a few setup things to do that. And finally, don't forget that we setup our Plans in Stripe manually. So the plans will need to be manually setup on production again, with the same plan id's (so that they match our code). You don't need to delete your test data - it's sort of unrelated to changing to "prod" mode.
Oh, one last thing! You should also look into PCI compliance - Stripe makes it easy, but there's some work you might want to look into doing.
Good luck! It's been cool to see your progress!
Thank you for this course and your explications you are amazing !
"Houston: no signs of life"
Start the conversation!