WooCommerce Innovations in Order and Payment Processing

James:
Hello, I’m James Kemp. I’m from WooCommerce, and we’re going to use this time to talk a bit about what we’re working on at WooCommerce behind the scenes that maybe you, the community, don’t generally get to hear about. So I am joined today by Beka from KestrelWP and Patrick from Mindsize. We’re all collectively working on a project together centered around order management, and we’ll dive into that shortly. But first of all, I think it would be useful to introduce yourselves. Beka, if you want to go first.

Beka:
Yeah, sure thing. It’s great to see both of you again, James and Patrick. For those of you maybe new to the Woo space, I’m Beka Rice. I work at Kestrel, formerly one of the partners at SkyVerge. I’ve worked with WooCommerce since version 1.5 or 1.6, I think. So it’s been about a decade, actually a little over a decade of time with WooCommerce. I’ve built over 60 different plugins for WooCommerce as well as cross-platform apps for Woo and Shopify. So I’m very excited now to be working on a project to improve and revamp order management with James and Patrick. Patrick, I’ll turn it over to you.

Patrick:
I’m Patrick Garman. I own and run Mindsize. I’ve been working with Mindsize since 2017, but I’ve been working with Woo since probably the same era as Beka, maybe slightly earlier. I feel like it was around version 1.2 or 1.4, right after the fork that we don’t talk about. We work on high-performance, high-scale applications, and a lot of WooCommerce is the tool we use when we need to really customize an e-commerce store to fit our needs.

James:
What’s the first version of WooCommerce? WooCommerce 1.0?

Patrick:
That’s a gray area.

Beka:
Yeah, I think they did call it 1.0 right after the fork, and there were quickly a lot of patch releases. I remember the first couple of minor releases were within months of the WooCommerce launch, so it moved pretty quickly. Version 1.4 would’ve probably been, I don’t know, maybe six months in at most. It was pretty quick in the beginning, and then we got to skip around a bit. Sometimes it jumped from 1.6 to 2.0 right away. Those were painful times, but yeah, pretty early on.

James:
Yeah, I think I joined or started using WooCommerce after originally using the previous software in…

Beka:
2000? I don’t think it’s a bad word to say Jigoshop.

James:
I don’t know if we’re allowed to say it. What happens if we say it three times?

Beka:
Let’s not test that, James.

James:
It was 2011 when I started using it. I didn’t take note of what the version number was back then.

Beka:
Yeah, that would’ve been pretty early. It was like fall 2011, or early 2012, I want to say.

James:
My first plugin was in 2011, and it went on to CodeCanyon, so I must’ve been right on it somehow.

Beka:
I’m going to look it up right now. You’ve got me curious. Yeah, September 2011. So Woo is almost 13 years old. There we go. Okay, so we’ve all been doing this even longer than we thought—this is what age does to you.

James:
Yeah, definitely a lot of expertise in the room around WooCommerce. I imagine WooCommerce wasn’t your first entry point into the web either. We’ve all got a lot of medals in the industry, which is awesome. That’s why it’s such a great group of people to work on the project we’re working on. For clarity for any listeners, Beka and Patrick are working in a consultation capacity at the moment. We’re in the very early stages of the project, doing a lot of work around deciding what it’s going to look like, how the data is structured, and a lot of work on design and how it’s going to be implemented into WooCommerce. That’s the context. I think we should start discussing what we’re actually working on.

Beka:
So maybe what if we outline the problem? I think over time, Patrick and I have seen a lot of different Woo store owners doing a lot of off-the-wall but cool things. And I think one of the things that we’ve seen over time—and obviously, Patrick, feel free to jump in, especially from a high-volume perspective—has been that fulfilling orders, and that timeline between the customer placing the order and the customer receiving their order, is the hardest thing for any e-commerce merchant to manage, right? There are hard things…

James:
Probably one of the most common things that they’re going to be in there doing as well.

