 How are you guys liking DrupalCon so far? Good, working good? Keep it on. So I'm here to talk about the payment API. And I have a tendency or habit of writing sort of complicated, flexible, super abstract APIs. And I often do talks about all the functionality and features and a lot of walkthroughs and demonstrations. And I really feel like that's not all that useful in the context of a DrupalCon presentation. So I'm going to take a different approach today. I'm going to actually talk about, take a big step back and think about how I kind of got to the place of designing an API and what it does in the context of how people use it and work with it. So for those of you looking for like a really nitty-gritty, hands-done demonstration of the payment API, this isn't the place. But there is a bof in the next session in room 504. So I'll be happy to talk through that stuff then. The payment API is not part of DrupalCommerce. It's a completely separate thing with a completely different set of goals that I'll talk through today. So if you are expecting DrupalCommerce to ask a demonstration, then this probably isn't the place for you. And you guys are welcome to check out other sessions, totally not offended. Those of you who are just kind of curious and want to figure out what this is all about, I hope you guys enjoy this talk. So I've got a lot to talk about and a lot on my mind. But the most important thing right now is that I love Drupal. And I've been working with Drupal for, I don't know, probably eight years. And I've been, I was at the first DrupalCon in Antwerp. I've been around. And I just love so many aspects of it. The biggest part is that before I came to Drupal, this was me. And I, like many people, ran a web development shop. And like most people running web development shops, I wrote a lot of code. And when people had needs or requirements or things they wanted to get done, it meant that I would have to spend a day, 10 days, 10 weeks writing a piece of functionality. And so I mean, just the idea of getting anything done was soul-crushingly slow because I'm just writing everything from scratch. This is my office today. These people do not write code, but they do work with Drupal every single day. They're community wind experts. They're publishing experts. They work in the entertainment industry. They help people build sites. They do e-commerce. They do all these things. But none of them write any code at all. And that's what I love the most about Drupal is that people who actually have something important and useful to say or get done on the internet are capable of using available tools. And they're able to draw from each other and stuff. So my role went from just sort of being code monkey to helping people actually get a lot of stuff done. That's what makes Drupal so fantastic. And of course, you've seen this slide probably at 50% of the presentations you've attended. You're never alone. And so a great example is anything that you've ever wanted to do or tried to do, someone else probably has done it or tried to do it or can't explain why it's a bad idea or can't explain how to do it better. And that's another great thing that's just fantastic about the Drupal community. We had an experience the other day where a customer was like, I think it's impossible for a database-driven website to withstand any type of traffic. It all has to be static. And we were able to say, well, it worked for the Emmys and here's a really great write-up for how it was done. And so we're all able to kind of share and enjoy and build on existing solutions to get a lot farther, a lot faster. And that's what I love about Drupal. So it also makes it a really good e-commerce platform for all of these reasons. Here's a e-commerce page that I think was actually built with the commerce module. And what's interesting is that the act of making an e-commerce transaction involves this, involves a little shopping cart and some money and a transaction occurs. But really the act of commerce, the act of people making deals and exchanges on the internet or elsewhere is all this other stuff. You've got some kind of media module, you've got image integration, you've got slideshows presenting the project, the product. You've got recommendations or examples of other things that somebody might buy. You've got probably the flag module, something where you're creating wish lists. You've got favorite stores. You can flag different organizations as relevant or meaningful to you as a visitor. You can share it over Twitter or Facebook or whatever you wanna do. And you can fully describe and enrich the product and make it meaningful to other people. So the reason that Drupal makes a great e-commerce platform is not because you can effect a transaction. Heck, if there was no commerce module, if there was no e-commerce module, Uber, cart or pay, you could still have a really great e-commerce website by presenting your products beautifully with Drupal and then posting your phone number and saying, call if you wanna buy it. That's a great e-commerce website because it's really about the act of sharing information, building your product, building your case and explaining things to people and why they should be meaningful and relevant for them to buy from you. And that is what Drupal is really good at. And we can benefit from all those different modules and tools to get there. So change gears a little bit. This is who I see basically every day. This is Marianne, she is a site builder. She works with us, she was probably in that other picture. And our job is to kind of help her work with her customers and build Drupal sites every day. She does an array code, but she has great theming and she responds to her client's needs using Drupal because of all of these tools that are available to her. If you've ever been to a Twin Cities user group meeting you've probably met her. She's just a great lady. But so she works with clients of a certain size building sites of a certain size. And I often like to think about building a site or building an e-commerce site or any type of site in the same way that I like to think about vehicles. The site should be a vehicle to get you where you are going. The customers of the sites, they wanna post stuff and have people buy it or have people look at it or do stuff. Their main motivation is not to worry about the vehicle. They don't wanna know what's under the hood. They don't wanna change the oil. Just like a commuter that doesn't think about all this all the time, a site owner doesn't really wanna be hassled with how the sausage is made. They just wanna get on the road, get where they're going and have done with it. So Mary Ann's job is to help her clients get up and running and build their sites however they need them to build. And when they make a request, she's got certain jobs to do. First of all, she wants that vehicle to go fast. She wants, if a customer says we need this up by next Friday, she needs to be able to deliver a tool, a project, a webpage, a marketing newsletter, whatever, quickly. And she needs to be able to say yes because that's her job. She also wants to use, have a selection of sort of usable components. Like she wants to be able to choose from stuff that already exists. I mean, just like I had to wait three weeks to build one feature back when I was writing PHP. She doesn't wanna have to wait, you know, a whole bunch of time to write or lean on someone else to write things. She wants just a suite of vehicles at her disposal that she can choose and apply to help in getting her customers on the road. But she's also gonna be here tomorrow. They're gonna call up tomorrow. They're gonna have another request. They're gonna wanna upgrade their site to Drupal 8 or 9 or 26. And what she doesn't wanna do is maintain kind of a piece together thing that's difficult to maintain, difficult to support and upgrade sort of built from a bunch of kind of wonky components. So Mary Ann's goals are to find things that work really well, work well together and not have like a lot of problems going down the path. So the first thing she does whenever she needs to do something new is she goes to the Drupal module page and she quickly discovers that there's a lot of choices out there. And of course, I mean, this is the other obligatory slide. Every single presenter needs to say that Drupal is just like a big bag of Legos and we kind of assemble or build them all together into forming different solutions. And we talk about how great that is. We talk about how frustrating it is. But I also think it's sort of a mischaracterization because Legos are rather homogenous and you kind of take a whole bunch and you build them into a wall or the side of a castle or whatever. I like to think of really modules as tools. That's what they are. And each tool serves a discrete and meaningful purpose. They do it in different ways. They're good for different things. And you kind of have, you go to that modules page and you've got 9,000 tools at your disposal. And so there's a couple of different type of tools. That someone like Marianne can take advantage of. And the first type is gonna be with single purpose modules. So there's just gonna be a whole bunch of modules out there that do one thing and do it hopefully well. Great examples are like the URL alias module. That's what it does or the path auto module, I'm sorry. And there's no reason to have a lot of extra functionality built into it. It does one thing and sees it to understand and easy to support and easy to upgrade from version to version. Other modules sometimes run into the limitation of if they're too narrow or too specific to a tiny use case, then they don't get to have a huge user base. And so maybe it does one little tiny thing for one odd group of people. And when group seven or eight comes out, it's not upgraded. And so you kind of want a tool that works well for a lot of people. So sometimes you start adding functionality to it. And then it sort of becomes a multi-tool module where you've got a module that's doing, not just one job, but multiple jobs. It's interesting, Jeff Eaton's talk yesterday brought up the image module. It was exactly what I was gonna bring up. Back in the day, we used to use the image module because we wanted to put an image on a website or create an image node. And then it needed to be resized to have different thumbnails. So it got that functionality built into it. And then it needed to, we wanted to have different sizes in a gallery and then we wanted to import it from file systems. And so that module got sort of taller and taller functionality, which is still okay. It's still not necessarily a bad thing because maybe everybody who wants images wants all that functionality. It's still kind of, you only have to deal with one module and one maintainer and you don't have to worry as much about an upgrade path. So it's not necessarily a bad thing to do. But it can get sort of brittle to maintain because what if you don't want your image thumbnails to be exactly this way or what if you want to do something differently? You're, you know, and you can have the module maintainer has to just sort of build in a whole bunch of extra kind of wonky use cases to a particular tool. This also makes upgrades really time consuming because you have to upgrade all of that functionality all at once just to get to the next level. And this is also a big risk is that, you know, you can just stack too much stuff onto to one module. So the other kind of module, the different three different types are, you know, frameworks. And this is kind of what the image module sort of got supplanted by which was you've got the image field module and the file field module and the image cache module and I don't know views and a whole bunch of other stuff. And each one kind of does its discreet piece of the puzzle. And then you can kind of plug in and change out the different parts as you need to. This is a, I think a really great way to work it as long as it doesn't become too complicated because of course you've got different people working on different pieces of the puzzle and you can increase your leverage. So instead of one developer maintaining 10 aspects of a single module, you've got maybe 10 developers working on 10 aspects of the same problem space. And those are interchangeable. So, you know, the framework modules can be really handy but they can also, it always made me a little queasy before Drupal 7 to explain to a new user, no, don't use the image module, that makes sense. Use the seven other modules and assemble them together and invest two hours of your time and then you'll have the image module. So there's kind of different ends of the spectrum to how useful that is. Which is best, it really doesn't, it really, it's not clear. I mean, because I mean sometimes what you need is just a screwdriver, you just need to do one thing and do it really well. And sometimes you wanna break out the problem space and work on different aspects of it. So, you know, I took all this back to, you know, to heart and started thinking about what that means in terms of developing a module and I've been working on the payment APIs since 2006. It's gone through multiple incarnations. Really it was only viable for people to use in 2006 because I tried kinda slicing and dicing it in different ways. Is it a multi-tool module? Is it a single purpose module? Is it a framework? And so, because we work with so many people I had a really good pool of people to talk to. Like I said, our company does support and sort of hands on training and facilitation. We don't actually build websites. So, we have exposure to a ton of different people. And we kinda ask them questions about what are you trying to do? And what often happens is someone, a lot of nonprofits will say, I want somebody to just come and make a donation on our website. And other organizations, and I don't wanna cart and say I just wanna make a donation on our website. Other folks are like, we have these events and we've always had them be free. Us, for example, we have training events on our site. And we want people to sign up for them. Well, there's already a module for that. You can sign up. Yeah, but I want people to be able to pay but only sometimes, right? So, we wanna be able to take something that already works well and add functionality. A lot of other people are like, we want to accept arbitrary information from the internet. People fill out surveys or apply for something. And we're like, hey, I have a great idea. You should use the web form module. And they're like, yeah, but can they donate on the web form module? Or can we use the web form to capture an event sign up and include meal preference and everything else but also get them to pay online? And so, we kept hearing these conversations go back and forth. And the word that never, ever came up was cart. In fact, if there was a cart involved, it was offensive. Like, we're not a commerce agency. We don't want people to, we don't wanna come off as overly commercial. We want people to just naturally be just flowing through their sites, doing their thing, adding information, viewing information, flagging stuff, sending stuff via email and occasionally buying stuff on top of it. So, this is kind of the chart I ended up drawing is that something happens and it could be anything. But at some point, we all decide that this person wants to give our organization or company X amount of money. And so, we wanna process that. We want that to happen. And then we want to record it and let that process kind of continue going on its way. So, what we never really wanted to be involved in is what happens to generate that transaction. There's plenty of modules out there in the Drupal Sphere, you know, collecting user needs and facilitation. Like I said, there's web form. If they wanna submit a form, there's signup if they wanna sign up for an event. There's, you know, all kinds of flags. If they wanna register for a site, they can certainly just use a registration module. And so, we don't really wanna be involved in the business rules of how that goes down because that's just too much work for one developer. But what we do wanna do is consistently be aware of how much people want to pay us and we want to record that and we want to make that transaction. So, I wrote the payment API. After several attempts, I got it to a good place. It has zero dependencies. It's very lightweight to a certain extent. It builds on other modules. So, if you just download and install the payment API, you don't get anything that is useful. But what you can do is you can install other modules that allow you to make payment, or you could write another module that allow you to make payment against arbitrary forms throughout your site. It does have a means of abstracting itself to have pluggable payment methods so that if you want to interact with authorized.net, there's literally hundreds of payment backends. And so, it'd be awfully silly for us to try to support that so you can write that functionality as well. And then it does maintain detailed transaction records. So, we tried at some point to do sort of like, we're just going to pass this to a gateway and not really record what happens. We're just going to record yes or no. But the problem is that maybe you want to have multiple payments against a particular transaction. So, if you want to ship part of something and accept payment for that, or what if you want to pledge $100 but not actually pay for it right away? You just want to record that pledge. So, we do actually maintain a pretty complete history of what happens to a particular payment transaction. But we don't make a lot of judgments about how that transaction came into being. So, this is basically kind of how it looks. Each of those boxes to be right into the left are or could be different modules. And so, you would write as a developer, you would write one of two types of modules. You would write a payment form module. And so, Nate Howe wrote the web form pay module to be able to have kind of any type of payment activity on top of a web form. We wrote a dirt simple really lightweight donate module which if you just want to be like, how much do you want to donate? Great, here's your credit card form. You can install that. We'd like to see more stuff happening in the signup space, user registration, that kind of stuff. And I'd love to see a tip jar module, all kinds of other stuff. But those modules can be written by other people. And the payment methods certainly are the same kind of thing you've got. Those modules exist, the authorize net pay cow, relic, secure pay. And we of course like to be adding multiple of those. And so the Payment API just sort of sits in the middle and allows one set of modules to decide why a payment is occurring. And another set of modules to make sure it happens on the back end. So this is for example, a donate form. It's very simple. We do the donate module allows you to kind of just generate some arbitrary dollar amounts where you can click on other amount and it opens up a little type in the amount thing. Then it happens on one page. Drupal commerce is very different, but in Drupal six. This page was like a nightmare to do with Uber cart because we'd have to install and configure Uber cart to completion and then install and configure a bunch of other modules to hide and strip away the cart things. There was no way to just have a page that makes a donation happen. And so this in Drupal six was a godsend because it kept people who just wanted to, just like this is 100% of what we wanna do with commerce on our entire infrastructure allowed us to install two modules and have done with it. The other thing that we really like about it is that I wrote a node payment. So I associate payment forms with particular nodes. And so this is an event page that, or it's actually a series of events. So each of those are little events that are happening in the series is a collection of those events, the Latin music. And there's this little donation form up in the corner that knows that it's attached to that particular program node. And so I really like that because I think that it's false to assume that if we just make our donate buttons bigger and bigger on nonprofit sites that people will be more likely to click on them. I think you have to build a case. And I think it's important to have the donate stuff in context with the content. So look at our great organization. We've got these really great Latin music festivals. Oh, hey, you wanna support this Latin music festival. And so, and then clicking on that gets you to a kind of the same donate form actually, but it's a little bit branded. And we can do some reporting on, hey, people, you know, the money goes in the same bucket, but we actually know that most of the money comes in from the Musica Latina Festival and not from the Global Roots Festival, for example. So it's a neat way to just sort of like be a little bit pervasive and in line with what the organization is trying to do and what users on the site are trying to do without getting too involved in the e-commerce stuff. So I'd love to see more things happening in the payment form space. It's actually really simple to write a payment form integration module. And we can talk about that in the buff in the next hour if you're interested, I'd love that. Otherwise you can email us, teamadadvantagelabs.com. In terms of developers, there are specific hooks. Everybody likes hooks. This is how you get a payment form into another form. And so basically what payment API is, more than anything, is a really heavy duty form alter hook. So you can actually just use those two lines of code to go load up a form and embed it in any other form. So if you wanna embed a donation form into the contact us page, great idea, you could just do that or you could embed a payment form on the comment form and boy, that would stop your spam. And so I designed it to be a really simple way to just sort of plot payment this into whatever arbitrary functionality you want to include it in. And then in Drupal 7, I'm taking it a step farther and the entire payment form can actually be instead of the payment node module that I was just showing you is a field. So you could add a payment form field to user registrations or to any type of entity that you would want. So you could have somebody pay to create a node, which would be great for certain applications. So super flexible in that regard. The process of creating a payment method module is really simple. We just have, it's all object oriented. So we've got a base class for payment methods or a base class even for payment methods that use a gateway like AuthorizeNet or something that uses one of those HTTP gateways. And so you would just sort of write a little hook pay method handler info to assert that you have a module or a payment method called pie in the sky that it's extending the pay method gateway. And then it would exist and users could select it when they're configuring their site. And you can just go ahead and extend whatever you need to extend to make it work with your backend. Hook pay form handler, that's the other side, that's the web form pay or the sign up or things like that. If you were using this little form alter just on your own site for your own special use case that's completely independent from this, but if you wanted to actually write and distribute a Drupal module that implements a payment form, you would just implement that hook. And outside of that functionality is actions and triggers. You can sit on activities that come along. We do actually record because we did kind of write this, tailor this for donation functionality. We do actually record what a goal amount for a particular form might be. So you could do like funding goals and things like that. And so it'll launch out little actions and triggers as those goals are reached or as certain deadlines close. So it's actually pretty flexible to configure both from a developer's perspective, a coder's perspective and from a site builder's perspective. I was thinking about Marianne. It's got full view support. So like I was saying before, is that it maintains an awareness of all the transactions that have occurred, all the activities that have occurred on those transactions who's making the transactions. And you can build up reports and forms pretty much any way you need to. This one is on a particular node. And in fact, the node it's on is this one, which is in fact, you know, a Kickstarter style microfunding thing. And it works just like Kickstarter because the authorize.net payment method does, it'll collect and store via authorize.net, the payment credit card information and then we can actually effect a transaction to capture payment if the project is successful. So people can pledge against a particular payment campaign. And then if that's successful, then we can go back and collect the money. If it's not successful, we don't collect the money. So that's totally possible with this. And then it's got all the view support back into it. And the modules that we include just in the payment API are like the payment field or the payment node, kind of making that transition. And then the progress indicator for that goal amount. And then other people have written, like so Stella Power has written, both a payment backend and she's written a Google Analytics API or module for the API and hopefully other people write other stuff as it goes. So we just want to sit in the middle of this little ecosystem of people thinking about different use cases for writing payment forms and people thinking about payment backends that they want to use. And we just kind of want to sit in there and kind of leverage both sides of that work. I really, I've been like worried about this presentation actually because I'm worried about like a versus attitude or like, you know, I just think there's just bad blood is not good for anybody. And it shouldn't really be, and we to be honest use Drupal commerce a lot and we recommended a lot. And the reason we do is when we start hearing people say, we need a cart, we need product management, we need, you know, we need rules, we need all like absolutely, right? That's exactly the right place to be with that stuff. Or if you have multiple pieces of functionality that, you know, might benefit from having all the flexibility of Drupal commerce. I like to think of a module like that going back to the earlier slides as like a multi-tool or even like a multi-tool made out of frameworks. And that's really great if you're gonna use that functionality, but it's like renting a U-Haul to carry a letter to your friend. It doesn't always make sense. If you're renting a U-Haul to move out of your apartment then that makes a ton of sense. So just sort of kind of thinking about short and long-term needs. One of my big hopes would be to, my sort of plans is to try to write a payment form module for Drupal commerce so you don't really have to choose. You could implement, hey, we just want a simple donation or we wanna sell a hat. And you might implement that functionality using the payment API. And then you say, oh, we had it all wrong, we need a cart, we need all the stuff. And you could install the Drupal commerce module and be able to use the payment API and all the configuration for it to make that transaction and keep all your records in one place. And so that's something that I'd like to see in the future is sort of playing all together and working in harmony rather than having it have to be an either or it should be a both and kind of solution. So it's sort of like alpha, beta and Drupal seven. But it is working and a lot of people are using it. We're certainly using it. And I do kind of hope for more people to just try to think of reasons to use it. Like I said, I have come too many Drupal cons and I presented at many Drupal cons talking through all the functionality without really explaining the rationale. So I'm hoping that explaining the rationale will help people understand where I'm trying to go with this. There's a buff in the next session in room 504. So if you're interested in understanding how to write a module or interested in whether or not it makes sense for you to work with this, we'll be happy to talk through it. We'd also love some help if people are interested in getting involved in terms of documentation, writing some modules, or even just like having a case study. Like, you know, here's how we use it, what we're doing with it. So I wanted to know if people had any questions. If you could talk to that, yeah. Actually, if you want to come up to the microphone, it's a race. Just wondering how or if you deal with PCI DSS, that all that e-commerce stuff that's now everyone's. Yeah, everybody's kind of worried about that. We've dealt with that to the extent we've had to. I mean, I know that sites that we're using it on have done well on PCI compliant stuff. I mean, we do transact everything over SSO. We don't store anything. And so we're doing that to the best of our ability, but yeah. I can't remember if you said that image at the slide that you had where the payment API was talking to authorize.net and PayPal and all of that. Yes. Was that included that communication or was that like a different module for PayPal that we would have to attach or talk to? Yeah, so there's a module called PayPal and there's a module called authorize.net. And then I think style of powers wrote another one for secure pay or there's an Australian for security. So those are all different modules that extend like a base class that's inside of the payment API. Okay, thanks. Sure. A nonprofit and as we get more of these payment sources, one of the worries or problems that's occurring now for us is once authorize.net settles, it goes into our bank account and we can't identify with the reporting as easy anymore. Have you experienced that or is there a solution that you know of that can make us help us track the settlements with the actual initial payment easier? Well, I mean, the having view support and the ability to use like export a CSV would be helpful, assuming that all of your transactions are going through the one Drupal site, right? Actually, there are multiple sources, like we have different donation forms from different websites. So we'd like to be able to identify those when it settles, but we're using the same gateway for both things like a Drupal site and that. I just don't know if there's a solution or if a bank can give. I know that authorize.net like has reporting on transactions that have gone through. And so the extent that good information is sent back to authorize.net. That's probably the best way to do it. Or like I said, you can compare the views, you know, what's in the Drupal site with, what's in the settlement reports. There's always weird stuff though that like the settlement happens at a specific time of day. And so a transaction that occurred at 555 and a transaction that occurred at 601 would be in two different batches. Do you have any suggestions on handling multi-tiered payment sites or multiple payment gateways on the same website? Yeah, so the payment API lets you set up multiple payment methods and those can actually have like for example authorize.net will allow you to store credentials separately for different instances of that payment method. I think that's the only one I did that for. But so that would allow you to have as many payment methods or many different authorize.net accounts as you want. And then each payment form is associated with one or more of those. So you could create multiple payment forms via web form or donations or something else. And then associate that with different different payment backend accounts. So the short answer is that's technically possible. So I feel like I kind of powered through that. But the bonus is a little bit more time in the hallway track if you want that. Or we can, like I said, I'm gonna make my way to the BOF session if you don't wanna like ask questions over a microphone. I'm totally happy to talk to you in the BOF or just at any time if you wanna flag me during the rest of the conference. So thanks for your time. Thanks for coming to my session.