 All right, for everybody that's here, this is Boyan Zavanovich from Commerce Guys, presenting Commerce Without Borders, and I just figured that he's not going to give himself a decent introduction, so I thought I would do it. He's the best Drupal developer ever in Serbia, and we've been really privileged to work with him since he rocked the Google Summer of Code a few years ago. Then he came into Commerce Guys and was the principal architect behind Commerce Kickstart 2.x, and he won't tell you that in a session because he's not here to to toot his own horn, but really good developer for us. He's passed that off to Jonathan Saksik, and now he's sort of engaged in a lot of marketplace and platform development within Commerce Guys, and I really respect him, and I look forward to hearing what he has to say about Commerce Without Borders. Thanks, Boyan. Thanks, Ryan. We can start. Welcome, and thank you for choosing this session. I'm Boyan Zavanovich. I'm BoyanZionDrupal.org, and I'm a developer from Serbia. I spend most of my Drupal time in contrib and have worked on projects such as the Drupals having port of views, views bulk operations in line entity form, some other modules. But most importantly, I work on Drupal Commerce and its many contrips. So in the previous year, I did two great things. The first one was leading the development of Commerce Kickstart V2, and the second one was growing a beard, and both have been a great success with the target audiences. So when it comes to Drupal, I have two big passions, and the first one is distributions and just pushing the limits on what the distribution can do and the amount of flexibility it can provide, and the second one is solving hard problems with Commerce, and we have plenty of those, and we'll see some of them in this session. Quick word about my employer, so I work for Commerce Guys. We are an awesome company behind Drupal Commerce and Commerce Kickstart. We also contributed significantly to Drupal 7 core, Drupal 8 core, many other contrips. We have about 60 people in three offices, so Paris, France, London, England, and Ann Arbor, Michigan. We are VC funded, and our business model revolves around making sure that you build something amazing with Drupal Commerce. So a quick show of hands. Who here has already built a production website using Drupal Commerce? Put your hand down, Ryan. Okay, good. So I'm going to give a brief introduction for those who still haven't. So Drupal Commerce is an e-commerce framework built natively on Drupal 7, using all of its core technologies. So if you like Drupal 7 and if you know Drupal 7, you will feel right at home with Drupal Commerce. We like to say that it's minimalistic and flexible, and in practice it means it is loosely coupled, allowing you to take only the parts that you need and ignoring the others. Building websites without cards, without checkouts, with custom implementations where needed, just it tries not to get in your way. And its flexibility lies in the fact that it makes no assumptions, which means that as you're building your project, you can think about the features that you need and not think about fighting commerce. And this has allowed us to build a huge range of solutions. So no matter whether you have a store that sells shipable products or books or subscriptions to an external service, or maybe doing event registrations, hotel registrations, donations, every single use case can be done. And it's interesting that a bit less than a year ago we had this big planning sprint for how we were going to do commerce on Drupal 8. So we had the space to re-evaluate every part and to fix anything that annoyed us. And during that time, during that week, the 10 of us could not find a single thing that is currently impossible with the current version of commerce. There was never a time where we said, this just cannot be done. And this is really a great testament to the flexibility in the architecture that was implemented by Ryan Serama and Damien Tuchel. So that's just amazing. And it allows sites such as Cartier to be done in an amazing way, implementing their own custom workflows while still using everything that we can provide. So we use views for all listings, which now feels natural, but was a bit experimental at the time. And it provides a lot of benefits, both on the back end and on the front end. It means that you can easily change any column, any data immediately from the UI. So you can customize the back end to suit your client's needs. If I need to change a column, I can edit the view in five seconds, I can add what I need, and I'm done. Same in the product catalog. If I need to add an additional field, two clicks, and it's there. Furthermore, views can use alternative back ends, which means that my results can come from another back end such as solar for increased performance, for faceted search, for full text search. And this is all done out of the box for us because we are leveraging this important technology. We use rules for all of our business logic, which means that you can respond to key events like you would to a hook and just plug in whatever business logic that you need and it works. And compared to a hook, there are many benefits here. You can edit a rule right from the UI and change its configuration. You can change the data that supplies to it. You can disable it if some kind of behavior needs to be turned off for a bit, or you can reorder the way the rules are executed. And we pass off all of our critical decisions through the rules engine allowing you to affect it. So when we need to select the right payment provider, we pass it through rules. When we need to select a tax rate, we pass it through rules. When we need to determine the correct product price, we pass it through rules. And this really allows you to easily handle many crazy use cases. So last night I learned that in the US, you have certain tax-free weekends. So that means on that weekend, your products have no tax. And that would be a pretty crazy thing to hard code into commerce. But with rules, you can easily add your own condition and respond to that and handle that use case and any other that can pop up. And that's really important. Of course, rules are exportable so you can still version them in your code and so on. And rules gets a bit of negativity for its UI, which is, of course, very generic. But it also allows you to build a nice UI on top, which we've proven with Commerce Discount, where we have our own completely custom and nice UI that actually generates a rule in the background. So even that is not a problem. Rules does not prevent us from making nice UIs. So, of course, commerce is minimal, but we also need our features that we are going to add to our website so we can finish our projects. And for that, we have the essential contribs or the golden contribs, as we like to call them, where the use case-specific features are located. So things such as shipping or stock control or selling access to files, it's all in those modules. And then you have additional modules that make front-end or back-end UI tweaks since they can assume a specific use case. So if we know that a module will be used on a shipping website, we can provide a better UI that accounts for that use case. So that way we keep the Commerce Core lean, maintainable and prevented from getting in your way, but at the same time give you the features that you need to actually move forward and successfully complete your project. Now, the problem here is that you suddenly have a big set of modules you need to install. There's commerce with all of its dependencies, there are the essential contribs, any other modules you might have found in the meantime, and then you need to configure your base theme, you need to just mesh it all together, and that takes time. So it can take days or even weeks for you to have something that you can demonstrate to your colleagues or your client or your future clients. And to handle that, Drupal has distributions, which allows us to package all that in an easy-to-use install profile in a complete download that has everything you need. So we can include all of the modules, the base theme, we can provide the initial configuration that will get you started, and we can even provide a full-features demo mode that has all of the features demonstrated, even the ones that you wouldn't normally configure so that you can use it to show off to a potential client or your colleagues or wherever you need to actually demonstrate the full functionality at your fingertips. And one such distribution is Commerce Kickstart, which we have built. So Commerce Kickstart has been released, well, the second version had been released about a year ago, and it has been a great success. Commerce Kickstart is currently the most popular Drupal distributions. It has about 8,000 installs, and just to put that into perspective, that is as much usage as the next 10 distributions combined. However, when you actually compare it to the number of total Drupal installations, that percentage is really small, which means that Drupal as a whole still has a lot of work to do to make distributions flexible enough and just approachable enough by new users so that they become the default option when starting a new website instead of just starting from scratch. In order to make Commerce more user-friendly, we have completely redesigned the Admin UI. So we have implemented an admin theme and an admin UI with the help of Buoy and Summers, and you can see many UI elements that have since then made it into Drupal 8, and my colleague Jonathan likes to joke that Drupal 8 looks more like a Kickstart than Drupal 7. So other than this theme, we have carefully chosen all of the filters, all of the data that should be shown to you. For instance, we see here an order listing that allows you to see the order summary right at the same page, and you can see what was bought, who bought it, where it was shipped to, and you can see all the latest communication with the client. So we gave the same treatment to every page that you interact with. We have a completely custom toolbar that gives you access to the most commonly needed e-commerce functions, and we have help on each page that allows you to go to a documentation page or see a video that will explain the key concepts behind such functionality, so you can learn as you go along, which once again makes Commerce much more approachable. Of course, nowadays, having a responsive Frontend theme is a requirement, so we have a Frontend theme that's based on Omega-3, and it's really nice to use. We provide our own base theme, you can extend, so you can inherit the stylings that we add as to the e-commerce elements, and it just works. Of course, in order to demonstrate what Kickstarter's can actually do, we implemented all of the product marketing features that you would usually implement on your own website, on your own project. So we have slideshows, we have image zooms, we styled all of the attributes, we added JavaScript, spinners, all kinds of eye candy that you usually implement on a project, and now it's there for you, so you don't need to hunt for that. We have chosen the best JS libraries, we have demonstrated how it should be integrated in the best way, and then you can just benefit from that. And of course, Search is a hugely important feature and especially for e-commerce websites. You need to have faceted search because that's the main way your customers will actually browse your product catalog. And here we rely on Search API, and we use the excellent commerce search API module that was developed by Jonathan that actually adjusts to your product types and your data structure. So as you define your product types, as you define your custom fields, the module will automatically create and maintain facets for them, allowing the whole thing to work automatically. And of course, it has really powerful full-text search as well. And since Search API has multiple backends, you can start using your database for the initial solution, and it will have no worse performance than the regular Drupal search, and then as soon as possible, you can install solar and move to that, and then gain a very big performance boost. So it's my general opinion that nowadays you should be using solar for all of your listings, front-end and back-end. And for us, we've just made the front-end listings work seamlessly with Search API. We also provide built-in payment gateways and third-party tools. So this means that when you install, you will select your country and we will try to select and install a payment gateway for you so that you are immediately ready to start selling. So we know which payment gateway works well in your country, and we have installed it and you are ready to configure it and just go ahead and start selling. And I will explain that later in more detail. And of course, the important thing is that we've built Kickstart so that it's a set of loosely coupled modules that you can install on your own website so you can use it on your existing site or maybe if you don't have a shipping site which Kickstart optimizes for, if you are selling files or events, you can still take the modules that you need and just mash them up and get the desired functionality. So even if you don't want to use Kickstart, you will benefit from all the work with it. But if you want to, it is a great tool for learning commerce best practices, for demonstrating what commerce can do and at the end of the day, for launching new stores quickly because you can really get up and running in a single day and just sell your product. So if Kickstart is so great, why don't we just stop here and go and have beer? I mean, we have everything we need and we can move forward. Unfortunately, it's not that easy because while we like to think of ourselves as the citizens of the internet, we actually aren't. And the country in which we do business provides its laws which give us a set of constraints and not only that, but the countries with which we do business with. So the countries we sell to will affect those constraints as well. So that means that many people who are approaching a new e-commerce platform, no matter if it's commerce or magento or something else, they bump into these problems unknowingly and they get really frustrated because they thought that software would solve their problems and it didn't. So at the end of the day, they're frustrated and they lost weeks more than they anticipated. So in this case, we will look at what those first problems are and how we can solve them using triple commerce. And our use case in this case is Czech startup and they're selling their first product. And let's say that the product is a deployment tool. It takes your code from GitHub and puts it on your server. And they're selling one time licenses. They want to do this with commerce kickstarts or any custom triple commerce solution. However, they also at one point want to switch to a subscription model. So it would be creative. They could build their customers on a monthly basis. Also to fill in the budget from time to time, they're also giving Git trainings. They're familiar with Git so they go to other companies, they provide the trainings and earn money that way. Sometimes they even go to other countries to do that, for instance, when they're at the conference. So those are, that is their main use case and that's what they need to be able to do and to do it quickly so that they can focus on their core competencies so they can focus on developing their product. And we start by gathering the requirements. What it is that they need on top of what kickstart gives them. So to start with, of course, they need multiple languages. At least they should have Czech and they should have English and in time they will add additional languages. So when I arrive at the website, I will have the UI in my language. I will see the products in my language and of course it should just work seamlessly. I also need prices in multiple currencies. So the Czech Republic has its Karunas but for user friendliness, we will probably also want to have Euro prices and one day dollar prices. And there are two ways you can do that. You can either enter your base price in Karunas, for instance, and then do automatic conversion or you can define completely separate prices which makes a lot more sense because then you're not tied to the exchange rate and you can actually have user friendly amounts displayed. So what I always do and what we do in our own projects is just define the prices separately and even if they're not exactly equivalent then select the right one and show it to the user. And so right away we see a potential problem. If we have two sets of prices, how are we going to decide which one we are going to show to our customer? And the main problem here is figuring out where our customers are coming from. So we need to have a reasonable guess at first. So default based on our domain if we have a store for friends, for instance, or based on the user's location, we need to allow the user to actually tell us. For instance, this website has a nice little selector in the header that allows me to change my country right away and it will change the taxes, the currencies, it will just adjust itself to me. So that's a great way of doing it and it doesn't require me to log in. So it will just save a cookie on my computer and it will work. And of course there are alternative solutions. So on our marketplace what we are doing is we are forcing you to register before checking out. So we always know what your country is because you've already told us. And that way we can always have the correct prices and everything because one of the problems is with actually refreshing the whole order during anonymous checkout. So if I came to your website and I didn't select anything and I'm checking out the product and suddenly I change my country to Serbia or France. You need to change the amount, change the currencies, change the taxes and you need to make it obvious to me as a customer that everything has changed. I'm no longer buying the same thing essentially. So it's pretty bad from a UX perspective. It can be done, it works in commerce but I would avoid doing it so late in the process. Ideally you want the user to tell you before he starts to checkout and you should have a reasonable guess that you can later adjust. We need to of course figure out which payment provider we are going to use and we currently have no clear set of guidelines on what the criteria is and how we are actually going to do that. So we need to explore that topic. And of course the one that causes us the most headaches is VAT. And you will see that if you pronounce it as one word it sounds like what? Because that's usually what your reaction is when you start exploring VAT. It's usually pretty hard. So let's see why. Of course VAT is inclusive tax. It's included in everything that you sell. So when if I'm selling something that costs eight euros it already has the VAT included. And at the end of the month I'm supposed to pay the VAT to my country. And you can see here an example of actually entering the prices without VAT and then showing the subtotal and the VAT amount. So let's dive into that. My first problem is what are my country's VAT rates? So if I haven't gone to an accountant yet I'm completely clueless about how this should work. I need to figure out which rates there are and every country has multiple rates. For example the Czech Republic has the normal rate of 21% but it also has a reduced rate of 14% for books and other things. And then it has items that are completely tax free. And every country has its own set of rates that are different and the number of those rates rise. So I need to have them all predefined in my system. I need to classify my products into those categories and then have the correct VAT actually selected and charged to my customer. In this case we still don't have shipping but we might decide we want to do some kind of merchandising maybe selling t-shirts with our company logo and in that case we need to ship something. So does shipping have VAT? In fact it does and our problem here is that if you have products with different VAT rates shipping needs to have the highest one. So you always need to select the highest rate in your cart otherwise it won't be correct. Do discounts have VAT? They do, unlike sales tax which is applied to pre-attacks in theory VAT discounts are always applied post-tax. So if you're applying a percentage, 10% tax you're discounting both the base price and the VAT. If you're applying a fixed discount it needs to have its own VAT component and that needs to work. VAT rates can change. So you know this woman, it's her friendly Angela and she thinks your country is spending too much and she thinks you're too much in debt. So she's going to pressure your country to get more money to increase its budget and countries usually do that by passing off the tax burden to us and they first start by raising VAT. It has happened multiple times in multiple European Union countries. So what happens if your country tells you that from January 1st the VAT rate is no longer 21%, it's 22%. Your system needs to handle this because otherwise at midnight, at New Year's Eve you need to sit in front of your computer. You need to make sure that there are no orders that are in progress and you need to make sure that immediately at midnight you change the rates to 22% so that any new orders are priced correctly and that's a bother. I really don't want to spend New Year's Eve in front of my laptop. So ideally we would have a system that would handle that. Not everyone pays them. So for instance, I am from Serbia and we are not in the European Union. If your customer is not from the European Union he should not have a VAT charge. So when we look at his location we need to know which countries are in the EU and based on that we need to not have the VAT applied in that case. Not everyone pays them in the case of B2B transactions as well. So if my company is selling to another company in the European Union, they are the ones who are paying VAT and my only job is noting how much they should have paid and selling it to my government. So in that case during checkout I need to ask the customer whether he has a VAT number and if he does his VAT needs to be removed because he is handling that. We also have the problem of place of supply which is a concept that exists in the European Union. So we are a Czech company and we provide our trainings and one day we are invited to go to Paris and do a gift training. Why not? And it sounds like fun. However, if we are giving that training in Paris our place of supply has changed and it is now France which means that the VAT that we need to charge is not the Czech one it is the French one. So that means that I need to know all of the French VAT rates. I need to know which ones apply to my product and I need to charge them instead based on where I'm actually providing my service. That can be kind of a problem. Then we have the troublemakers and I need to apologize to my colleague Björn here. It's not Sweden it's actually Switzerland but that's how it's turned out. So we have three countries that do things kind of differently. We have Switzerland, Norway and Iceland. And what they say is that if you're selling something to a Norwegian customer for instance you need to charge their VAT no matter what the place of supply is. So if my place of supply is the Czech Republic I'm selling it from Prague but my customer is from Norway the VAT rates needs to be the Norwegian one. And they are going to want that money. It also works in reverse. So if I'm a Norwegian company selling to the European Union I need to apply the appropriate EU tax. So now I need to know all of the rates for Norway and Iceland and Switzerland as well. And I need to know which ones apply to my product and this is becoming more and more annoying. My team has a simple motto which is we don't care about Norway. But the problem is you need to care about Norway. And at one point you need to start caring about Norway and you need to implement this. You cannot ignore the law when it suits you of course. And then we have trouble on the horizon and this is what people call woes and it's short for VAT on electronically supplied services. So this means that whenever you're selling something that's not physical. So for instance a file, an ebook, trainings whatever it is you have a special law that applies to you that says when you're selling the product the VAT is due at the place of the customer. This means that the VAT rates applied are from the customer's country. If I'm selling something, if I'm selling my training or my products to someone in Germany they will need to, I will need to charge the German VAT and same for Spain and same for Portugal. From 2015 this applies to everyone. This means that in our system we will need to have the VAT rates for the whole European Union. We need to maintain them, make sure they don't change and we just need to make sure this works. So I will give you a minute to panic now. Of course there is a solution. The first solution is just using an external service for tax calculation. If you go to a Magento page they will tell you, yeah just use an external service if you're bigger than, I don't know some predefined size and of course some people say that's to me in the Drupal world as well. They can just use an external service but if the laws are changing this way this means it affects everyone. It affects the two person company, it affects the thousand person company and if I need to pay for an external service just to have an e-commerce website then we have failed. I can pay for the complete solution, I don't need to mess around with open source at all. So I don't think that's a solution. We need to have a solution that actually works for us out of the box. So let's see how Drupal Commerce can actually help us with that. We are kind of depressed at this point but it gets better. So the first thing that Commerce allows us is to have a price field per currency. I mean we can have as many price fields as we want. So we go and we create separate price fields and we enter our prices without VAT which is very important. So Commerce has this dropdown that says include tax in this price and it is a big shotgun pointed at your feet. You cannot lift it up, you can only pull the trigger don't. You need to enter the price without VAT because once you select the VAT here it stays selected. If I selected the check one I cannot say oh for Boyan there won't be any VAT or for Augustin the French one will be used. It doesn't work that way. So knowing that we can proceed and it will work. We use a pricing rule that selects the right price field. So that means when the price of a product is calculated the system asks do you have anything to add to this price and then we say yeah sure where is the customer coming from? Oh he's French. Okay I'm applying the French VAT and or I'm selecting the Euro price and that will work. Of course there it is not completely user friendly. Ideally I would be able to select my rate right when I'm adding a product but we'll get to that. And this is where David Kitchen saves us all. He's right here in case you want to buy him a beer afterwards. So we have a set of commerce modules that handle all of the edge cases that I described for triple commerce and I think this really gives us an edge over competing solutions. So what these modules do is that they handle all of the rate changes automatically. So they will compare the date of the order and based on that select the appropriate rate that was valid at the time of the purchase. So if I added suddenly manually an order that was valid for a previous period it will know to select the previous rate that was used. It knows how to collect the correct VAT on shipping. It will always select the biggest rate. It predefined all of the rates for the European Union and they maintain it. I must admit that it took David four days to add Creish after they joined the European Union. It's quite a long period of time but we survived. So we have all of the rates and they are being maintained. So you can just install that and the system suddenly knows about all this. And there are additional modules that will do the same for Switzerland and other non-EU countries that still force you into this. It handles B2B correctly. So what's EU called reverse charge? It will add a VAT number field and if that field is entered it will not apply the VAT. It will handle the place of supply. So it has a much more efficient rules mechanism so that it first determines the country that's valid and then it determines the rate of that country that should be applied which means that you have drastically less work to do in your rules with evaluating all of the different conditions. And of course it gives you the ability to pre-select the VAT when you're adding a product. So you don't need to go into rules at all to say this product should have this VAT by default and so on. And it's ready to handle your woes. So I think this is major. So please give David an applause. Of course the problem that we have is that we need to scale David. It's not okay for one person to maintain all this when all of our businesses depend on this. In commerce we have the list of countries that are maintained by the contributors and it has always worked well. A developer from a specific country will come and say my currency is not in here and they will help keep it current. So we need to start doing the same for the VAT rates. We need to care whether our country's rates are current and keep them up to date so that David doesn't have to. And that way we ensure that the system continues to function for others and it's constantly up to date as it should be. In general I was asked about the problem of updating. So if the country keeps changing its VAT rates the system needs to be updated as well. So it might still make more sense to use an external service. But I don't really agree because countries don't do this every five days. They usually do it in something like once a year. This gives you plenty of time to install that commerce VAT point release and get the updated rates. And so now that we have VAT covered and we feel better about it, we know that it will work for us and our accountant won't escape to another country. We can actually think about choosing a payment provider. And the problem here is that people usually don't know how to think about the problem. I myself before we just start googling for random solutions choose one that kind of looks okay and then try to implement it if it has commerce implementation. But let's look at what the actual criteria is and should be. So of course we start with the location and this is your location and the location of your customers. Not every payment solution will work in your country and it might not support all of the countries that you want to support. If you really want to sell to Serbia because I'm there and I will buy your product but it doesn't support Serbia, you just lost me as a customer. Or you need to provide an alternative. So that means you now have several payment solutions you need to have on your website which you need to track which is not really nice. So that's our first criteria and we need to think about that. Our second criteria is budget. So the thing is that different payment providers have vastly different pricing models and pricing strategies based on the business that you're actually doing. So are you doing hundreds of sales per month or are you doing hundreds of thousands? How much money is that actually bringing you? Which countries are you selling to? Which payment methods you need to support like you need PayPal, Amex, all this is taken into account and some payment providers might have a flat rate up to a certain amount but others might actually be cheaper if you're doing more requests. So there are many varying factors and you usually need to contact them and get a quote and we'll see how we can actually get around that so we can have more information. So to recap, the main question is do they work in my country and can I afford it? There's also a question of coverage. So we can classify payment providers into two buckets that they call regular and alternative and they might not be the best terms but the idea is that for a regular payment provider is one that processes the payment directly. So you have a merchant account with American Express or your local bank and they just do this thing for you. However, you also have alternative payment providers such as Amazon and PayPal that will partner with a whole range of smaller gateways and just deal with them for you. So you don't need to open accounts for every new country you need to support, you can just, they will just handle that for you. They will take the payment and they will route this to the appropriate place. It's something to keep in mind and it's important to know what the future plans of your provider are. So are they planning to move into another country? If I want to support Croatia and it's not supported, it might matter that they have it on their roadmap in the next six months. In that case, I don't need to look for another payment provider. So that matters. There are also many additional questions like are we supporting 3D secure? So most of you have seen 3D secure in action. You go to buy something and it redirects you and then it asks for some additional information, your password or your date of birth, different banks have different ways of implementing this. Visa calls this verified by visa and by having this additional step of verification, you feel more secure, your customers feel more secure, which means there's a higher chance of your order actually being completed and the bank feels more secure which means there's less of a chance for them to block funds. So it really minimizes the problems that you might have. There's also the question of PCI compliance, not all payment providers and not all implementations are made the same and you need to take that into account. Even with PayPal, you select one solution but it actually has a bunch of different solutions included and not all of them are the same when it comes to PCI compliance. So this could be a session or two all on its own. I can say that we have an awesome website and an awesome white paper on triplePCIcompliance.org. It was partially sponsored by Commerz guys and it will tell you what you need to know both to select the right payment provider and to make sure that your shop is secure and that you've minimized your liability. So go there today and read everything about it if you're actually doing e-commerce on triple. I also mentioned that our company might want to have subscriptions at one point and not every provider supports this in the same way. So this year Commerz has seen the development of awesome recurring solutions. We have Commerz recurring done by Pedro that handles the prepaid use case which is great if you're charging for a magazine or a file and Jonathan and me also have a solution called Commerz license billing which aims at assess use case. So that means you can charge based on a plan, you can charge based on metered usage, you can have plan changes, postpaid charging, everything you would want to if you're charging for an external service like you're selling the right for the customer to send emails and you're giving them a certain quota and then charging them over that quota and so on. And both of these solutions use Commerz card on file so that the user doesn't need to actually enter his credit card each month. So the way card on file works is that it stores the credit card information on the payment provider, they basically do it themselves and they give us a token and we can use that token for all future transactions and that way we can do recurring each month or each billing cycle no matter what its length is and it will work automatically. So ideally our payment provider should support card on file not everyone do. And then there's the question of zero authorizations. So imagine that you're not actually that you're doing postpaid billing. You will charge someone at the end of the month but you need to actually make sure that you can charge him at the end of the month. So you need to do an authorization to test his credit card. And certain payment providers support zero authorizations which means you can do that without actually charging them anything and some don't. And ideally you would want to have that. We use PayMeal for that for precisely that reason because it allows us to do zero authorizations which allows us to actually sell you Commerz platform and we can actually be sure that we can charge you. And in the same ecosystem we have Commerz dining that will handle the use case when the card could not be charged and then we need to notify you and so on. So this is another big story and if you really want to get into it it's something that you should think about when you're selecting your payment provider so that later you can just add the modules and implement that instead of being stuck or having to actually redo your payment implementation or change it in any way because let's be honest it's also a stress on the user who suddenly sees a completely different payment flow on your website. So I wanted to show you how we can help. For a long time now people were coming to us and asking these questions. How do I know which payment provider I should use? What should my criteria be? Do you have any listing that I can look at? And now we do, it's called the marketplace and it has constantly expanding listing of payment providers and other third party tools that you can look at and you can inform yourself. So we are taking the effort to actually gather the information from them and then present it to you in an easy to use way and then if you want you can download the module and open an account with them. We even ship the connector inside Kickstart so you can click a tab and immediately browse and when you select one for instance if I open PayPal it will show up in my add-ons later and it will show me my credentials. So it's a big convenience and I think it really helps people decide. So what we provide is we give you a general overview of the cost. We cannot give you an exact cost because they will always want to know all of the parameters they use for pricing so they can give you a quote but we will tell you what the general category is so you will know whether it is for you or not because for instance PayPal is a really flexible solution it supports many countries, customers trust it but it's really expensive and it's okay if you want to grow with them but if you're just starting out you might want to look at some other solutions. Also we tell you clearly what's the functionality. You don't need to go yourself through the marketing talk we will see what's important and we will present this to you and we are constantly working on refining this so it's actually more informative. We will tell you how to sign up so we will direct you to them or we will give you a form you can fill in right away to send them an inquiry. For certain solutions we will allow you to register right away through the marketplace so you will immediately get your account details and you will be able to see them right away even from Kickstarter. So this also decreases the time needed to actually get you started. We also provide the quality guarantee so if something is on the marketplace that means we've completely reviewed the code sometimes multiple times and we've worked with them to ensure that they are secure and that they maintain a certain level of quality which is really important and together with that it also means that there is a maintenance guarantee. This module will not be abandoned because we are here and we are helping maintain it and you might have 20 PayPal modules but ours is maintained. It's not just maintained, it's maintained by Ryan so that's a pretty big thing to consider and even you know that it's on a roadmap so even as commerce changes as times change we are still here, we are maintaining it and making sure it's good and honestly that would make me sleep much better at night. We are very interested in finding out what you want. What are your questions? What do you worry about when selecting a payment provider? So come to our booth, talk to us, talk to Shannon and tell us so we can actually refine this and we can provide all of the information that could be useful for you. That way we will come to a point where we have all of the great payment providers right there ready to compare, ready to review and then we can just pick a good one and we can implement it and we're done. So all of this really saves time for you and it helps us because you're not building a crappy site. We need to talk about few technical caveats about implementation. I won't be able to go into all of them in detail because we should start with the questions but let's go through it real fast. So with translating the UI, many people think like this. You know at some point you just have to realize there are some strings that don't want to be translated and you need to honor their decision because the Drupal T system only works on strings you define but if something is user defined like the title of a text type or a checkout completion message you cannot translate that but if you use the internationalization module which provides the string and field sub modules that will work and when you install them many of the commerce strings that you couldn't translate previously will automatically become available and this solves 95% of the support requests around that in our queues. Translating the content, you use entity translation for everything. Forget about the old translation module forget about the internationalization taxonomy don't use different approaches for different entity types you use one module to translate any entity whether it's content whether it's a product, a term, it doesn't matter. For invoicing there's a nice module called commerce billy you can use it if you don't use an external system make sure that you're following your country's laws different countries have different laws on how the invoice needs to look and what information it needs to contain and that information varies from country to country. So if you have a presence in multiple countries you also need to think about that. So inform yourself and then implement the correct template at one point it would be great to have a contrib that would do it automatically for you of course. So what's our future? Right away we have a buff at one PM and we would love for you to come and talk about the actual problems that you have implementing this in commerce. It's some of you are probably listening to me and saying yeah it sounds so easy but I ran into this bug or this problem and I didn't know how to proceed. Well we can discuss all of that at the buff. At the buff so David and I are doing that at one. Please come if you're interested at least we can have a chat. We need better documentation so Josh Miller is working on having a complete step-by-step guide on how you should translate commerce and how you should translate commerce kickstart. This is our biggest cause of confusion right now and just doing this on Drupal 7 is really hard which you know if you ever listen to Gabor we can make it easier but actually showing you the right way and we are working on that. We are working on the full documentation and you're free to contribute. We of course need better contributes so we can make this even more user-friendly. For instance we have a nice discount module maintained by Jonathan Kuma and it really helps you define discounts in an easy way and it also needs to handle VAT rates easier so you don't need to worry about modifying rule weights and so on. It just should handle everything automatically for you, it doesn't but it's really close and we are working actively on it. We need all the help we can get. As I said, David doesn't scale, Ryan doesn't scale. Most of our developers do testing on their own so you have a project that's done by only one person and these are the things that affect us all so we need to care. We need to care that commerce does this in an easy way, in a bug-free way and we should all at least provide testing to point out the hard things to point out any bugs and we should contribute because we cannot do it alone and we need to have this. And remember, commerce without borders is Drupal without borders. If we have an amazing solution for e-commerce, amazing beyond the borders of Drupal itself and the more we spread commerce the more we will spread Drupal. So please, if you have any questions, step up to the mic. I'm working as newly implied as head of Drupal service with a Dublin-based company and we use Drupal for making big websites. I'm sorry, can you just be a bit louder, I couldn't hear you. Hello? Yeah, that's much better. Yes, I'm newly implied as head of Drupal with a company in Dublin and we use Drupal first at big websites. If the big websites have a small e-commerce section and we use Drupal commerce. Yes, definitely. If we're making a big website with a big e-commerce section and we use Magento, how do I get my boss to use Drupal commerce? Well, show them all the great huge websites that use Drupal commerce. Go to our booth and see some of the examples. If Royal Mail can do it with 18 million orders a year, if Cartier can do it with sites in every country and point of sale terminals in every store, I would say that's pretty big and we have plenty of those examples and we have shown that commerce scales amazingly on the projects of that size and of course, you can contact us and we can help with any talking points or examples or anything you need to actually make that switch. We will support you in any way we can. Thank you. Hello. I want to ask you if there are some features or something other that can add me to import some content type as a product then to or when I raised all the website with commerce, if I can import the contents, photo, video and other. Yeah, so the best solution for importing anything into Drupal is migrate. Migrate will allow you to go between Drupal versions, go from external systems and we always use migrate for everything. Commerce Kickstarter actually has migrate built in and we use it for our own importing of the demo content. So that's definitely the solution you should use. When you start the website, use migrate to import your data no matter where it comes from. Yeah, we have a video channel that helps. So, well, we have tutorials about that so you can, and we have time for one more. Oh, thanks for a great presentation. I think I represent your nightmare. I'm from Norway. I'm sorry. I also represent a publishing company in the same country and we do sell a lot of stuff but we still are seeking for some kind of transparency regarding the ERP integration possibilities in Drupal because we are totally dependent on that and it's a big part of our supply chain and it also is actually a fact for most other companies in the Nordics at least in Microsoft Dynamics is the solution with Navision and stuff and the biggest sales argument to get Drupal through to the organization is how well it works with an existing ERP solution. So what are your thoughts and experiences? So in my experience, the different ERPs always need different custom implementations and we've had experience with integrating various different ERPs and so far it seems that that work wasn't shareable. That's how custom it was but I think we can definitely talk about how we can actually improve that. Maybe we can document the process. Maybe we can release some code even if it needs modification so to actually get you started on that but right now it's always a custom integration. Okay, yeah, Brian. Did you know while you were talking I fixed that shoot your foot with a shotgun thing? There's a patch now to remove a VAT that's already been included if you entered a product price including that VAT. Nice. So yeah, I should say that every single commerce release has had at least a few fixes for intranslization and translation. We are constantly improving things. The commerce 1.8 has about 10 patches and improvements to make this really smooth and to make the ad to cars form and everything easily translatable. So we are constantly working on this and thanks to Ryan, we are constantly progressing. So I think that's good and make sure you're always using the latest code because it's always a working progress. Yes? What about rounding with the VAT? If you don't include the VAT in the original price and like your product is one cent and you buy a thousand of that and the VAT in the product price is shown as the product is just one cent but if you buy a thousand of that it would be like 10 euro and 11 euro or something because you have the VAT but you don't see that in the product price. Yeah. So the commerce VAT has some additional options to handle the rounding. One other example is that if you're entering prices without VAT it's really hard. You cannot get a price such as 14.99. So we allow you to change the rounding so that you can actually manage that. And I think that helps whether it resolves your problem completely. I'm not sure but we can discuss it at the both together. Okay. And if you enter the product price with VAT isn't there, why can't I not just remove it again for business customers? Because the patch wasn't written. Yeah. Okay. Because that's what we ended up doing. And then about this, you say you update the module and then you get the new VAT. Does it mean that it switches immediately or it switches at the correct date? It always switches at the correct date. It knows when the rate starts and when it ended. Yeah. Okay. Otherwise I would say why not make our own web service for this. Yeah. Okay. Yeah. Well, some of my colleagues say that ideally the government should have a free service so that you can ask what's the rate for this and you will just get back a response. The problem is we would still need to classify our product but maybe the NSA can do it for us. So at least for sales tax we can use that. We'll see. Okay. Thank you for your time and see you at the booth. Oh, and please take the survey and tell me how I can improve. Thanks.