Beka:
Exactly right. That’s what you do all the time. You’re not always uploading product images or changing product listings, but the one thing you’re doing consistently is fulfilling orders. And it’s the hardest thing in e-commerce, even though inventory management is hard, there are a lot of hard things. Order fulfillment is definitely the most challenging thing for merchants to do. And I think historically in WooCommerce, that’s always been a bit challenging. When you look at the orders list, it’s not always clear if something’s paid for or not, if the charge has been authorized or captured, if the products have been packed, if they’ve been shipped, if they’re in transit but not yet delivered, or when the item is delivered. We only have this concept of order on hold, processing, or completed. So merchants have not had a granular view of that fulfillment process, and as Patrick can attest to this, the more your store scales up, the more important that granular view becomes. How many packages do I have yet to ship? How many labels am I going to need? What’s the throughput in my warehouse or shipping operation? So that was kind of what inspired the three of us working together on this—how do we solve that problem in WooCommerce, and what other related problems can we address at the same time for merchants who are fulfilling orders and struggling to understand the status of orders and how to fulfill them, and what steps are needed? Patrick, I don’t know if you have anything to add to that, but that was kind of the problem that inspired this project, and I think we can also talk about what we want to do about it.

Patrick:
Yeah, definitely. It has been a challenge. I know Beka and I have experienced a lot, like she said, and I think this project is most exciting because a lot of the community may think that we just build in a silo, like we’re going to build what we want and you guys will live with it. But in this case, with one of the hardest problems in Woo, we have the product side represented—building extensions, building products within Woo—the scalability side, the data architecture. We’re looking at every aspect of this to build a highly customizable, highly performant flow that can support all stores.

James:
Yeah, and I think that’s probably the biggest challenge. One of the biggest challenges of WooCommerce in general is how customizable it is, and when you’re building something like we’re working on, you have to think about all the ways that this is also going to be extended in some way. But yeah, like you say, Beka, one of the issues with how orders are presented in WooCommerce at the moment is the merchant can land on that orders page and they don’t know what to do next. There’s no clear indication from that list of orders what the next action is for each one of those orders. It’s quite a complicated thing to tackle. Obviously, the order status comes into play, and we have tons of extensions that modify the order status and add all of these interim statuses that could apply to an order. So you might see currently orders that are marked with a custom status of “shipped,” for example, but that’s not indicative of the actual status of the order. Like you said, you don’t know if it’s been fully paid for, you don’t know what’s being shipped, you don’t know when it’s delivered. There are so many aspects that aren’t covered by just having one singular order status. So one of the first points that we discussed is breaking that order status out into essentially three statuses: where you’ve got the overall order status, a payment status, and a fulfillment status. But the challenge we faced is because of how extensible WooCommerce is, and how many plugins and implementations there are that modify or use the order status in some way, we don’t want to just rush in and change how that all works in one fell swoop. So the approach we’ve taken is actually to leave the order status as it is and focus primarily on the fulfillment status. With the goal of tackling that without impacting how people use the order status—other than maybe transitioning to our new fulfillment status if they’re using a custom fulfillment status within the order status system—see how that goes, then focus on the payment status side of things, and then we’re kind of in a better position to migrate people to start using those. We’ll roll it out in a way that they’re kind of independent of each other, but can potentially impact one another. So it’s quite a challenging task, and that’s just the status aspect of it. There’s more to it than that. I don’t know if you had anything to

add to that.

Beka:
No, I think it’s a great start. So definitely the fulfillment side of it. There’s obviously the payment side, as you mentioned, the payment statuses, but the fulfillment side is definitely the place where we can make the biggest impact for the largest number of merchants. Even though every merchant is going to take a payment, and not every merchant is going to have to ship something, the shipping side is definitely more painful right now. Being able to add a fulfillment status is going to make it much clearer where things are. And as you had mentioned, James, the clarity in terms of the data structure around that and also being backwards compatible is a big consideration. Right now, Woo has the concept of shipping line items, but that shipping line item doesn’t really represent a package or a shipment. It’s just a single line with an ID and a name, which can sometimes be very difficult to tie back to which rate created that line, for example. What it represents is more of a payment for a shipment and less so an actual package. So having a proper API to retrieve shipments, to add new shipments, is going to make courier integrations much better. The ability to have a standardized way of tracking information will be much better and will give developers a framework to be able to add all kinds of different shipments. While Core can handle, “I took the order and I shipped it to the customer,” in mind, we also have things like how would we handle RMAs or how would we handle sample packages or ways that this feature can be extended by plugin developers to add new functionality to the shipment concept. So I think it’s a pretty exciting thing for us to do: to have a better data standard around what represents a shipment, how that’s going to be tied to an order, and to the line item that represents how much that shipment costs, and how developers can take that and make some really, really wonderful things on top of it for all sorts of advanced or niche use cases.

