The State of Payments Online
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Cull, Ben
Taking payments online has come a long way since the early days of PayPal. With more than half the world's population now spending money online, now is your chance to take a slice of that pie. In this talk I take you through the latest and greatest ways to take payments online, including live coding demos.
 Alright, check one too. Yeah, hey, there we go. Thanks everybody for coming today. I think we'll get started now. It's good to see that Troy Hunt's panel didn't take everyone in the entire conference. I'm pretty happy with that. But today, I'm here to talk to you about the state of payments online. And essentially, I want to cover basically how you should be taking other people's money in 2015. My name is Ben Cull and you can see that I like one particular thing. And so my Twitter handle is Ben who likes beer. Now, by the end of this talk, I promise that you should be inspired. I guess I promise you will be inspired because there is such a massive opportunity at the moment as developers to take a slice of a very big pie called online payments and just the way that money is moving around the world at the moment. And one of the best stats I've seen at the moment, which is increasing all the time, is that 80% of people have shopped online in the last year. And this particular one was taken from a Norwegian statistics magazine. But 80%. It's a little bit less in the US, probably about 72%. But 80% of people have shopped online. And what that means for you and me is that people are getting used to putting their credit card details into the internet. They're getting used to putting their credit card details into their phone to purchase goods. And so it's so simple to take payments. And I'm super excited to show you what's coming up because basically any ID you have, be it as small as it can be, you can add payments into it and try and push that as a product. So today I'm going to be covering a little bit of a history. How did we get here? You know, sort of how have payments evolved online and that sort of thing. I want to cover how payments actually work. So what happens when you plug your credit card data into something? Well, what happens when you go to the shops and you swipe your card, although I don't think you swipe your card here anymore, do you use the chip? And so I want to cover that. I want to take a look at PCI compliance, which is very important. And that's sort of the security of the payment card industry. How is your credit card safe or how is your money safe when you go and put these numbers online? I'm going to cover taking payments the hard way and sort of how we've traditionally done it and take a bit of a look at how that works because it's quite different to the systems we have today. You know, I'm going to cover a bit of PayPal. That's probably what everyone would recognize and you should, I don't know if you've had experience with it, but it's a little bit painful. And so I want to cover that pain and then I want to get to how you should be taking payments in 2015. So let's start with a little bit of history. In 1992, the first online transaction that someone put a credit card into a website for was Books.com and they had built their own credit card processing system back onto the banks, but they were the first ones to do it and they sold books. In 1994, HTTPS was created and so there's been a little bit of a gap there, but that's a really important milestone because pretty much anything that touches credit cards should absolutely be done over HTTPS and there have been a ton of talks already at NDC here about security, so make sure you're using that. Interestingly enough, 95, that's when eBay was founded and this is what's really brought sort of spending money online into the spotlight. You know, eBay was the first system that really got people excited about spending money online. Again, in 95, Amazon was founded and there's a great story that I was talking to someone in Slovenia and they said, hey, Jeff Bezos, who is the founder of Amazon, was so paranoid about credit card data and about security that every time people would purchase something, all the credit card data would go into one single server, he'd unplug the network cable and then start batch processing all that data. He was that worried about accidental leaks and stuff like that, so it was all compiled in one spot and he had a really big head for security and so I can't emphasize that enough. In the early days, especially when it was a bit of a Wild West, security was key. This next one, I'm not sure if you've even heard of it, but I really like to explain this one because Alibaba was founded in 99 and it is the largest, by far, the largest processor of payments on the internet. You can take all the other payments in the world and it doesn't add up to as much as Alibaba processors. Now, this is the biggest one in China, of course. Now, China's population is massive and so it's a massive opportunity here to tap into this market. In 2002, eBay acquired PayPal and, of course, this integrated payments and products together. All of a sudden, people had a brand name they can attach to. They say, Protected by PayPal. People felt safer and spending online started to increase. And in 2011, you'll notice quite a big gap there because nothing much has happened. Nothing much has happened in online payments. In 2011, the first steps of one of my favorite companies started and we're going to get to that one a little bit later. But who am I to tell you about all this sort of stuff? My name is Ben. Hi. I'm a solution architect at SSW. We're a consulting firm in Australia. I'm Mr. Payments at SSW. If there is money flowing through a system, I'm there. It's so important. You might notice that we've got some pretty funky locations around the world. Of course, Australia, that's where we're all from. I'm based in Belgium recently there and it wasn't really a coincidence that I went to sort of the beer capital of the world. Let's just say that. We have a guy in Slovenia and I mentioned before I've done a few talks there as well. And, of course, we have an office in China which is, again, coming to this massive opportunity. There's just so many people. You really can't ignore them and I can't stress that enough. I've been working in the financial industry for quite some time now. Pretty much all my years as a developer, which isn't that many, but I've been in the financial industry. Processing payments. I've seen the dark, deep sort of tentacles of the way banks communicate. I've seen text files go from place to place. I've seen all sorts of really awful techniques. And what you think are very big, secure banks are actually under the covers, quite fragile and quite, I wouldn't say insecure, but there's a lot of risk there that they sort of take on. Now, it's from all this work in the financial industry that I love payments. It's not because I... It's not from the financial industry I love beer, but yes, these are the things that are about me. And if you've seen any of my talks, I always put this slide up. I don't know if you've got untapped, but I'm very proud of the distinct beers number there. Basically, it's a social network for beer drinkers. You check in your beers, it's all quite wanky, but yes. But today I'm going to be talking about the credit system specifically. So there are two ways of taking payments from your customers. You can either reach in to their bank account and just pluck out the money, which is called direct debit. And it's quite popular in Australia. Less so in the US, in fact, it doesn't exist at all. And across Europe, it's not used too much. The second method, of course, is the credit card system. And that also includes any of the Visa and MasterCard debit systems, which are... As long as it goes over Visa and MasterCard, that's the systems I'm talking about. So one of the things that inspired me to get into payments and all this sort of stuff was I was working in my first job straight out of university for a payment processing company. And I wrote... This is right around the time of NBC3 coming out. And I wrote a credit card validator, which is one of those data annotation little attributes you put at the top of your classes to unobtrusive validation, all that whole sweeping thing just automatically works. So I wrote one for credit cards to validate a credit card. And one day, Scott Guthrie blogged about it. In fact, it's right there. Just in passing, Scott Guthrie mentioned me and I was super excited. It blew up my blog. It did everything and it inspired me. And so as soon as Scott Guthrie mentioned me on a blog, I was pretty proud. So what I want to do first is explain how the credit card system sort of works. Because I mean, it's a little bit mysterious. You sort of put a card in, you type some numbers and then money goes from place to place. So first of all, you have an F-Post terminal. Now, it's not called that all over the world, but it's the thing you put your card into and you type the numbers into. It's that little terminal thing. That stands for electronic funds transfer point of sale terminal. Now, when you create a transaction, that transaction goes off to the merchant bank. So each shop you go into physically has a deal with a particular bank. That's called the merchant bank. So the transaction goes directly to them. That bank goes and looks up what bank was attached to the credit card itself or debit card. Now, they do this over a private network. It's over the internet still, but it's like a private network. They'll talk to that issuing bank, which is the customer's bank. The customer's bank will say, yep, he can buy that six pack and it'll go back to the merchant. The merchant sends it back down to the terminal. And in this sort of scenario, the person responsible for the transaction is the merchant bank. So if anything goes wrong anywhere in that whole chain, if the customer's card is fraudulent, if the shop is doing something dodgy, it's all up to the merchant bank. So how do online payments work? Well, it's a very similar system. We'll just move that guy over there. You take the same way of doing things, but you add the internet. You put your website on top of that. And then all you do is you drop off the FBOS terminal and you replace that with a payment processor. Now, a payment processor is just someone who processes the payments, obviously. But the first and most basic one, which people often don't think about, is the bank itself. You can go up to a bank and you can say, I would like a merchant account. And all this account does, it's like a bank account, but all it does is it lets you process credit card data. You can get it from pretty much any bank, especially any of the major banks, but pretty much any bank will give you a merchant account. It's often cheaper than the other payment processors. So if you've heard of PayPal, if you've heard of all the other ones, they might charge you about 2% or 3%. And merchant account is usually in the vicinity of just over 1%. It's quite substantially cheaper. However, the big caveat to this is that you still need to comply with PCI DSS, which is the payment card industry's data security standards. Everyone needs to obey these standards. If you want to process transactions over Visa or over MasterCard, you have to obey the PCI DSS. Even if you are a massive, massive industry and all you do is churn through a ton of bank accounts, that's fine. You do need to do it. Even if you process one transaction a year, if you see credit card data, you need to obey PCI DSS compliance. Everyone. But the key thing to this is that you can avoid it altogether by just not processing credit card data yourself. Now, this is where you may have seen people like PayPal come in. The whole point of PayPal was to remove that risk. It was to make it easier to process these payments. The only problem is PayPal has been around for a very long time and you kind of get dodgy screens like this. I mean, even if you didn't have a PayPal account and you wanted to pay by credit card, you've got to go kind of down here. I'm not sure if that's working. Yes, you'd go down there and fill it out manually. It's not a very nice user experience. So PayPal, this is the number one payment processor that everyone is used to seeing. They'll charge you about 2.9% plus 30 cents a transaction and this is US sort of based stuff here. It does vary by country as well. So make sure you check it out for yourself to see what sort of rates you can get. The biggest problem with PayPal, especially historically, has been their APIs. They used to have a whole range of APIs. It was really, really painful to integrate because you'd have to sort of understand how everything works, how they all interlinked. If you needed to do multiple things, if you needed to take payments on behalf of someone else, it was really painful because you have to figure out the mess. Now, they are developing a new REST API, which is actually looking pretty promising. They've replicated a lot of their old functionality in this new API, but not all of it. So if you do want to still take payments on behalf of someone else, which is a marketplace style transaction, you've got to deal with the old APIs and get web hooks in through the backend. It's not a fun experience. The other key point to the PayPal sort of flow is that it does usually redirect you to another page. You fill out all the information and then you get redirected back to your website. A lot of clients that I go to say, look, I just want something quickly, but I do not want it to redirect. I want the experience to be good. I want it to be contained in our website. The other sort of major hurdle you'll come across. When I was talking in Slovenia just recently, I had one person in the audience as I was talking about this sort of stuff, pipe up and say, hey, we've just completed a PayPal project. It took us a whole month just to implement recurring billing. All they wanted to do was take some money to start with, then sign them up to a plan, then have that money, churn over, and then make sure that if they change plans halfway through, they needed to figure out the pro-rata sort of, will it charge $20 for this? Because you upgraded halfway through it, it will charge you $50 now, and just sorting the whole thing out was a mess. I've also experienced that as well. Luckily, there are things, oh yes, of course, you've got PayPal Touch, which is a new sort of interface that they're developing. If you do implement PayPal, there is a bit of light at the end of the tunnel because you do get a new experience called One Touch, and that will basically remove the ugliness of those other screens, but unfortunately, it still does redirect you away. But it does have a better looking checkout system. It'll remember your details, which is one of the best parts of PayPal, and it does have worldwide brand familiarity. So people know PayPal, they trust PayPal, they understand it, they're going to use it fine. The second payment processor to come along and make things a little bit easier for you is Braintree. Now, if you haven't checked them out, I suggest you do. The first thing you might notice is that they're a PayPal company. They're going to charge you the exact same amount. They were acquired by PayPal only recently, it was maybe a year and a half ago or so, but pretty much this is the answer to a lot of PayPal's failings. Braintree were a separate company, they developed up quite a nice REST API, and PayPal came along and said, yes, I'll have that. So the API is good quality, but one of the sort of great initiatives that they're doing as well is that when you sign up, the first $50,000 that you process is going to be completely free. So no 2.9%, no 30 cents, and it's only if you go over $50,000 that they'll start charging you. So from here, you've already got a free pass. You can just put in a payment system, and the product doesn't have to be profitable, it can be a test run, it can be an experiment, but you can process real money, get into the hands of real people for no transaction fees. The big caveat here, it's only for US, and some parts of the EU. I think most of the EU itself, but not all of Europe. But I think that's pretty sweet, that's a pretty great way of doing things. But I don't really come to this talk on a fair note because I try to treat all payment systems equally, I try to treat everything the same, but unfortunately, I fell in love with Stripe. And so this is my favorite company, founded in 2011. This company does everything right, it's awesome. Not only do I love them for their payment capabilities, but just even everything they do. Their REST API, I point developers to that to say, hey, you want to build a REST API? Go copy their one. You want to document your API properly? Copy their documentation. That's awesome. What these guys will give you is the uncompetitive 2.9% plus 30 cents. Now, again, these are US figures. So in the US, they have no competition. It's all just that level. But across Europe, it does fluctuate a bit. And because we're doing NDC Australia next year, they give you 1.75%. They heard about it. They heard about NDC and they said, we'll give you 1.75%. It's not because they just always charge that in Australia. These guys have the best REST API. It's easy. But it just uses basic ORF. So connecting up is simple. There's no certificates to go in the background like some complex companies do. There's no OAuth flow if you don't want it. You can just use basic ORF with a secret key and it's fine. They do recurring billing. So simply, it's stupid. You just give them a plan ID and the user can change their plans. You can change their plans. It's one call to the API. We'll probably check it out later. And it will do pro rata for you. So if you had a customer on a low plan or no plan, if on a free plan, and they decide to change to a $50 plan, three quarters of the way through the month, it will automatically calculate everything for you and build the customer. If they then change back again, it will still figure it out. And they can do that as many times as they want. They'll just get lots of invoice items on their invoice. But it will only charge them the correct amount for what they used. They have a product called Stripe Checkout. Stripe Checkout is the easiest way to take money in 2015. I'm going to do a demo of Stripe Checkout in just a minute. But essentially, it is just a cool little pop up that lets customers put in their credit card details and you can charge them straight away. They have a product called Stripe Connect, which is a very simple way of making payments on behalf of your customers. If you have a website such as a SaaS app and you need to let your customers charge their customers, Stripe Connect makes this stupidly simple. They also have a brand new feature that only came out about a month ago called Stripe Managed Accounts. Now, the thing with Stripe Connect is that each of your customers has to have a Stripe Account for you to be able to use their Stripe Account to charge other people. The thing with Stripe Managed Accounts is that your customers no longer need a Stripe Account. You can programmatically create a Stripe Account for them and then charge other people without any further information. Eventually, you're going to need to validate those accounts, so you're going to need to ask for identification and then provide that through to Stripe. Again, you can do this all through the API. But the super exciting thing about this is that all SaaS apps can now process credit card data natively and the customer doesn't need a Stripe Account. You don't need to rely on them knowing, oh, who's Stripe? Oh, should I sign up? No, you can just get them signed up. You can get money flowing early on and then once they start seeing the benefits, you can start asking for ID and really sorting out of their accounts so that the limits are lifted and they can process as much as they want. Finally, the kicker is that Stripe supports Alipay, which is the number one processor of payments in China. Now, coming back to this enormous market you can't ignore, you suddenly have it for free. It's in the same workflows, the same API, everything is supported and now you can offer up the same easy interfaces for Chinese products as well. So, a little bit more focus on Stripe Checkout. This is what it looks like. Essentially, you drop a script tag onto your website and then that appears. All they need to do is weck in an email address, a card number and hit go and it's all going to work. They use something called card tokenization. Now, this is how you don't have to deal with PCI because what happens is that Stripe communicates with the browser directly and all you receive is a card token. You never see the credit card data, therefore you don't need to deal with PCI. It's really easy to set up. Again, it's just a script tag. I'm going to go do that in a second. Also, it's got some pretty awesome animations. It flicks around. It does all sorts of... It's great. It's great. Just go check it out. It's great. So, the process flow. How does Stripe Checkout work? For starters, you have your ASP.NET or any other backend, but you have a web server, pumps down the page to the browser. Now, the user simply types their credit card details into that Stripe Checkout thing you saw before, but when they hit submit, Stripe hijacks that submission and sends it off to Stripe directly. It goes from the browser to Stripe. So, the raw credit card data is there. Stripe then return a token to your browser. Your browser then finishes the submission, sending it back to your website. So, it sends the token back to your website. From your web server, you then use your secure key to talk to Stripe directly with that same token, and that is what gets you paid. Then that way you can tell the customer, yep, I got that money. That's good. What we're going to do now is jump out and implement this. It's so simple that you can do it in about five, ten minutes. I'm going to do it right now. So, first of all, what I'm going to do is throw up in a new project. Again, it doesn't matter what you call this. We'll call it Stripe. Checkout one. Nope, I've already done that. Two, three, four, five. There we go. We got him. Okay. So, you can pick any backend. I'm just going to do NBC for the sake of it, so we'll just go okay. And the beauty of this is if we go over to Stripe.com, again, this is where you'll find this sort of stuff. Hopefully my Wi-Fi works. Basically what we're going to do is we're going to go to Stripe.com and we're going to go find the help documentation that I was raving about earlier. Again, if you're building products, Stripe is just such a great company to copy as a developer. There you go. There it is on the home page there. We'll go check out the documentation. And you can see here an example. Let's click. There it goes. Up it comes. So, we're going to go put this into our product. And how do we do that? Well, we go down a little bit and there it is. That's all we need to put in. I might just make that a bit bigger so you can see. But essentially, this is a script. You pass in, well, it goes and grabs the Stripe.js stuff from Stripe itself. You put in your key. Now, you'll notice here's another little bit of a tip that the Stripe key you see there, I'm logged into Stripe right now. And just all of the documentation automatically plugs in the bits for you. So, I don't need to go okay, I'll copy this and then I'll go look up my key and then I'll go put it in. No. The API Docker just puts it straight in so I can literally copy and paste and I'm good. The next thing you'll see is just an image. Don't really care about that. Don't care about the company name. You put a description in, you put a currency in and then you put in a data amount. That's how much they're going to pay in cents or whatever indivisible unit your currency supports. So, let's go grab that particular one. We'll jump over to our new application. And all we're going to do is go to Home Index. Who here uses Rechapper actually? Can I get some hands? Oh, beautiful. Then, who here uses ControlShift T to jump around their projects? Okay, a little less. If you haven't used it, essentially you can just start searching for things. So, I know in the Home feature, you know, there's Home Views and I hit slash and I go, okay, here are the views and if I wanted to say IN for index, like it's just got really good search and it's super quick. So, ControlShift T, Brr-tun. So, up here in the Jumbo Tron, what we'll do is we'll plug in that exact form. So, let's just go put it right instead of learn more. We'll just whack it in there. See how we go. I'm going to hit build and hit run. All right. Immediately, you see pay with card has come up. Let's just make it a bit bigger. You click it. You lose a marketplace image because that, of course, doesn't exist on my server, but you get the email address, you get the card number, you get everything in here and you get some pretty sweet animations. So, as I mentioned, that's great. We've got the client side in our triangle of payment processing. We have the browser side set up. Now, the transaction is only executed on the server. All that this Stripe Checkout thing does is create a token. It doesn't actually process any payments. You've got to do that on your server. So, what we'll do is set that up now too. I'll just make that bigger so you can see. So, we'll go to home controller. We'll create a new index. Here we go. Action results. The thing that we need to go and get is the Stripe token. So, what I might do is just show you that quickly. If we throw up our Chrome tools and we actually process this, let's just go to test at test.com and we'll go forward to, oh, actually, no, this is a happy accident. So, in Stripe Checkout, one of the cool new features is that Stripe will start to remember your credit card all over the Internet. Now, you'll notice I typed test at test.com, which is, I don't know about you guys, what email address you use, but I always use that. Someone else has done that. They've connected their phone number to that email address. And so, anytime you put test at test.com into one of these Stripe Checkout things, it's going to go ask you for the code. So, that's a really cool feature except when you're trying to demo, you know, a Stripe Checkout. So, I'll put my one in and hopefully I haven't done the same thing. No, I haven't. Good. Oh, I need a card number. Do you have a credit card on you? No? Any, anyone have a credit card on them? Oh, no. Oh, no, no, you know what? It's okay. It's okay. I know exactly where to go. Twitter.com slash needed debit card. I don't know if you've seen this website before, but you have some very interesting characters posting some very real credit cards on Twitter. This guy's spray painted his black, sort of look good. So, he's just taking a photo posted on Twitter. My first debit card and probably my last debit card. My favorite thing is, oh, this guy's showing the back. Look, there's the security code. My favorite thing is when people on this particular post, someone's posted the front of their credit card and people go, oh, that's a beautiful card. What does the back look like? But of course, we don't actually need a real one. We're in test mode. I'm not sure if you saw, but my key that I put into the script tag had the word test in it, which means we're in test mode. We're using test keys. And what is the test credit card number? Does anyone know? Anyone? Hence? Five, five, five. No. It's four, two, four, two, four, two, four, two, four, two, four, two, four, two, four, two, four, two. It passes the Luhn algorithm, which is the algorithm that checks credit card validity. It's a Visa card. That's cool. But you can plug this into anything on the Internet and fingers crossed, you might actually get something from it because you can't be charged. We'll put in any valid date in the future and we'll hit pay. Now, the key thing I wanted to capture here is gone because I didn't keep the log on. We'll do it again. So email address, four, two, four, two, four, two, four, two, four, two, valid date in the future. Click it. Okay. So we want the top one. This is going to be a tight fit. Can we make it bigger? We can. See the form data down the bottom there? What we get is a striped token in a variable. We get the fact that it's a card and we get the email address they plugged in as well. So this is all just post data. You'll notice that it didn't post any credit card data, which is good. You don't want to see it. If your server sees credit card data, you all of a sudden need to pay millions of dollars to obey the PCI compliance checks. So what we're going to do now is we're going to jump in and we are going to ask for that Stripe token and we are going to create a new charge. Now the first thing you need to do is jump over to NuGet and search for Stripe.net. Stripe.net isn't officially supported by Stripe, but it is the best.net client for Stripe itself. So there it is at the top, Stripe.net. We'll click install. Now you'll see that the API is pretty simple to use. You could skip this SDK if you wanted to, but it just makes it a bit easier. I mean we're going to put in a few lines of code and we're going to have a working solution. So we'll close that. The first thing we want to do is create a charge and we create that using Stripe. Oh, not that. Not that at all. We use a Stripe, Charge, Create Options. So here we need to put in only a few things. Probably the most important one is the amount. But you might be thinking, why do you have to put the amount in twice? That seems a bit strange, doesn't it? Well the reason is that you don't have to use Stripe Checkout to get a token. You can create a custom form, put in whatever you want, and still use Stripe's JavaScript library and get back a token as well. So because you can display whatever you want, Stripe can't control what you've displayed. So you need to on the server securely tell them exactly what amount to charge. And in this case, we'll put in, I can't remember what was in the form, but I think it was $20. You need to give them a currency, which again, depending on your account, is going to change. I've got Australian dollars for this particular one. You also need to give them a card. Now a card is a new credit card options. We'll go put that in there. But the only thing you need for card is that token. Token ID is equal to our Stripe token. And then we have a charge. It's a pretty simple object. We've filled it out with what we need. The next thing we're going to do is execute the charge. So we'll go service is equal to new Stripe Charge service. And you'll see here we need an API key. Now this brings up a very excellent point. We'll jump into, hopefully I've got it open somewhere, yes. So Stripe, this is what, and I'll go to the dashboard. This is what Stripes dashboard looks like. Now I'm using one of my data accounts. You can just put in as many of these accounts as you want. One email address as many accounts as you want. But what you're going to want to do is take a look at account settings. You don't want to log in. Oh, again, this is really nice. It doesn't make you check, or one of the nice features I like in web apps is that you don't need to log in all the time. But when you do important things such as going and playing with the API keys, it makes you log in again. And I think that's a really nice pattern. But we'll jump, we'll look at API keys. I'm using a fairly old API version, but it doesn't matter. The important thing here is that you look at how testing is done within Stripe. We've got two sets of keys, and all you need to do is use the particular type you want to use to test. Now I don't know if you've used PayPal before, but you have to have a sandbox account. You have to sign up. You've got separate accounts, separate URLs, separate, separate everything. It's awful. But in this, all we need to do is swap out the keys. A web config transform is all you need, and you'll have test to production. Oh, and the great thing is, if you use live keys and you're using Stripe Connect where you make payments on behalf of other people, you can use your live key to get their test keys to then make test transactions. It all flows very well. But what we're going to do is take our test secret key. Now the difference between the test secret key and the publishable key is that, well, one's a secret and one's publishable. I mean, the publishable one, you put in that script, and it'll load the Stripe checkout and identify you as you. And the secret key goes and lets you communicate with Stripe servers directly. So we're going to use our secret key. We're going to plug it into Stripe Charge service. And then we're going to use that service to create a new charge, given the option. So I'll put charge up here, and I'll make that a result. Okay, that's it. That's going to go and execute that payment. What we can do is check that it worked. So if we go result.paid, if it comes back as paid, your beauty will say, let's call it payment message. We'll say, woohoo, it worked. If it didn't work, what we'll do is say, viewbag.payment message is equal to, and in the result object itself, you can find the failure code and failure message. Now these are user friendly errors. You can pass them straight onto the user and they'll understand at least a little bit what's happened, what's gone wrong. So regardless of whether or not those happened, we'll then return the view. Okay, so what we should get here is a Stripe token come in from our Stripe checkout. We create a charge. We fire up an API service. We execute that payment using our test key, and if it worked, we'll say, great, it worked. If it didn't, we'll say, bugger it didn't. So let's just jump into here and put in our viewbag.payment message and see if it works. Don't need a semicolon. Save, build, run. Of course, so what I've done there is not specify that this is a post method only. And we'll fire that back up again. Okay, here we go. We have our home page. We have our pay with card. We have our email address. We have our test card number, future details, and fingers crossed. There's our suite animation, and I made a huge mistake. But this is great. This is learning. Essentially what I've done here is our form action. I don't know who caught that. Who knew that? No, no, no, no, you didn't. I'm sure you didn't. Our form action needs to be home index. So we'll go and put that in. All right, index home resharper gives us little things to say they exist. Let's try that again, shall we? Oh, hang on. I'll refresh just in case. I don't know about you, but I can't get enough of those animations. Show me one other company that does that really cool. One, two, one, eight, one, two, three. All right, this time. Second time lucky. Whoa, yes! Oh, it worked. So all I've done there is process a charge. So if we jump onto our website and we visit the dashboard again, we're refresh, I guess. See this? Today, $20. There it is. Straight in. Now, Stripe operates on a seven-day rolling payout basis, so you'll only get paid on a rolling seven days to make sure the fund's clear and to make sure that they're not charged back or the customer doesn't want any more, etc., etc. But you see everything instantly. So the next thing I kind of want to show you is how recurring billing has been solved by Stripe. A lot of this is very similar. In fact, you'll probably recognize that script tag. But what I'm doing here is I'm displaying a page that lets the user change their plans. So if I have a SaaS application at the moment, and I do, they can have a free account to start with or they can upgrade to paid plans. And so what this one does is it says, hey, if I've already collected this Stripe information, just go and click a button because I don't need them to do anything. But if they haven't, go and render out me a Stripe checkout form. I put my public key in, which is the publishable key. I put in a bunch of other details. Probably the only important thing there is that I can also pre-fill that email address if I already know it. On the server side, all I'm doing is I'm saying, okay, once the user has given me the Stripe token, so they've filled out Stripe checkout, or maybe they haven't. Maybe I've captured it from last time. I'm going to plug in a new Stripe customer options. Now, this is a little bit different to a charge because a charge can only be done once. Once you take a token and you create a charge with it, that token is invalid after that. So what you need to do is create a customer record. A customer record basically just turns that token into a customer ID. It stores it in Stripe. And then you can go and charge that customer over and over and over and over. It's up to you to behave because you can do any amount at any time. So what I've done here, though, for recurring billing, because you can optionally just charge them when you want. So if you have your own scheduling service and your own sort of way of billing them, you can just do it manually and execute payments. But the easy way is to set up plans with Stripe. And all I'm doing here at the top there is passing in the ID of that plan. And then the rest is pretty normal. We've given them an email address. We've given the payment plan a bit of a description. We're passing in the token we get just from Stripe checkout. We fire up a new Stripe customer service, given our secret key. We then receive a customer object, which is down here. We've got a customer ID that we can store in our system. And that's so that we can just use that ID to then process them in future. And in future, this is the only thing you need to do to change their plan. So if they've already typed in all their details, you already have the customer around, and you just want to swap them from $20 to $50 or something like that, you just change the ID, submit that. It's that simple. And what I want to do is just briefly show you what that looks like. So again, here we go. We have a demo portal. I'm not sure how well this is going to be seen. But essentially, we have a demo portal in one of my products. And we have a demo portal. They're on the free plan at the moment. And I want to get them up to, let's say, $30 a month. So you might recognize here, we've got a couple of blue buttons. They look pretty familiar. We'll try one of these. Select plan. Here it comes up with my email address prefilled. I can go and use the magic number. Oh, that's not the magic number. That's the magic number. And again, this is a test system. So it's using my test keys. And we'll go and update this particular person to the $39 plan. That'll go through. And when it's done, that's it. All the customer had to do was put in their credit card details. I now have that for future. So I can go and edit that. So there we go. The first time you're charged, so if I was on a free plan and then I go to a paid plan, it's going to execute a payment straight away. It's going to say, do you have that $39? I think it was. It's going to say, yes, you do. I'm going to charge the card now. And I'm going to save your details for later. And then next month, I'll go and charge you again. But if you've already got a Stripe customer ID and they've already paid for a plan and you're just swapping plans, it's not going to charge you till the end of the month. So be careful of that, actually. If you have a really cheap plan and you put your user in a really expensive plan and they cancel their card, it's only going to try and charge them at the end of the month. So don't offer up your functionality if that's the case. But I think for the most part, it should be fine. So let's go check out what that looks like. So if we go into our customers... Oh, no, it's a connected account, so we won't see that. Oh, that's a shame. Right. So because it's... Yeah, there's some details here which mean I can't show you the customers. But essentially what we can do now, if we jump back to our dashboard, we go back to upgrade plan. I'm just using the same code I showed you just before on those slides. You'll see now that the current plan is selected there and in the back end, all it's doing is swapping the ID and it's going to charge me correctly. And we'll just let that one go through. Beautiful. Okay. The second thing I wanted to show you is the custom forms. You don't have to use StripeCheck out if you don't want to. You can have any old payment form and you can connect StripeJS and it will go and scoop out the credit card details before they can be submitted and then it's going to pump them up to Stripe and your system won't see those credit card details. And so that looks like this. It's a bit weird on this screen, but essentially we have an invoice. This is just custom bootstrap form. It's just text boxes. There's nothing special here, but in the background, what you'll see, if we click on this, we'll see data stripe number. And that data stripe number is just telling StripeJS, hey, this is the credit card number. There's an attribute on every single one of those text boxes telling Stripe which one it is so that automatically when you hit submit, it's going to scoop up that data for you. So if we use the magic number again, one, two, three, four, five, six, seven, eight, we put in any future date and we put in any name. Let's go to test. We can proceed with that payment. That's just a regular submit button and all it's going to do is it's going to send that data to Stripe, come back and then successfully process it. And it should be in test mode. I hope that's in test mode. Anything, anything, let's just change the month and we'll say something like that. All right. Let's go. And sometimes, if you haven't upgraded your VMs to a stronger one, there we go. Thank you for your payment. There we go. So a custom form and Stripe checkout, super simple. There's not much code there. It's just a few attributes and that's all you need to do. So I wouldn't work for Adam Kogan if I didn't have a few suggestions for Stripe and all the others. Number one, PayPal. I'd really love a JavaScript library for tokenizing credit cards because at the moment, you can only be redirected. You can only have your credit card data on the server. You've got to comply with a bunch of stuff. It would be great if you had a JavaScript library to tokenize credit cards. Braintree. I would love it if your marketplace or being able to automatically sign up customers and charge on behalf of other people was outside the US. Now with Stripe, I know that Norway is on beta at the moment and so you can get in there and actually do everything that I've shown today right now. It'll work. The beta just means that not all of the features, especially the Stripe marketplace, is going to work. Stripe, the last time I gave this talk, I wanted you to remember details across the internet because I thought you were excellent. I would really love that functionality that PayPal provides where you need to sign up once and you get it forever. But they've done that. They actually did that in the last, within the last six months essentially. So I have a new suggestion. I would love to see a whole heap of that UI gold that you provide in Stripe Checkout and other places for signing up clients. Some sort of automated process for getting clients on board with a nice shiny UI. We've taken a look at skykelec.com today. This is the product that I made with custom payment forms. It's got Checkout and Connect. And the reason I bring this up is because if any of you have questions about how any of the Stripe stuff works, this is the proof that I can get it done pretty quickly. And I'm super happy to take any questions or any, if you ever get stuck trying to implement anything, I'm quite happy to help you out. I'd just like to say thank you. You can contact me at Ben Who Likes Beer. You can check out my blog. Otherwise, have a great day. Yes. Sorry? Yes, questions. Happy to take questions. Right. So the question was what about refunds? Can you do that through Stripe? Yes, you can actually. They have a very good refund API. You can also do it through the web interface if you sort of need to look up customer details a bit easier. So if a customer says, hey, why was I charged this? You can jump onto the Stripe dashboard, look up the customer information, find the charge and go, oh, yes, I'm very sorry. That shouldn't have happened. One click and the whole thing is refunded automatically. Now, you might say, okay, then how does your system know about that? There's a whole world of web hooks out there. So Stripe will pump down information about everything that happens within Stripe. And you can just put one endpoint in and then read that information out and react to what happens. And this is the same thing that happens for if a customer sort of cancels outside of your system or a card is declined on a monthly transaction or anything like that or if they change their location or something like that, you can be notified through that web hook system. Beautiful. Any other questions? Yes, over here. How does the customer know that they can trust your payment? Because if you're redirected to PayPal, even if you come from some sort of place, you don't know that this is safe because you look down at your card, PayPal, HGT, TPS and like everything, it just pops up a window in the middle of the web page. And the credit card number, I never got the market. Excellent. So the question was, how can you trust Stripe or how does the customer know that they can trust your website because you can put whatever form you want there? Now, that's actually up to you to build that trust. At the moment on the internet, there's tons of credit card information that people put in every day and it's just dodgy implementations. So you're right. The whole idea is that you can use Stripe's branding, which isn't very familiar, or you can roll your own and try and make the process as seamless as possible. But it's really up to you. You've got to try and sort of build that trust yourself. But you're right. It doesn't have the brand familiarity that PayPal does. Any other questions? No? Very good. If anyone wants to come up and chat to me about beers, I've got a couple of bottle openers to give away as well. And I've got a few stickers. I don't know if you like these. Again, if you're just nice to companies and you say, hey, I'd really like some stuff, they'll give it to you. So if anyone wants a sticker, they can come up and grab it as well. But apart from that, have an excellent NDC and I'll catch you guys later. Yeah, be my guest. Stand here. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.
 Alright, check one too. Yeah, hey, there we go. Thanks everybody for coming today. I think  we'll get started now. It's good to see that Troy Hunt's panel didn't take everyone in  the entire conference. I'm pretty happy with that. But today, I'm here to talk to you about  the state of payments online. And essentially, I want to cover basically how you should be  taking other people's money in 2015. My name is Ben Cull and you can see that I like one  particular thing. And so my Twitter handle is Ben who likes beer. Now, by the end of  this talk, I promise that you should be inspired. I guess I promise you will be inspired because  there is such a massive opportunity at the moment as developers to take a slice of a  very big pie called online payments and just the way that money is moving around the world  at the moment. And one of the best stats I've seen at the moment, which is increasing all  the time, is that 80% of people have shopped online in the last year. And this particular  one was taken from a Norwegian statistics magazine. But 80%. It's a little bit less  in the US, probably about 72%. But 80% of people have shopped online. And what that  means for you and me is that people are getting used to putting their credit card details  into the internet. They're getting used to putting their credit card details into their  phone to purchase goods. And so it's so simple to take payments. And I'm super excited to  show you what's coming up because basically any ID you have, be it as small as it can  be, you can add payments into it and try and push that as a product. So today I'm going  to be covering a little bit of a history. How did we get here? You know, sort of how  have payments evolved online and that sort of thing. I want to cover how payments actually  work. So what happens when you plug your credit card data into something? Well, what happens  when you go to the shops and you swipe your card, although I don't think you swipe your  card here anymore, do you use the chip? And so I want to cover that. I want to take a  look at PCI compliance, which is very important. And that's sort of the security of the payment  card industry. How is your credit card safe or how is your money safe when you go and  put these numbers online? I'm going to cover taking payments the hard way and sort of how  we've traditionally done it and take a bit of a look at how that works because it's quite  different to the systems we have today. You know, I'm going to cover a bit of PayPal.  That's probably what everyone would recognize and you should, I don't know if you've had  experience with it, but it's a little bit painful. And so I want to cover that pain  and then I want to get to how you should be taking payments in 2015.  So let's start with a little bit of history. In 1992, the first online transaction that  someone put a credit card into a website for was Books.com and they had built their own  credit card processing system back onto the banks, but they were the first ones to do  it and they sold books. In 1994, HTTPS was created and so there's  been a little bit of a gap there, but that's a really important milestone because pretty  much anything that touches credit cards should absolutely be done over HTTPS and there have  been a ton of talks already at NDC here about security, so make sure you're using that.  Interestingly enough, 95, that's when eBay was founded and this is what's really brought  sort of spending money online into the spotlight. You know, eBay was the first system that really  got people excited about spending money online. Again, in 95, Amazon was founded and there's  a great story that I was talking to someone in Slovenia and they said, hey, Jeff Bezos,  who is the founder of Amazon, was so paranoid about credit card data and about security  that every time people would purchase something, all the credit card data would go into one  single server, he'd unplug the network cable and then start batch processing all that data.  He was that worried about accidental leaks and stuff like that, so it was all compiled  in one spot and he had a really big head for security and so I can't emphasize that enough.  In the early days, especially when it was a bit of a Wild West, security was key.  This next one, I'm not sure if you've even heard of it, but I really like to explain  this one because Alibaba was founded in 99 and it is the largest, by far, the largest  processor of payments on the internet. You can take all the other payments in the world  and it doesn't add up to as much as Alibaba processors. Now, this is the biggest one in  China, of course. Now, China's population is massive and so it's a massive opportunity  here to tap into this market. In 2002, eBay acquired PayPal and, of course, this integrated  payments and products together. All of a sudden, people had a brand name they can attach to.  They say, Protected by PayPal. People felt safer and spending online started to increase.  And in 2011, you'll notice quite a big gap there because nothing much has happened. Nothing  much has happened in online payments. In 2011, the first steps of one of my favorite companies  started and we're going to get to that one a little bit later. But who am I to tell you  about all this sort of stuff? My name is Ben. Hi. I'm a solution architect at SSW. We're  a consulting firm in Australia. I'm Mr. Payments at SSW. If there is money flowing through  a system, I'm there. It's so important. You might notice that we've got some pretty funky  locations around the world. Of course, Australia, that's where we're all from. I'm based in  Belgium recently there and it wasn't really a coincidence that I went to sort of the  beer capital of the world. Let's just say that. We have a guy in Slovenia and I mentioned  before I've done a few talks there as well. And, of course, we have an office in China  which is, again, coming to this massive opportunity. There's just so many people. You really can't  ignore them and I can't stress that enough. I've been working in the financial industry  for quite some time now. Pretty much all my years as a developer, which isn't that many,  but I've been in the financial industry. Processing payments. I've seen the dark, deep sort of  tentacles of the way banks communicate. I've seen text files go from place to place. I've  seen all sorts of really awful techniques. And what you think are very big, secure banks  are actually under the covers, quite fragile and quite, I wouldn't say insecure, but there's  a lot of risk there that they sort of take on. Now, it's from all this work in the financial  industry that I love payments. It's not because I... It's not from the financial industry  I love beer, but yes, these are the things that are about me. And if you've seen any  of my talks, I always put this slide up. I don't know if you've got untapped, but I'm  very proud of the distinct beers number there. Basically, it's a social network for beer  drinkers. You check in your beers, it's all quite wanky, but yes. But today I'm going  to be talking about the credit system specifically. So there are two ways of taking payments  from your customers. You can either reach in to their bank account and just pluck out  the money, which is called direct debit. And it's quite popular in Australia. Less so  in the US, in fact, it doesn't exist at all. And across Europe, it's not used too much.  The second method, of course, is the credit card system. And that also includes any of  the Visa and MasterCard debit systems, which are... As long as it goes over Visa and MasterCard,  that's the systems I'm talking about. So one of the things that inspired me to get  into payments and all this sort of stuff was I was working in my first job straight out  of university for a payment processing company. And I wrote... This is right around the time  of NBC3 coming out. And I wrote a credit card validator, which is one of those data annotation  little attributes you put at the top of your classes to unobtrusive validation, all that  whole sweeping thing just automatically works. So I wrote one for credit cards to validate  a credit card. And one day, Scott Guthrie blogged about it. In fact, it's right there.  Just in passing, Scott Guthrie mentioned me and I was super excited. It blew up my blog.  It did everything and it inspired me. And so as soon as Scott Guthrie mentioned me  on a blog, I was pretty proud. So what I want to do first is explain how the credit card  system sort of works. Because I mean, it's a little bit mysterious. You sort of put a  card in, you type some numbers and then money goes from place to place. So first of all,  you have an F-Post terminal. Now, it's not called that all over the world, but it's the  thing you put your card into and you type the numbers into. It's that little terminal  thing. That stands for electronic funds transfer point of sale terminal. Now, when you create  a transaction, that transaction goes off to the merchant bank. So each shop you go into  physically has a deal with a particular bank. That's called the merchant bank. So the transaction  goes directly to them. That bank goes and looks up what bank was attached to the credit  card itself or debit card. Now, they do this over a private network. It's over the internet  still, but it's like a private network. They'll talk to that issuing bank, which is the customer's  bank. The customer's bank will say, yep, he can buy that six pack and it'll go back to  the merchant. The merchant sends it back down to the terminal. And in this sort of scenario,  the person responsible for the transaction is the merchant bank. So if anything goes wrong  anywhere in that whole chain, if the customer's card is fraudulent, if the shop is doing something  dodgy, it's all up to the merchant bank. So how do online payments work? Well, it's a very  similar system. We'll just move that guy over there. You take the same way of doing things,  but you add the internet. You put your website on top of that. And then all you do is you  drop off the FBOS terminal and you replace that with a payment processor. Now, a payment  processor is just someone who processes the payments, obviously. But the first and most  basic one, which people often don't think about, is the bank itself. You can go up to  a bank and you can say, I would like a merchant account. And all this account does, it's like  a bank account, but all it does is it lets you process credit card data. You can get  it from pretty much any bank, especially any of the major banks, but pretty much any bank  will give you a merchant account. It's often cheaper than the other payment processors.  So if you've heard of PayPal, if you've heard of all the other ones, they might charge you  about 2% or 3%. And merchant account is usually in the vicinity of just over 1%. It's quite  substantially cheaper. However, the big caveat to this is that you still need to comply with  PCI DSS, which is the payment card industry's data security standards. Everyone needs to  obey these standards. If you want to process transactions over Visa or over MasterCard,  you have to obey the PCI DSS. Even if you are a massive, massive industry and all you do  is churn through a ton of bank accounts, that's fine. You do need to do it. Even if you process  one transaction a year, if you see credit card data, you need to obey PCI DSS compliance.  Everyone. But the key thing to this is that you can avoid it altogether by just not processing  credit card data yourself. Now, this is where you may have seen people like PayPal come in.  The whole point of PayPal was to remove that risk. It was to make it easier to process  these payments. The only problem is PayPal has been around for a very long time and you  kind of get dodgy screens like this. I mean, even if you didn't have a PayPal account and  you wanted to pay by credit card, you've got to go kind of down here. I'm not sure if that's  working. Yes, you'd go down there and fill it out manually. It's not a very nice user  experience. So PayPal, this is the number one payment processor that everyone is used to  seeing. They'll charge you about 2.9% plus 30 cents a transaction and this is US sort  of based stuff here. It does vary by country as well. So make sure you check it out for  yourself to see what sort of rates you can get. The biggest problem with PayPal, especially  historically, has been their APIs. They used to have a whole range of APIs. It was really,  really painful to integrate because you'd have to sort of understand how everything  works, how they all interlinked. If you needed to do multiple things, if you needed to take  payments on behalf of someone else, it was really painful because you have to figure  out the mess. Now, they are developing a new REST API, which is actually looking pretty  promising. They've replicated a lot of their old functionality in this new API, but not  all of it. So if you do want to still take payments on behalf of someone else, which  is a marketplace style transaction, you've got to deal with the old APIs and get web  hooks in through the backend. It's not a fun experience. The other key point to the PayPal  sort of flow is that it does usually redirect you to another page. You fill out all the  information and then you get redirected back to your website. A lot of clients that I go  to say, look, I just want something quickly, but I do not want it to redirect. I want the  experience to be good. I want it to be contained in our website. The other sort of major hurdle  you'll come across. When I was talking in Slovenia just recently, I had one person in  the audience as I was talking about this sort of stuff, pipe up and say, hey, we've just  completed a PayPal project. It took us a whole month just to implement recurring billing.  All they wanted to do was take some money to start with, then sign them up to a plan,  then have that money, churn over, and then make sure that if they change plans halfway  through, they needed to figure out the pro-rata sort of, will it charge $20 for this? Because  you upgraded halfway through it, it will charge you $50 now, and just sorting the whole thing  out was a mess. I've also experienced that as well. Luckily, there are things, oh yes,  of course, you've got PayPal Touch, which is a new sort of interface that they're developing.  If you do implement PayPal, there is a bit of light at the end of the tunnel because  you do get a new experience called One Touch, and that will basically remove the ugliness  of those other screens, but unfortunately, it still does redirect you away. But it does  have a better looking checkout system. It'll remember your details, which is one of the  best parts of PayPal, and it does have worldwide brand familiarity. So people know PayPal,  they trust PayPal, they understand it, they're going to use it fine.  The second payment processor to come along and make things a little bit easier for you  is Braintree. Now, if you haven't checked them out, I suggest you do. The first thing  you might notice is that they're a PayPal company. They're going to charge you the exact  same amount. They were acquired by PayPal only recently, it was maybe a year and a half ago  or so, but pretty much this is the answer to a lot of PayPal's failings. Braintree were  a separate company, they developed up quite a nice REST API, and PayPal came along and  said, yes, I'll have that. So the API is good quality, but one of the sort of great initiatives  that they're doing as well is that when you sign up, the first $50,000 that you process  is going to be completely free. So no 2.9%, no 30 cents, and it's only if you go over  $50,000 that they'll start charging you. So from here, you've already got a free pass.  You can just put in a payment system, and the product doesn't have to be profitable,  it can be a test run, it can be an experiment, but you can process real money, get into the  hands of real people for no transaction fees. The big caveat here, it's only for US, and  some parts of the EU. I think most of the EU itself, but not all of Europe. But I think  that's pretty sweet, that's a pretty great way of doing things. But I don't really come  to this talk on a fair note because I try to treat all payment systems equally, I try  to treat everything the same, but unfortunately, I fell in love with Stripe. And so this is  my favorite company, founded in 2011. This company does everything right, it's awesome.  Not only do I love them for their payment capabilities, but just even everything they  do. Their REST API, I point developers to that to say, hey, you want to build a REST  API? Go copy their one. You want to document your API properly? Copy their documentation.  That's awesome. What these guys will give you is the uncompetitive 2.9% plus 30 cents.  Now, again, these are US figures. So in the US, they have no competition. It's all just  that level. But across Europe, it does fluctuate a bit. And because we're doing NDC Australia  next year, they give you 1.75%. They heard about it. They heard about NDC and they said,  we'll give you 1.75%. It's not because they just always charge that in Australia. These  guys have the best REST API. It's easy. But it just uses basic ORF. So connecting up is  simple. There's no certificates to go in the background like some complex companies do.  There's no OAuth flow if you don't want it. You can just use basic ORF with a secret key  and it's fine. They do recurring billing. So simply, it's stupid. You just give them  a plan ID and the user can change their plans. You can change their plans. It's one call  to the API. We'll probably check it out later. And it will do pro rata for you. So if you  had a customer on a low plan or no plan, if on a free plan, and they decide to change  to a $50 plan, three quarters of the way through the month, it will automatically calculate  everything for you and build the customer. If they then change back again, it will still  figure it out. And they can do that as many times as they want. They'll just get lots  of invoice items on their invoice. But it will only charge them the correct amount for  what they used. They have a product called Stripe Checkout. Stripe Checkout is the easiest  way to take money in 2015. I'm going to do a demo of Stripe Checkout in just a minute.  But essentially, it is just a cool little pop up that lets customers put in their credit  card details and you can charge them straight away. They have a product called Stripe Connect,  which is a very simple way of making payments on behalf of your customers. If you have a  website such as a SaaS app and you need to let your customers charge their customers,  Stripe Connect makes this stupidly simple. They also have a brand new feature that only  came out about a month ago called Stripe Managed Accounts. Now, the thing with Stripe Connect  is that each of your customers has to have a Stripe Account for you to be able to use  their Stripe Account to charge other people. The thing with Stripe Managed Accounts is  that your customers no longer need a Stripe Account. You can programmatically create a  Stripe Account for them and then charge other people without any further information. Eventually,  you're going to need to validate those accounts, so you're going to need to ask for identification  and then provide that through to Stripe. Again, you can do this all through the API. But the  super exciting thing about this is that all SaaS apps can now process credit card data  natively and the customer doesn't need a Stripe Account. You don't need to rely on them knowing,  oh, who's Stripe? Oh, should I sign up? No, you can just get them signed up. You can get  money flowing early on and then once they start seeing the benefits, you can start asking  for ID and really sorting out of their accounts so that the limits are lifted and they can  process as much as they want. Finally, the kicker is that Stripe supports Alipay, which  is the number one processor of payments in China. Now, coming back to this enormous market  you can't ignore, you suddenly have it for free. It's in the same workflows, the same  API, everything is supported and now you can offer up the same easy interfaces for Chinese  products as well. So, a little bit more focus on Stripe Checkout. This is what it looks like.  Essentially, you drop a script tag onto your website and then that appears. All they need  to do is weck in an email address, a card number and hit go and it's all going to work.  They use something called card tokenization. Now, this is how you don't have to deal with  PCI because what happens is that Stripe communicates with the browser directly and all you receive  is a card token. You never see the credit card data, therefore you don't need to deal  with PCI. It's really easy to set up. Again, it's just a script tag. I'm going to go do  that in a second. Also, it's got some pretty awesome animations. It flicks around. It does  all sorts of... It's great. It's great. Just go check it out. It's great. So, the process  flow. How does Stripe Checkout work? For starters, you have your ASP.NET or any other backend,  but you have a web server, pumps down the page to the browser. Now, the user simply  types their credit card details into that Stripe Checkout thing you saw before, but when  they hit submit, Stripe hijacks that submission and sends it off to Stripe directly. It goes  from the browser to Stripe. So, the raw credit card data is there. Stripe then return a token  to your browser. Your browser then finishes the submission, sending it back to your website.  So, it sends the token back to your website. From your web server, you then use your secure  key to talk to Stripe directly with that same token, and that is what gets you paid. Then  that way you can tell the customer, yep, I got that money. That's good.  What we're going to do now is jump out and implement this. It's so simple that you can  do it in about five, ten minutes. I'm going to do it right now. So, first of all, what  I'm going to do is throw up in a new project. Again, it doesn't matter what you call this.  We'll call it Stripe. Checkout one. Nope, I've already done that. Two, three, four, five.  There we go. We got him. Okay. So, you can pick any backend. I'm just going to do NBC  for the sake of it, so we'll just go okay. And the beauty of this is if we go over to  Stripe.com, again, this is where you'll find this sort of stuff. Hopefully my Wi-Fi works.  Basically what we're going to do is we're going to go to Stripe.com and we're going  to go find the help documentation that I was raving about earlier. Again, if you're building  products, Stripe is just such a great company to copy as a developer. There you go. There  it is on the home page there. We'll go check out the documentation. And you can see here  an example. Let's click. There it goes. Up it comes. So, we're going to go put this into  our product. And how do we do that? Well, we go down a little bit and there it is. That's  all we need to put in. I might just make that a bit bigger so you can see. But essentially,  this is a script. You pass in, well, it goes and grabs the Stripe.js stuff from Stripe  itself. You put in your key. Now, you'll notice here's another little bit of a tip that the  Stripe key you see there, I'm logged into Stripe right now. And just all of the documentation  automatically plugs in the bits for you. So, I don't need to go okay, I'll copy this and  then I'll go look up my key and then I'll go put it in. No. The API Docker just puts it  straight in so I can literally copy and paste and I'm good. The next thing you'll see is  just an image. Don't really care about that. Don't care about the company name. You put  a description in, you put a currency in and then you put in a data amount. That's how much  they're going to pay in cents or whatever indivisible unit your currency supports. So,  let's go grab that particular one. We'll jump over to our new application. And all we're  going to do is go to Home Index. Who here uses Rechapper actually? Can I get some hands?  Oh, beautiful. Then, who here uses ControlShift T to jump around their projects? Okay, a little  less. If you haven't used it, essentially you can just start searching for things. So,  I know in the Home feature, you know, there's Home Views and I hit slash and I go, okay,  here are the views and if I wanted to say IN for index, like it's just got really good  search and it's super quick. So, ControlShift T, Brr-tun. So, up here in the Jumbo Tron,  what we'll do is we'll plug in that exact form. So, let's just go put it right instead  of learn more. We'll just whack it in there. See how we go. I'm going to hit build and  hit run. All right. Immediately, you see pay with card has come up. Let's just make it  a bit bigger. You click it. You lose a marketplace image because that, of course, doesn't exist  on my server, but you get the email address, you get the card number, you get everything  in here and you get some pretty sweet animations. So, as I mentioned, that's great. We've got  the client side in our triangle of payment processing. We have the browser side set up.  Now, the transaction is only executed on the server. All that this Stripe Checkout thing  does is create a token. It doesn't actually process any payments. You've got to do that  on your server. So, what we'll do is set that up now too. I'll just make that bigger so  you can see. So, we'll go to home controller. We'll create a new index. Here we go. Action  results. The thing that we need to go and get is the Stripe token. So, what I might do  is just show you that quickly. If we throw up our Chrome tools and we actually process  this, let's just go to test at test.com and we'll go forward to, oh, actually, no, this  is a happy accident. So, in Stripe Checkout, one of the cool new features is that Stripe  will start to remember your credit card all over the Internet. Now, you'll notice I typed  test at test.com, which is, I don't know about you guys, what email address you use, but I  always use that. Someone else has done that. They've connected their phone number to that  email address. And so, anytime you put test at test.com into one of these Stripe Checkout  things, it's going to go ask you for the code. So, that's a really cool feature except when  you're trying to demo, you know, a Stripe Checkout. So, I'll put my one in and hopefully  I haven't done the same thing. No, I haven't. Good. Oh, I need a card number. Do you have  a credit card on you? No? Any, anyone have a credit card on them? Oh, no. Oh, no, no,  you know what? It's okay. It's okay. I know exactly where to go. Twitter.com slash needed  debit card. I don't know if you've seen this website before, but you have some very interesting  characters posting some very real credit cards on Twitter. This guy's spray painted his black,  sort of look good. So, he's just taking a photo posted on Twitter. My first debit card and  probably my last debit card. My favorite thing is, oh, this guy's showing the back. Look,  there's the security code. My favorite thing is when people on this particular post, someone's  posted the front of their credit card and people go, oh, that's a beautiful card. What  does the back look like? But of course, we don't actually need a real one. We're in  test mode. I'm not sure if you saw, but my key that I put into the script tag had the  word test in it, which means we're in test mode. We're using test keys. And what is the  test credit card number? Does anyone know? Anyone? Hence?  Five, five, five. No. It's four, two, four, two, four, two, four, two, four, two, four,  two, four, two, four, two, four, two. It passes the Luhn algorithm, which is the algorithm  that checks credit card validity. It's a Visa card. That's cool. But you can plug this into  anything on the Internet and fingers crossed, you might actually get something from it because  you can't be charged. We'll put in any valid date in the future and we'll hit pay. Now,  the key thing I wanted to capture here is gone because I didn't keep the log on. We'll  do it again. So email address, four, two, four, two, four, two, four, two, four, two,  valid date in the future. Click it. Okay. So we want the top one. This is going to be  a tight fit. Can we make it bigger? We can. See the form data down the bottom there? What  we get is a striped token in a variable. We get the fact that it's a card and we get  the email address they plugged in as well. So this is all just post data. You'll notice  that it didn't post any credit card data, which is good. You don't want to see it. If  your server sees credit card data, you all of a sudden need to pay millions of dollars  to obey the PCI compliance checks. So what we're going to do now is we're going to jump  in and we are going to ask for that Stripe token and we are going to create a new charge.  Now the first thing you need to do is jump over to NuGet and search for Stripe.net. Stripe.net  isn't officially supported by Stripe, but it is the best.net client for Stripe itself.  So there it is at the top, Stripe.net. We'll click install. Now you'll see that the API  is pretty simple to use. You could skip this SDK if you wanted to, but it just makes it  a bit easier. I mean we're going to put in a few lines of code and we're going to have  a working solution. So we'll close that. The first thing we want to do is create a charge  and we create that using Stripe. Oh, not that. Not that at all. We use a Stripe, Charge,  Create Options. So here we need to put in only a few things. Probably the most important  one is the amount. But you might be thinking, why do you have to put the amount in twice?  That seems a bit strange, doesn't it? Well the reason is that you don't have to use Stripe  Checkout to get a token. You can create a custom form, put in whatever you want, and  still use Stripe's JavaScript library and get back a token as well. So because you can  display whatever you want, Stripe can't control what you've displayed. So you need to on the  server securely tell them exactly what amount to charge. And in this case, we'll put in,  I can't remember what was in the form, but I think it was $20. You need to give them a  currency, which again, depending on your account, is going to change. I've got Australian dollars  for this particular one. You also need to give them a card. Now a card is a new credit  card options. We'll go put that in there. But the only thing you need for card is that  token. Token ID is equal to our Stripe token. And then we have a charge. It's a pretty simple  object. We've filled it out with what we need. The next thing we're going to do is execute  the charge. So we'll go service is equal to new Stripe Charge service. And you'll see  here we need an API key. Now this brings up a very excellent point. We'll jump into, hopefully  I've got it open somewhere, yes. So Stripe, this is what, and I'll go to the dashboard.  This is what Stripes dashboard looks like. Now I'm using one of my data accounts. You  can just put in as many of these accounts as you want. One email address as many accounts  as you want. But what you're going to want to do is take a look at account settings. You  don't want to log in. Oh, again, this is really nice. It doesn't make you check, or one of  the nice features I like in web apps is that you don't need to log in all the time. But  when you do important things such as going and playing with the API keys, it makes you  log in again. And I think that's a really nice pattern. But we'll jump, we'll look at  API keys. I'm using a fairly old API version, but it doesn't matter. The important thing  here is that you look at how testing is done within Stripe. We've got two sets of keys,  and all you need to do is use the particular type you want to use to test. Now I don't  know if you've used PayPal before, but you have to have a sandbox account. You have to  sign up. You've got separate accounts, separate URLs, separate, separate everything. It's  awful. But in this, all we need to do is swap out the keys. A web config transform is all  you need, and you'll have test to production. Oh, and the great thing is, if you use live  keys and you're using Stripe Connect where you make payments on behalf of other people,  you can use your live key to get their test keys to then make test transactions. It all  flows very well. But what we're going to do is take our test secret key. Now the difference  between the test secret key and the publishable key is that, well, one's a secret and one's  publishable. I mean, the publishable one, you put in that script, and it'll load the  Stripe checkout and identify you as you. And the secret key goes and lets you communicate  with Stripe servers directly. So we're going to use our secret key. We're going to plug  it into Stripe Charge service. And then we're going to use that service to create a new  charge, given the option. So I'll put charge up here, and I'll make that a result. Okay,  that's it. That's going to go and execute that payment. What we can do is check that  it worked. So if we go result.paid, if it comes back as paid, your beauty will say,  let's call it payment message. We'll say, woohoo, it worked. If it didn't work, what  we'll do is say, viewbag.payment message is equal to, and in the result object itself,  you can find the failure code and failure message. Now these are user friendly errors.  You can pass them straight onto the user and they'll understand at least a little bit what's  happened, what's gone wrong. So regardless of whether or not those happened, we'll then  return the view. Okay, so what we should get here is a Stripe token come in from our Stripe  checkout. We create a charge. We fire up an API service. We execute that payment using  our test key, and if it worked, we'll say, great, it worked. If it didn't, we'll say,  bugger it didn't. So let's just jump into here and put in our viewbag.payment message  and see if it works. Don't need a semicolon. Save, build, run. Of course, so what I've  done there is not specify that this is a post method only. And we'll fire that back up again.  Okay, here we go. We have our home page. We have our pay with card. We have our email  address. We have our test card number, future details, and fingers crossed. There's our  suite animation, and I made a huge mistake. But this is great. This is learning. Essentially  what I've done here is our form action. I don't know who caught that. Who knew that?  No, no, no, no, you didn't. I'm sure you didn't. Our form action needs to be home index. So  we'll go and put that in. All right, index home resharper gives us little things to say  they exist. Let's try that again, shall we? Oh, hang on. I'll refresh just in case. I  don't know about you, but I can't get enough of those animations. Show me one other company  that does that really cool. One, two, one, eight, one, two, three. All right, this time.  Second time lucky. Whoa, yes! Oh, it worked. So all I've done there is process a charge.  So if we jump onto our website and we visit the dashboard again, we're refresh, I guess.  See this? Today, $20. There it is. Straight in. Now, Stripe operates on a seven-day rolling  payout basis, so you'll only get paid on a rolling seven days to make sure the fund's  clear and to make sure that they're not charged back or the customer doesn't want any more,  etc., etc. But you see everything instantly. So the next thing I kind of want to show you  is how recurring billing has been solved by Stripe. A lot of this is very similar. In fact,  you'll probably recognize that script tag. But what I'm doing here is I'm displaying  a page that lets the user change their plans. So if I have a SaaS application at the moment,  and I do, they can have a free account to start with or they can upgrade to paid plans.  And so what this one does is it says, hey, if I've already collected this Stripe information,  just go and click a button because I don't need them to do anything. But if they haven't,  go and render out me a Stripe checkout form. I put my public key in, which is the publishable  key. I put in a bunch of other details. Probably the only important thing there is that I can  also pre-fill that email address if I already know it. On the server side, all I'm doing  is I'm saying, okay, once the user has given me the Stripe token, so they've filled out  Stripe checkout, or maybe they haven't. Maybe I've captured it from last time. I'm going  to plug in a new Stripe customer options. Now, this is a little bit different to a charge  because a charge can only be done once. Once you take a token and you create a charge with  it, that token is invalid after that. So what you need to do is create a customer record.  A customer record basically just turns that token into a customer ID. It stores it in  Stripe. And then you can go and charge that customer over and over and over and over.  It's up to you to behave because you can do any amount at any time.  So what I've done here, though, for recurring billing, because you can optionally just charge  them when you want. So if you have your own scheduling service and your own sort of way  of billing them, you can just do it manually and execute payments. But the easy way is  to set up plans with Stripe. And all I'm doing here at the top there is passing in the ID  of that plan. And then the rest is pretty normal. We've given them an email address.  We've given the payment plan a bit of a description. We're passing in the token we get just from  Stripe checkout. We fire up a new Stripe customer service, given our secret key. We then receive  a customer object, which is down here. We've got a customer ID that we can store in our  system. And that's so that we can just use that ID to then process them in future. And  in future, this is the only thing you need to do to change their plan. So if they've  already typed in all their details, you already have the customer around, and you just want  to swap them from $20 to $50 or something like that, you just change the ID, submit  that. It's that simple. And what I want to do is just briefly show you what that looks  like. So again, here we go. We have a demo portal. I'm not sure how well this is going  to be seen. But essentially, we have a demo portal in one of my products. And we have  a demo portal. They're on the free plan at the moment. And I want to get them up to,  let's say, $30 a month. So you might recognize here, we've got a couple of blue buttons.  They look pretty familiar. We'll try one of these. Select plan. Here it comes up with  my email address prefilled. I can go and use the magic number. Oh, that's not the magic  number. That's the magic number. And again, this is a test system. So it's using my test  keys. And we'll go and update this particular person to the $39 plan. That'll go through.  And when it's done, that's it. All the customer had to do was put in their credit card details.  I now have that for future. So I can go and edit that. So there we go. The first time you're  charged, so if I was on a free plan and then I go to a paid plan, it's going to execute  a payment straight away. It's going to say, do you have that $39? I think it was. It's  going to say, yes, you do. I'm going to charge the card now. And I'm going to save your details  for later. And then next month, I'll go and charge you again. But if you've already got  a Stripe customer ID and they've already paid for a plan and you're just swapping plans,  it's not going to charge you till the end of the month. So be careful of that, actually.  If you have a really cheap plan and you put your user in a really expensive plan and they  cancel their card, it's only going to try and charge them at the end of the month. So  don't offer up your functionality if that's the case. But I think for the most part, it  should be fine. So let's go check out what that looks like. So if we go into our customers...  Oh, no, it's a connected account, so we won't see that. Oh, that's a shame. Right. So because  it's... Yeah, there's some details here which mean I can't show you the customers. But essentially  what we can do now, if we jump back to our dashboard, we go back to upgrade plan. I'm  just using the same code I showed you just before on those slides. You'll see now that  the current plan is selected there and in the back end, all it's doing is swapping the  ID and it's going to charge me correctly. And we'll just let that one go through. Beautiful.  Okay. The second thing I wanted to show you is the custom forms. You don't have to use  StripeCheck out if you don't want to. You can have any old payment form and you can connect  StripeJS and it will go and scoop out the credit card details before they can be submitted  and then it's going to pump them up to Stripe and your system won't see those credit card  details. And so that looks like this. It's a bit weird on this screen, but essentially  we have an invoice. This is just custom bootstrap form. It's just text boxes. There's nothing  special here, but in the background, what you'll see, if we click on this, we'll see  data stripe number. And that data stripe number is just telling StripeJS, hey, this is the  credit card number. There's an attribute on every single one of those text boxes telling  Stripe which one it is so that automatically when you hit submit, it's going to scoop up  that data for you. So if we use the magic number again, one, two, three, four, five,  six, seven, eight, we put in any future date and we put in any name. Let's go to test.  We can proceed with that payment. That's just a regular submit button and all it's going  to do is it's going to send that data to Stripe, come back and then successfully process it.  And it should be in test mode. I hope that's in test mode. Anything, anything, let's just  change the month and we'll say something like that. All right. Let's go. And sometimes,  if you haven't upgraded your VMs to a stronger one, there we go. Thank you for your payment.  There we go. So a custom form and Stripe checkout, super simple. There's not much code there.  It's just a few attributes and that's all you need to do. So I wouldn't work for Adam  Kogan if I didn't have a few suggestions for Stripe and all the others. Number one, PayPal.  I'd really love a JavaScript library for tokenizing credit cards because at the moment, you can  only be redirected. You can only have your credit card data on the server. You've got  to comply with a bunch of stuff. It would be great if you had a JavaScript library to  tokenize credit cards. Braintree. I would love it if your marketplace or being able  to automatically sign up customers and charge on behalf of other people was outside the US.  Now with Stripe, I know that Norway is on beta at the moment and so you can get in there  and actually do everything that I've shown today right now. It'll work. The beta just  means that not all of the features, especially the Stripe marketplace, is going to work.  Stripe, the last time I gave this talk, I wanted you to remember details across the internet  because I thought you were excellent. I would really love that functionality that PayPal  provides where you need to sign up once and you get it forever. But they've done that.  They actually did that in the last, within the last six months essentially. So I have  a new suggestion. I would love to see a whole heap of that UI gold that you provide in Stripe  Checkout and other places for signing up clients. Some sort of automated process for getting  clients on board with a nice shiny UI. We've taken a look at skykelec.com today. This is  the product that I made with custom payment forms. It's got Checkout and Connect. And  the reason I bring this up is because if any of you have questions about how any of the  Stripe stuff works, this is the proof that I can get it done pretty quickly. And I'm  super happy to take any questions or any, if you ever get stuck trying to implement  anything, I'm quite happy to help you out. I'd just like to say thank you. You can contact  me at Ben Who Likes Beer. You can check out my blog. Otherwise, have a great day.  Yes. Sorry? Yes, questions. Happy to take questions. Right. So the question was what  about refunds? Can you do that through Stripe? Yes, you can actually. They have a very good  refund API. You can also do it through the web interface if you sort of need to look  up customer details a bit easier. So if a customer says, hey, why was I charged this?  You can jump onto the Stripe dashboard, look up the customer information, find the charge  and go, oh, yes, I'm very sorry. That shouldn't have happened. One click and the whole thing  is refunded automatically. Now, you might say, okay, then how does your system know  about that? There's a whole world of web hooks out there. So Stripe will pump down information  about everything that happens within Stripe. And you can just put one endpoint in and then  read that information out and react to what happens. And this is the same thing that happens  for if a customer sort of cancels outside of your system or a card is declined on a monthly  transaction or anything like that or if they change their location or something like that,  you can be notified through that web hook system. Beautiful. Any other questions? Yes,  over here. How does the customer know that they can trust  your payment? Because if you're redirected to PayPal, even if you come from some sort  of place, you don't know that this is safe because you look down at your card, PayPal,  HGT, TPS and like everything, it just pops up a window in the middle of the web page.  And the credit card number, I never got the market. Excellent. So the question was, how  can you trust Stripe or how does the customer know that they can trust your website because  you can put whatever form you want there? Now, that's actually up to you to build that  trust. At the moment on the internet, there's tons of credit card information that people  put in every day and it's just dodgy implementations. So you're right. The whole idea is that you  can use Stripe's branding, which isn't very familiar, or you can roll your own and try  and make the process as seamless as possible. But it's really up to you. You've got to try  and sort of build that trust yourself. But you're right. It doesn't have the brand familiarity  that PayPal does. Any other questions? No? Very good. If anyone wants to come up and  chat to me about beers, I've got a couple of bottle openers to give away as well. And  I've got a few stickers. I don't know if you like these. Again, if you're just nice to  companies and you say, hey, I'd really like some stuff, they'll give it to you. So if  anyone wants a sticker, they can come up and grab it as well. But apart from that, have  an excellent NDC and I'll catch you guys later.  Yeah, be my guest. Stand here.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.
