So we had a look at a bit of the evolution,
so a couple of the previous sort of states.
This is leading us through into the count state with JavaScript,
so why don't you explain what it looks like today.
What really happened was that merchants,
people who are selling things on the internet,
decided they didn't want to do PCI DSS.
And so a really clever payment processor came up with a brilliant idea.
And can I just interrupt you there, is that because it is burdensome,
or why would a merchant not want to do PCI?
That's a really great question.
So, if you and I went through PCI DSS and said,
well, which of these controls are not worth doing?
Do you want a firewall?
Probably, it's a good idea.
Do you want good security development lifecycle?
I mean, everything PCI DSS is recognized as good security.
Hygiene-level security.
But merchants are there to buy one thing at a price and then sell it for
a different price and make some money in the middle.
The more they spend on security, that's not their core business.
So if they could find a way of being able to be a store and not have
to be security experts or high security experts,
that's good for them.
Because it's almost, there's a bit there that feels just a little bit dirty,
which is,
you've said like a lot of the PCI DSS objectives are to
try and make a web server more secure, that's a little bit hard,
and we want to be able to sell things without having to make it secure,
so let's unburden ourselves?
Did I get that kind of right?
You sort of got that kind of right, because,
and you have to look at what a merchant's core thing is,
they want to buy something and sell something.
But they don't want to have a team of security experts like a bank would have.
And so originally they have to do that because of the way
they chose to process payment cards.
If you could come up with a way they didn't have to touch the cardholder data,
then the criminals wouldn't attack the merchants,
and therefore the criminals would go somewhere else to get the card data,
and the merchant wouldn't have to spend all this money securing card data.
So,
would it be fair to say there are plenty of merchants
out there who do security well, but if they also had to handle card data,
they would have to do many other things in addition
to the baseline and security?
Yeah, because, you know, it's about threat, isn't it?
And in our business, we always talk about what's the threat out there.
Criminals can monetize card data really easily,
so they're going to spend more effort stealing it.
Okay, so that risk goes away when they don't have to do that.
Okay, cool, so let's have a look at what it looks like now.
So a payment processor came up with a great idea, they call it direct post.
I'm going to run through this really slowly, because it was really clever.
And you might say, you might suddenly go, yeah, but.
But let's go through them really slowly, okay.
So the really clever is that what happens in the
direct post is the consumer's browser, they get to the checkout page,
they want to buy something, they press buy,
you've now got the payment page.
So the payment page, and I've just done a really cut down version,
it's just got two fields on it, and that comes from the merchant's web server.
So it's a normal form slash form.
So what's going to happen is you've bought something on the merchant's website,
you go to check out, you're still on the merchant's website,
it's loaded up the fields for the card data,
you hit Submit, you're now going to post over to the payment provider,
which if it unloads the page and goes to the payment provider,
you'd see the payment provider's address in the URL.
Yeah,
and you might see a flash thank you page from the payment provider
and then it would redirect back to the merchant.
Right.
But it may not totally unload the page, like it might just async post --- Yeah.
In fact, that's exactly what happened,
the first time when this came out to begin with,
it used to bounce to the payment service provider,
it looked a bit ugly,
so then people then did an async post off the Submit
button rather than a bounce post, effectively.
So yeah, so you're not unloading the page,
you're not seeing the payment provider's URL,
that sits there, it's just a nice little come back.
Of course, here's the cool thing.
The merchant's web server now knew the stores,
processes,
or transmits cardholder data --- But it serves the page which requests it.
The key definition in PCI DSS was the merchants,
to be in scope of PCI DSS, you store, process,
or transmit cardholder data.
I just had like this flash of the thing that that reminds me of is remember
in days gone by where we said there'd be a log-in form,
and the log-in form could be loaded in securely because you only needed
to protect the credentials when they're in transit,
and so long as you post to HTTP URI,
and then we saw people owning the log-in form,
which accepts the sensitive data,
and I suspect this is where you were heading with this.
That's where we're heading.
Because now we've gotten no manager security controls on the merchant's server,
the bad guy needs to just put his line of JavaScript
or even tamper with the foreman, originally,
the attacks where they tampered with the foreman,
the Buy button went somewhere else.
So you would just change the form action to post to the attacker.
The criminals, yeah.
And then they could always post to the merchant after that and
then bounce you back to the original location.
Actually what they did was really cool.
They said, so the consumer typed in the --- So the criminals are cool,
just to get this --- The criminals are clever,
the criminals are clever, but maybe not cool,
but clever.
So the consumer would type in their card data,
they press the Submit button, they'd get a message that said I'm sorry,
something went wrong with your payment, please will you do this again.
And the second time it posted to the payment service provider.
The first time it posted to the criminal.
Right, okay.
All right, so that's, that is obviously not a good place to be.
Nope.
Where do we go from here?
Well, actually it even got better because then the world changed,
we started using more asynchronous JavaScript when we were writing web apps,
so we actually now, and this is typically how most payment services work,
so people like Stripe, people like Braintree.
Now it's all based around JavaScript.
So basically the merchant will send a bunch of JavaScript to the browser.
It'll be script source equals Stripe payment form.
Okay, so let's break that down a little bit just to be clear.
So when you say that the merchant sends a bunch of JavaScript,
what you're saying is that the merchant is
returning a script tag to the browser, which means the browser then goes out,
it pulls in whatever the source attribute is,
that source attribute may pull from the payment provider.
So now you've got a situation where someone's browser
has loaded the page from the merchant,
and then the script to do the processing from the payment provider.
Yeah.
And they'll typically just then surface that as a
floating div or something like that.
In the page you'll often see that there it appears to be just
floating or just embedded into the form.
Again, as before, you type your card number in,
you type the expiry date, the address, whatever it wants.
Press the Submit button and again it goes straight
to the payment service provider.
Again, the merchant doesn't see the cardholder data.
So it's just an evolution of the direct post effectively.
So, yeah,
I guess the main value proposition over that direct post model
is that it's a little bit more integrated because it is just
now a single line of JavaScript, the whole page is not unloading.
And I guess also,
if they're pulling that line of JavaScript and then the
payment provider is effectively painting whatever they want
into the DOM to make that input, you know,
the payment provider then has a lot of control over how it
looks and appears and everything else.
And the payment provider can keep changing that and they can get a better
user experience without the merchant being involved in it.
And the payment provider will do that.
There's a little bit in me that just went,
so what you're saying is that the external party,
the third party to the merchant being this payment provider now has
control over deciding what happens on the other side.
Yeah.
Well, we'll see where this goes,
because there's a little bit I feel a bit uncomfortable about.
But again, you have the same problem,
that the payment process starts with the merchant's web server.
Right.
And the merchant's web server is not in scope of PCI DSS.
Right.
Because they're not directly handling the code.