Patrick:
You mean I won’t have 15 processes because I use three different carriers that all did things completely differently?

Beka:
Yeah, I think that’s the challenge right now. A lot of folks might be doing things directly in WooCommerce, or they might be using an ERP system. They might be going directly to their account with a specific shipment carrier, and there’s a lot of difficulty in doing that. A good example would be, I know a lot of merchants use both FedEx and USPS for different types of packages, and some of them might be using an ERP or a system that’s helping them in one place, but some of them are logging into both of those and copying and pasting tracking numbers from FedEx over to WooCommerce order notes or something. And that’s the broken process in my mind, and something that you’re going to do hopefully every day as a merchant, we should just be able to make a lot easier—and you should be able to do that right within WooCommerce as you’re looking at the order: “Hey, I’ve packed it, I’m ready to fulfill it.” I should be able to do that whole flow inside of my WooCommerce admin.

James:
For sure. So I think for a bird’s eye view of what we’re working on, which ultimately stems down to a fulfillment status, we’ve got the fulfillment status of an order, which we are looking at as either fulfilled, partially fulfilled, or unfulfilled. Those are the three core statuses that you could assign to an order. So in order to fulfill an order, you would need to create a shipment or a fulfillment, as Beka was describing. And on top of that, you might not want just one fulfillment for a single order; you might want to have multiple fulfillments shipped via different couriers, for example.

Beka:
And I think that piece there, James, is really key. I think a lot of folks who have used Woo have been frustrated with the fact that, “Well, I’m going to ship this order in multiple pieces, and I only have ‘processing’ and ‘completed,’ and my customer doesn’t get notifications for every shipment.” So that partial fulfillment concept is going to be a huge win for merchants who want to just ship things as fast as possible, even if that means multiple shipments, right? There are definitely bigger sellers who want to send more than one package, and this opens that capability up in WooCommerce in a very sane way, which I think is going to be very exciting. And to Patrick’s point about scalability and showing WooCommerce doing these really amazing things, it’s going to be a big win for those kinds of merchants.

James:
I was speaking to a merchant that has to do that quite often. They sell, I think they’re like a bedding store, but they also sell beds. So they have to ship massive items alongside a pillow. What they tended to do if someone ordered a bed, a mattress, and a pillow, they had to manually create another order with just the pillow, remove the pillow from the previous order, and all this kind of manual work they had to do behind the scenes just to be able to send two separate shipments and log it appropriately in whatever system they were using. So ultimately, what we need—and this is what we’re working on—is a data structure for shipments or fulfillments behind the scenes so that the data that belongs to a shipment is always the same, regardless of what kind of shipment it is, and it’s consistent. So third-party tools can integrate into it, and they can receive that data and integrate out of it as well.

Beka:
Yeah, I think let’s take that to a very practical example. So not only as a seller—let’s stick with this retailer that you were talking about—this is an excellent use case. So not only can this person now just fulfill each of those line items independently, with as many shipments as they need, all of that data is stored against the WooCommerce order, easily referenced, and in a structured way. Now we can expose that with a semantic API. Let’s say I build an email marketing app. Now I can get a webhook for a fulfillment being added to an order. First of all, that tells me maybe I should be sending an item-shipped email to users. Now I will know which items have been shipped and which things are in that package, as well as which line items, and by proxy, which products were in that order. So I can be sending these beautiful item-shipped emails as a good example. If there are other actions that need to happen as each item is fulfilled, now any external system that you’re using can tap into that information easily, because it’s not just going to be some random plugin that your app might not have integration with right now. It’s a core feature with part of the core API supporting it. And I think while it’s a really big deal to just support that workflow, I think we all know that the extensibility of Woo and the ability to use it with so many different tools and apps and services—that’s really the killer feature. Having that as part of core, I think, will be a big win for every app in the ecosystem, not just that fulfillment flow specifically on the site.

James:
For sure. And I think as a merchant, just being able to see—and this is kind of where we are at in the design explorations—as a merchant, being able to see the list of orders and then being able to see which orders have been fulfilled and which haven’t, but also which orders have been partially fulfilled but still need some sort of action. I think that’s a really important thing, and it makes that orders list much more useful than it is currently.

