Okay.
Welcome to section ten.
And now it's time to take a look at our checkout and payment system in our application.
And take in payments in our application is not something to be taken lightly.
So let's take a look at what's coming up in this section.
Of course, first of all we're going to take a look at taking payments.
That means user entering their credit card details into a form and us processing the payment.
I say us in air quotes because it's not really going to be us taking the payment as we need to account
for payment card industry compliance, as there's a reason that the internet is kind of a trusted place
where people do enter their credit card details into e-commerce stores with some confidence that it's
not going to be a fraudulent transaction.
We're also going to take a look at strong customer authentication, which is actually a European standard
for taking payments.
But that pretty much means that for a typical e-commerce store, you might as well use this for every
transaction The payment processor we're going to use, because it's pretty much impossible for us to
meet in a training course, the payment card industry compliance standards.
We need to use a payment processor.
The one that we're going to use is stripe.
It comes with a lot of excellent functionality that we can take advantage of in our application.
So we'll also take a look at that.
And one of the things that stripe gives us is a secret key.
So we also need to think about where we're storing these kind of secrets in our code.
So when it comes to taking payments we need to think about PCI compliance.
And this refers to adhering to the Payment Card Industry Data Security Standard, or PCI, DSS to give
it its full abbreviation, which is a set of industry standards designed to protect cardholder data
during processing, storage and transmission, and it increases the protection for payment card information.
And this set of standards applies to any organization that accepts processes Is or stores payment card
information and ensures secure handling to prevent data breaches and fraud.
So we're not going to go into detail about what this is because it's a 100 page document, but it does
relate to six main themes, all of which have more detail inside those documents.
But it relates to things like building and maintaining a secure network, protecting cardholder data,
and maintaining things like a vulnerability management program and implementing strong access control
measures.
Okay, so you've protected your network, but what about your data center?
How secure is that?
Can somebody just walk in off the street and get access to the servers in there?
So then we're talking about physical security as well.
All of these things are literally impossible to demonstrate on a training course, of course.
And also we need an information security policy and also to regularly test and monitor the network.
So a huge range of things encompasses PCI compliance, not just what we do in our code, but also the
physical security around where our data is located.
So not something that we're going to cover on this training course.
And this is really just to point out that you absolutely, really do not want to take people's payment
details directly on your server where you deploy your code.
Otherwise you can be punished and punishment costs money.
So if you're taking payment card details and you experience a hack or a data breach, then there's penalties.
And these penalties range from all sorts of things.
Monthly penalties of 5 to $100,000 a month.
Infringement consequences.
So that's going to cost you 50 to $90 per cardholder that's had their data breached.
Also, compensation costs come along with this as well as legal action, reputation damage revenue loss,
and federal audits can all become involved, so don't do it.
Is the general guidance on taking payment cards?
Unless you're the likes of Amazon and you can meet the PCI compliance standards, then fine.
But if you're not something like Amazon, then the next best thing to do when you do want to take payment
details from someone using your e-commerce store is to use a payment provider like stripe.
This is the one that we are going to use.
Obviously this isn't free of charge.
There is a cost and for each successful card charge, then stripe will take 2.9% of that payment plus
$0.30.
There really is no free way to take money.
We can't take cash on our servers.
That would be the only free way nowadays where you're not paying for receiving money.
Now, another thing that comes along with taking payments online and this is a European Union standard
for authenticating payments.
And even though it's an EU standard, it pretty much applies globally, except for the USA and Canada.
It's possible to take payments in USA and Canada without using strong customer authentication.
But typically, if you're creating an online store, you would accommodate global payments, because
we can use this in the USA and Canada as well as the rest of the world.
So that's what we will be implementing.
But what this really means is that we require two of the following three things.
Something the user knows, such as their password or their Pin.
Something the user has, such as their phone or a hardware token, and something the user is.
And that would be some kind of biometric authentication.
And banks will typically decline payments that require strong customer authentication and do not meet
this standard.
So before we begin getting our hands dirty, let's just take a look at a couple of flows.
The first one only applies to the USA and Canada because it's without strong customer authentication.
The second one is how we're going to implement it, which does utilize this.
So in the first scenario then not the one that we're going to implement, but the possibly simpler one
that doesn't require that.
But you could only sell things in USA and Canada if you were going to implement this kind of flow.
So the user creates an order and that order is sent to our API.
And if successful, the API will send a response back.
At this point the user makes their payment and this would all be within the same form on the client
interface.
The user is not doing two separate things here, but then the user would effectively their credit card
details would be passed up to stripe.
Stripe would then process that payment and return to the user a token, and this token is returned to
the client browser, which then gets sent up to our API, which is then passed on to stripe to check
the token is valid, and if it is, then effectively stripe is going to acknowledge that the payment
has been received and send a notification back to our API.
At that point, we can go back to the user and say, great, we've received your payment.
Everything is fine with the order and the order is on the way.
And the reason this system works is due to that token, because that token will be signed by stripe
using the secret key that's stored on our API server that we get from stripe.
Our API knows it can trust stripe to say, yep, that's the payment that's been received and it's not
the user doing something mischievous.
So how about with strong customer authentication then?
Well, slightly different flow in this case.
So the flow starts with the user going to the checkout before they've actually confirmed they're going
to make an order when they reach the checkout.
At least that's how we're going to implement it in our approach.
When they get to the checkout, then we're going to make a request to our API to create what's referred
to as a payment intent, an intent to pay.
At some future point, we send that payment intent request to Stripe and stripe will create for us a
payment intent ID and a client secret, which then gets returned to the API, which we're going to put
into the customer's shopping cart and return it to the user.
Now at this point, the user can go away, they can come back, they can add things, remove things
from their shopping cart or their baskets.
And that's fine.
Anytime that they come back to the checkout, we're going to repeat that process to update that payment
intent and keep repeating that process up until the point where the user decides that they're going
to make the payment for their order.
At this point, they do enter their credit card details, and this information, along with the client
secret, is sent up to stripe.
Stripe will receive the payment and return successful notification to the client the browser.
At this point, then the order can be created and that can be created on our API.
And our API will acknowledge the successful order the creation.
But what we've got at the moment is no communication directly between the API and stripe.
So the API at this point has got no way of knowing for sure that stripe has successfully received that
payment.
We don't trust the client to tell us that we need to get that information from stripe directly.
So after this stage, our order is going to be in a state of pending payment.
Now at some future points and this happens very quickly, then stripe is going to contact our API directly
using a webhook.
And our API is going to trust what's coming from stripe, because it's going to share a webhook secret
on the API that we get from stripe.
So as long as that webhook secret matches, then our API can acknowledge that and we can update the
payment to be payment received.
And then we can notify the user that their order is on the way.
So that's the flow that we are going to implement to take payments.
And let's begin.