Taking_other_peoples_money__A_guide_to_online_0_2735.png Taking_other_peoples_money__A_guide_to_online_2736_4295.png Taking_other_peoples_money__A_guide_to_online_4296_11171.png Taking_other_peoples_money__A_guide_to_online_11172_11591.png Taking_other_peoples_money__A_guide_to_online_11592_12599.png Taking_other_peoples_money__A_guide_to_online_12600_13775.png Taking_other_peoples_money__A_guide_to_online_13776_13979.png Taking_other_peoples_money__A_guide_to_online_13980_15023.png Taking_other_peoples_money__A_guide_to_online_15024_16163.png Taking_other_peoples_money__A_guide_to_online_16164_16823.png Taking_other_peoples_money__A_guide_to_online_16824_19151.png Taking_other_peoples_money__A_guide_to_online_19152_19907.png Taking_other_peoples_money__A_guide_to_online_19908_23639.png Taking_other_peoples_money__A_guide_to_online_23640_25787.png Taking_other_peoples_money__A_guide_to_online_25788_32903.png Taking_other_peoples_money__A_guide_to_online_32904_33491.png Taking_other_peoples_money__A_guide_to_online_33492_34799.png Taking_other_peoples_money__A_guide_to_online_34800_36299.png Taking_other_peoples_money__A_guide_to_online_36300_36419.png Taking_other_peoples_money__A_guide_to_online_36420_36467.png Taking_other_peoples_money__A_guide_to_online_36468_36527.png Taking_other_peoples_money__A_guide_to_online_36528_37367.png Taking_other_peoples_money__A_guide_to_online_37368_37535.png Taking_other_peoples_money__A_guide_to_online_37536_37835.png Taking_other_peoples_money__A_guide_to_online_37836_37895.png Taking_other_peoples_money__A_guide_to_online_37896_38015.png Taking_other_peoples_money__A_guide_to_online_38016_38111.png Taking_other_peoples_money__A_guide_to_online_38112_38219.png Taking_other_peoples_money__A_guide_to_online_38220_39971.png Taking_other_peoples_money__A_guide_to_online_39972_41075.png Taking_other_peoples_money__A_guide_to_online_41076_41291.png Taking_other_peoples_money__A_guide_to_online_41292_41783.png Taking_other_peoples_money__A_guide_to_online_41784_43079.png Taking_other_peoples_money__A_guide_to_online_43080_43163.png Taking_other_peoples_money__A_guide_to_online_43164_44639.png Taking_other_peoples_money__A_guide_to_online_44640_44699.png Taking_other_peoples_money__A_guide_to_online_44700_44855.png Taking_other_peoples_money__A_guide_to_online_44856_45011.png Taking_other_peoples_money__A_guide_to_online_45012_45059.png Taking_other_peoples_money__A_guide_to_online_45060_45167.png Taking_other_peoples_money__A_guide_to_online_45168_45803.png Taking_other_peoples_money__A_guide_to_online_45804_47819.png Taking_other_peoples_money__A_guide_to_online_47820_47879.png Taking_other_peoples_money__A_guide_to_online_47880_48683.png Taking_other_peoples_money__A_guide_to_online_48684_52595.png Taking_other_peoples_money__A_guide_to_online_52596_55499.png Taking_other_peoples_money__A_guide_to_online_55500_58103.png Taking_other_peoples_money__A_guide_to_online_58104_58643.png Taking_other_peoples_money__A_guide_to_online_58644_59015.png Taking_other_peoples_money__A_guide_to_online_59016_59183.png Taking_other_peoples_money__A_guide_to_online_59184_59855.png Taking_other_peoples_money__A_guide_to_online_59856_59927.png Taking_other_peoples_money__A_guide_to_online_59928_59975.png Taking_other_peoples_money__A_guide_to_online_59976_60035.png Taking_other_peoples_money__A_guide_to_online_60036_60407.png Taking_other_peoples_money__A_guide_to_online_60408_60455.png Taking_other_peoples_money__A_guide_to_online_60456_60743.png Taking_other_peoples_money__A_guide_to_online_60744_60803.png Taking_other_peoples_money__A_guide_to_online_60804_61619.png Taking_other_peoples_money__A_guide_to_online_61620_61679.png Taking_other_peoples_money__A_guide_to_online_61680_63107.png Taking_other_peoples_money__A_guide_to_online_63108_65447.png Taking_other_peoples_money__A_guide_to_online_65448_65867.png Taking_other_peoples_money__A_guide_to_online_65868_65987.png Taking_other_peoples_money__A_guide_to_online_65988_66035.png Taking_other_peoples_money__A_guide_to_online_66036_66383.png Taking_other_peoples_money__A_guide_to_online_66384_66491.png Taking_other_peoples_money__A_guide_to_online_66492_67007.png Taking_other_peoples_money__A_guide_to_online_67008_69299.png Taking_other_peoples_money__A_guide_to_online_69300_70307.png Taking_other_peoples_money__A_guide_to_online_70308_70415.png Taking_other_peoples_money__A_guide_to_online_70416_70667.png Taking_other_peoples_money__A_guide_to_online_70668_71111.png Taking_other_peoples_money__A_guide_to_online_71112_71795.png Taking_other_peoples_money__A_guide_to_online_71796_72707.png Taking_other_peoples_money__A_guide_to_online_72708_75203.png Taking_other_peoples_money__A_guide_to_online_75204_75863.png Taking_other_peoples_money__A_guide_to_online_75864_75935.png Taking_other_peoples_money__A_guide_to_online_75936_76055.png Taking_other_peoples_money__A_guide_to_online_76056_76235.png Taking_other_peoples_money__A_guide_to_online_76236_77003.png Taking_other_peoples_money__A_guide_to_online_77004_80255.png Taking_other_peoples_money__A_guide_to_online_80256_80507.png Taking_other_peoples_money__A_guide_to_online_80508_84990.png