Patrick:
We’re filling a giant gap in a number of areas. WooCommerce is often seen as this customizable, flexible e-commerce platform until you want to do backorders or B2B and other complex scenarios that core doesn’t enable well, but now it’ll just work out of the box. If you’re doing a wholesale order to your distributor of 100 mattresses, surely that doesn’t fit in a single tracking number. Maybe you only have 50, but they ordered 100. Now you ship 50, and you still have 50 to go. All these scenarios will just work out of the box.

Beka:
And to be fair, you could always build all your own custom code to do that in the past, which was the cool part about Woo, but now we’re giving people a framework that these customizations or more advanced pieces of functionality can fit into. That gives us a translation layer between Woo and apps and other plugins. Everyone having that common data store, to your point, Patrick, you can enable these really complex scenarios, but now ERP integrations, inventory integrations, or anything else that you have will have a standard way to interact with those workflows. I think that’s really going to be the exciting part of this. Even though these things may have been possible through custom code in the past, that little bit of standardization is going to go a long way towards facilitating other integrations, plugins, apps, and all kinds of features that can be built on top of this, no matter the use case, right?

Patrick:
Yeah, it’ll be less work for me to build something that doesn’t feel like a bolt-on.

Beka:
Exactly right! It will feel way more native, and other plugins will have the ability to understand where that data is going to be stored.

James:
It makes a ton of sense. Additionally to that, Patrick touched on it just then—we’ll be looking at integrating some form of shipment tracking into this, which is a feature that many have complained about missing from WooCommerce.

Beka:
I’m so excited about that change. I think it’s been such a gap. I

know it’s hard because WooCommerce is free, right? Let’s not forget that. And you can’t have a sustainable ecosystem if everything is just free in the core platform. But I think we’ve maybe felt for a while that shipment tracking was probably a bit of a miss or something that is going to cover 80-90% at least of people using the core platform. So I’m super excited to see Woo make that decision to start to put a core shipment tracking feature available in WooCommerce as a result of this. I think it’s going to be a huge value add. And to our previous point, it gives you a standardized way for other apps to understand how to access tracking numbers as part of a fulfillment.

James:
Yeah, I’m hoping we can implement it in a way that means there can be versions of shipment tracking that expand upon the feature of whatever’s in core.

Patrick:
Well, there’s attaching a shipping number, and then there’s having real-time updates you send to the customer. There’s value that could be added. When’s the last time you heard someone say that the WooCommerce order thank-you page is good?

Beka:
Yeah, I think there are opportunities for carrier-specific integrations to have shipment statuses. A good example: if I’m integrated with FedEx, the basic level of that is just getting the FedEx tracking number and URL and showing it in the orders page or emails. But what if I want to have live updates because FedEx has more granular statuses for a shipment? There’s “awaiting package,” “received,” “in transit,” “out for delivery.” I think pro versions or more advanced integrations could be polling FedEx or getting webhooks from FedEx for those delivery alerts, for example, to send even more emails to your customers. I think there are some really cool opportunities that can be built on this with more advanced functionality, but at least from a core sense, you can be supporting that basic concept of: “Hey, a fulfillment is sometimes going to need a tracking number associated with it.”

James:
Yeah. It’s very exciting stuff. I think the other important thing to touch on is that not every order is going to need shipping, and that’s something we’re discussing quite a lot. How do we frame this functionality in a way that covers digital orders and virtual orders? I think “fulfillment” makes sense as a term for covering all of those different use cases. We’ve discussed the opportunity of also fulfilling downloadable orders and virtual orders, but also having it possible to dictate—probably through code—when an order is fulfilled. So if you’re selling a membership (and Beka, I think you touched on this before), you might not want to fulfill that order, or a course, for example, you might not want to fulfill it until they finish the course. So there would be a way to fulfill orders outside of just shipping an item or shipping all of the line items.

Beka:
Yeah, I think one of the things that’s exciting about Woo in general is that you have this long tail of use cases that can come out of every feature in these surprising and unexpected but very cool ways. That’s the beauty, I think, of open source—people will use things in ways you’ve never imagined. We tried to take that concept with fulfillment. Okay, the core reason to have a fulfillment is probably a shipment, but let’s dream a little bigger. What else could people do with this feature? I think as we all discussed this and talked to a lot of merchants, virtual goods like downloads, services, etc. may have the concept of fulfillment. You might want to skip that and not use fulfillments as a merchant, but you might want to—let’s say I sell content writing services and that’s a virtual item. I’m not going to ship anything to someone for content writing, but what I might do is say, “Hey, when I’m done, the first draft is up. Here’s my fulfillment—it’s my Google Doc,” and I send you the Google Doc link. Well, what are the parallels? What if we extract the idea and look for what’s core between a package and a Google Doc? They’ll have a name, they’ll have a URL, and they’ll have a status. So as a service provider, I could add a fulfillment with the Google Doc name and the Google Doc URL, and that’s my fulfillment to you. While I might not use that use case, I might use it differently. What we tried to do is think: what are other ways this feature can apply to different types of fulfilling a good or service, even if it’s not a package, if it’s a digital fulfillment or a service fulfillment, and how can we support that? Which things could be core for virtual sellers? If they’re not core, how do we facilitate extensibility and extensions of that? Core may not, let’s say, have a delivery date attached to fulfillment, but we need to make sure it’s possible to do such a thing, whether that’s enabling a semantic structured form of metadata. There are ways that we can do that and be mindful of that extensibility, which I think is an exciting part of this.

James:
Even touching on what you said before about the fulfillment statuses—not the overall fulfillment status of an order, but the status of a shipment or a shipment status—just having a status per shipment is something we could do via metadata in some way, or maybe it’s a permanent field that belongs to a shipment. But yeah, I think having this structured data of shipments is going to be massively useful in any number of use cases.

Beka:
I mean, especially with the number of digital goods sellers that WooCommerce has. I think that’s always been one of the strengths of Woo—it’s always been fantastic for virtual goods, whether downloadable, services, courses, memberships, all kinds of different things that I think will be very exciting to see how people use this feature. We’ve definitely tried to design it in mind that while it will primarily be used for shipments and packages, we have a ton of other exciting use cases that it could be brought to bear for.

James:
And I think speaking of design, the key area that we’ve been focused on at the moment is how the merchant can come into the orders list and create a fulfillment from that page so they don’t have to click through to the single order page. They can create fulfillments from the orders list and complete that process a lot more quickly than they could right now, which is actually quite a challenge we’ve found in terms of designing this in its most simple form without adding too many buttons or things calling for your attention. So yeah, I think the design aspect of this is very challenging. We’ve got that screen to focus on. We’ve got, once they create a shipment or a fulfillment, how does that look? What does that screen look like? And then also we’ve got the edit order screen—what does it look like when you create a fulfillment from that screen? So we’re definitely in the very early stages in terms of design for this, and we’re focusing on how to make that experience as simple as possible, while also covering all of these different bases that we’ve talked about and all these different use cases.

Patrick:
Not to mention as fast as possible.

James:
Yes.

Patrick:
We spent a fair amount of time in that one design call just talking about, “This page needs to be fast. You should not sit here and wait five seconds for this order to load after waiting 10 seconds for the orders list to load. We’re going to make it fast.”

James:
Yeah, exactly. That’s one of the key things. We want the merchant to be able to create and fulfill orders as quickly as possible because their time is important, and that is more than likely one of the most time-consuming things they have to do. And Patrick, I don’t know whether, but I imagine a lot of merchants are currently fulfilling orders via some other means.

Patrick:
Especially as stores grow, they’ll often have warehouses. Warehouses aren’t going to open up WooCommerce admin to fulfill an order, at least in a lot of cases they aren’t. So integrating these fulfillments into other platforms and having that ability will definitely be a thing. But customer service may need to look up the fulfillment that was fulfilled from the warehouse, and being able to integrate all these things or make it possible for the warehouse that fulfilled the order in some other platform to sync back to WooCommerce, which is integrated into your customer service tooling. In the little sidebar of your HelpScout or Zendesk, wherever you’ve got your order and your fulfillments, everything will be right there, all powered by one consistent data model.

James:
And that’s the goal. So yeah, in terms of a timeline for this, we’re very much in the design phase. We’ve scoped out how we ideally want this to look and work. There’s definitely still more discussion around specifics, particularly around what the data structure is going to look like and how we actually embed that into WooCommerce itself. I would hope next year is when we could be rolling this out in some form, but I definitely want to get feedback early and often on what we’re working on. Right now, it’s hard to find somewhere where you can do that. I think as a company, we use GitHub discussions quite a lot for more officially collecting feedback from the developer community. I use Twitter a lot, but that’s a very unofficial way of doing it—or X, as they call it now. So I don’t know if you guys have thoughts on how we can get more community involvement in this. And also, I’m conscious that we don’t want to have the classic saying of too many cooks. I imagine there’s a lot of design-based input that we could get on this in terms of visual design or even database

design, and there are probably a lot of differing opinions on how best to approach it. But I do feel like GitHub discussions has a technical barrier. I think the people who comment there are more than likely developers or part of some sort of agency, and less likely merchants.

Beka:
Yeah, I would say I don’t feel like that’s a terrible thing, though, because if you’re an agency or a builder, you are oftentimes supporting the merchant and understanding their needs and use cases. Sometimes it’s helpful to have that sense of technical creativity to understand what are the possible ways we could solve this, or what is possible now and what are the gaps. I definitely welcome that side of the input. I do think it’s important, though, to hear the pain in the merchant’s own words and also to get very close to what expectations they have of the experience. Ultimately, you need each of those personas or types of people to make a really wonderful product because they’re all going to be users of the product. Even if the agency, developer, or plugin developer isn’t the person who’s in there using the UX every day—let’s say from my perspective as a plugin developer—I’m the one trying to build something on top of it. If I hate it, I’m just not going to use it. So we need all of those people to be excited to adopt what we’re doing. It’s got to be a carrot; it’s got to be a no-brainer. It’s got to be: why would I do this my own way? Why would I build my own data structure for a fulfillment when what’s in core works really wonderfully for me? I’ve had a lot of success in the past using customer councils. I think Woo has experimented with such a thing. I think it would be great to do a rotation of agencies in the space, of merchants who are actively using it, who want to see improvements in the software. I think Patrick and I are definitely in some ways fitting that persona in different ways—Patrick being on the agency side, working with high-volume sites, and myself being in the plugin developer space, trying to build things on top of WooCommerce and supporting the merchant store using these customizations and plugins. I would love to see a variety of voices involved in contributing to that. I agree with you, James—you can get inundated with feedback that’s not super valuable. So I think it’s having a small group of folks, and it’s also great if it’s not always the same people. If it rotates maybe every six months, I find that works best.

Patrick:
There are so many bike sheds for us to debate what color to paint.

Beka:
Yeah.

Patrick:
Woo’s had a hard time getting store feedback. Think of a big business—they go out, they’re like, “Hey, web developer, I need you to build my store. I don’t care what platform it’s on.” Some of them… So how do you get their feedback from the agency side? What I’ve tried to do, and I recommend many people do, is there are people like James, Ken, and others in the Woo space who want to talk to stores. I can certainly take the store’s feedback and go bring it to James and be like, “Hey, here’s what the store said.” But I just outright introduce the store owner to James, to Ken, to these other people within Woo who can have their own calls and ask their own questions. How you word a question and which way you ask will impact the answer. I’ve got multiple projects right now where we ask the client a question in a way that makes sense to us. They give us an answer that makes sense for the question that made sense to them, but the answer was wrong. So getting these different perspectives from different people is the best way to build a good product—lots of opinions from different perspectives, from different use cases. Spam James with all your store owner introductions.

James:
Just send it all to me. Actually, Patrick, I think it was you that introduced me to the bedding store that I spoke to previously.

Patrick:
That was one of them.

James:
Yeah. I think that’s quite valuable—to have that kind of interaction, that direct interaction with the merchant and really dig into how they use the system.

Patrick:
I mean, it makes you look good as the agency: “Hey, I’m going to introduce you to the head of product at Woo who’s going to listen to your feedback,” which isn’t me. Some people might think introducing your store owner to someone else is going to take away from what you’re doing. It’s the opposite.

James:
Yeah, it’s definitely a useful thing to do. I think even the setup we’ve got here of WooCommerce working directly with you guys from different backgrounds and different perspectives is massively valuable. I think it takes away the too-many-cooks scenario where we’re aligned on what the goal is. Myself, coming from a plugin developer background, I’m kind of consciously aware of how would I want to extend this if I was building a product on top of this. So I think that’s really useful. Beka, you were going to say something. I don’t know if you remember what it was.

Beka:
I do. One thing I did want to call out: we talked a lot about fulfillments in this conversation. I think it’s the first step and most exciting. The plan is to continue building in this line. The other thing we should spend a little bit of time on is talking about payments. One of my complaints about Woo for a long time has been the way payments are represented. I’ve built around two dozen payment integrations with WooCommerce as part of SkyVerge. We have a couple at Kestrel as well that are payment integrations. One of the really challenging things has been that a payment is just a metadata blob attached to an order right now, and that’s not always very semantic or easy to work with. If an email wants to show the card type and last four digits that were used on the order, how does it do that? Well, it has to know which meta keys to look for from all these various payment gateways. That’s not great. So the other part would be what we can do on the fulfillment side, we can kind of do a parallel on the payment side, which is attaching transaction objects to an order. Each transaction would represent a payment. So number one, that’s cool for data standardization—a payment can be represented with the type, the payment name, the payment method that was used, some basic information about that payment method—and that’s exciting for all the integrations that Patrick’s pointed out on the order thank-you page, like, “Hey, we could just display this information; it’s now going to be available in the API,” and that’s pretty cool. But that also opens up the possibility for a couple of pain points for big merchants, which would be partial payments, deposits, multiple payments, multiple captures per order against different line items. There are a lot of more advanced workflows around payment processing that are difficult in WooCommerce, or you’ve got to go bespoke and build everything yourself with all your own custom code. There’s no standardization to allow for translation between apps and plugins. While fulfillments are one area, I just want to make sure people understand payments is another area where we see this need, and we can take the lessons learned from shipments and fulfillments and translate those lessons over to transactions as well, which I think will be a very exciting thing. I know Patrick, you’ve seen a lot of really weird use cases around payments. If there’s anything you want to add there that we can facilitate, just to call out that there’s some cool stuff coming there too next year once the fulfillment project can be kicked out the door.

Patrick:
I’ve been screaming from the rooftops for years about let’s separate the order, payments, and shipments/fulfillments. There are so many scenarios. As businesses get bigger, they add more process. Enterprise isn’t millions more orders; it’s a lot more red tape and process around everything they do. So having the ability to separate these things out, having bespoke objects for a payment, for a fulfillment, and you could have an entire workflow in your store. I’m selling a website. The first fulfillment could be sending off a contract through DocuSign that includes a payment afterwards of a deposit. Then the second fulfillment is a logo, and then a third fulfillment is the pages, the content. All of these things could just fit in a native data structure. You wouldn’t think, “I’m going to sell a website out of WooCommerce,” but you could! Multiple payments, multiple fulfillments of digital and physical things—that’s all possible.

Beka:
Yeah, I’ll give you an example that wasn’t even enterprise-level but was similar. I bought some swag from a Woo store. They’re called Scout Books—they do notebooks with custom printing, and they use their Woo orders as invoices and to pay a deposit. They can either use two separate orders, or you have to do a fee line item and then discount the main line item. But again, you have to have two separate payments, and that’s a customization. So there’s a lot of weirdness to that in Woo, and while it’s supposed to be the most flexible e-commerce system on the planet, let’s make it easier for developers to enable such a thing. Even if we don’t have to facilitate that in the core plugin, we should at least have the on-ramps for plugins to be able to do this in a sane and semantic way. So I’m very excited for that potential because I think multiple payments against a single order will open up a ton of really cool use cases around upsells and cross-sells, post-purchase additions, like a thank-you page order bump. These are all

things that we could make so much easier for plugin developers with that as well. Fulfillment is one piece of it, but then actually accepting the payments against the same order object is the other piece.

Patrick:
That’s like I said earlier: we go from “we can do it”—all of that you described is possible…

Beka:
But it’s ugly.

Patrick:
We can do it well.

Beka:
Yes, it’s ugly now, and that’s the thing that I will be so excited to fix.

Patrick:
It’ll be sustainable, scalable, and performant—just all of that.

James:
And I think on top of the transactions entity being just payments, it can also be refunds, fees, disputes—all of that stuff can be within the same database, and that alone will make reporting easier as well. I think that’s the more challenging side of the two entities that we’ve discussed because once you get into those grounds, you’re then affecting how the overall order status works and the need for using it at all. Whereas I think with shipments, it’s kind of an optional thing. You could either utilize that, but your overall experience, unless you’re using it, would remain much the same. But with payments, every order has a payment—there’s no way to not use that. So it’s definitely a challenging thing.

Patrick:
There’s a way to do it though—to not scare everyone into thinking there’s going to be this huge breaking change in WooCommerce coming. You could have a payment gateway that just marks the order as paid, like it does today, and it just marks the order paid without the data. So there’s going to be a path.

Beka:
And I think, to tie onto that, Patrick, I think as someone who has built both plugins and apps consuming the Woo API, I do want to call that out—that’s definitely part of the path that we’ve talked about: making sure that if you’re an API consumer right now and let’s say you might even be inferring financial and fulfillment statuses depending on whether the order is on hold, processing, or completed, or has a “date paid” property or not, you might have some work in your app right now that’s even circumventing these problems. One of the things we’ve discussed is not making specific breaking changes to the existing version of the API, but allowing you to upgrade to a new version of the API. Now you’ll have discrete properties and data objects for each of these things. The backwards compatibility aspect has been a big part of the discussion. It’s certainly a big project, and that’s why transactions would come after fulfillments, but there is a path to adding these things in a way that is not going to create breaking changes for stores, API consumers, or plugin developers. It would just behoove you as an app or plugin developer to adopt them because it’ll let you do much better things, and it will let you remove probably some of your internal logic that you’ve had to maintain. I think it’ll just be the smart decision to make the updates to adopt this once it’s out there, but definitely not something that would pull the rug out from underneath you.

James:
Yeah, I mean, that’s definitely the approach we’re going for. I think that’s why we’ve separated it out into these phases of work. We don’t want to just one day release a completely different way to manage orders all in one go. So yeah, I think that’s a great point to raise. That is the phase two, I guess, of what I would call the order status project. Ultimately, it’s all boiling down to having these separated order statuses for orders, even though there’s a whole iceberg of a mechanism that goes on behind the scenes for both scenarios.

Beka:
But to tie it back to our point at the beginning, the goal is just so much more clarity around order management. So I think both of these things can add wonderful clarity for even more complex use cases than just: I have a single item in an order, a single payment, and a single shipment. Woo is totally fine for that today, but as we’ve seen, the beauty is that it can be used for way more complex things too. We can have a cleaner way to support those complex things while still having a really beautiful, snappy, fast, and easy interface for people in the orders list.

James:
Agreed. Cool. I think we’ve had a pretty good discussion about what we’re working on, unless anyone’s got any additional points to raise about the project.

Patrick:
I heard from James we’re going to be live in a year!

Beka:
He’s going to hold you to that.

James:
For fulfillment! To be honest, I’m hoping less than a year. I would hope…

Beka:
I think Patrick and I are just excited to see the project happening. We’ve talked about this for a long time in Woo—how it would be a great improvement. I would just say thanks, James, for giving us the opportunity to collaborate and contribute to it. It’s nice to have more of a work-in-public mindset and to have more visibility, I think, as developers. Hopefully other folks too, because Woo is definitely more powerful when we understand even the extensibility use cases, not just core use cases. Not everything will be a core use case, but the extensibility is definitely something that is very powerful to facilitate and make possible.

James:
On which note, I think it would be useful to say how people can contact me or you. I’m on Twitter/X as @jamesckemp, which is probably the best place to reach me, to be honest. Beka?

Beka:
Yeah, also on Twitter—I refuse to call it X.

James:
I feel like I have to…

Beka:
On the bird app—@beka_rice. As James mentioned earlier, our website is kestrelwp.com, contact form. There’s only a few of us, so the contact form will hit me too.

Patrick:
Patrick, and I’m also on Twitter—@pmgarman, G-A-R-M-A-N. You can find us at mindsize.com. Definitely reach out.

James:
Awesome. Well, I hope we can do this again, potentially next month, and we’ll keep people updated on where we’re at on the project as a whole, any kind of roadblocks we’re up against, or any new decisions we need to make. I think it’ll be quite a fun project to keep an eye on. But yeah, thanks for joining me and thanks for being willing to contribute to this project.

Beka:
Thanks, James.

Patrick:
Thank you.