Hey there, welcome back. Here's one more change to make your project more aligned with reality, with what you would find in e-commerce applications. Up to now, we had the payment information inside the Order model. In real life, you probably want to have a Payment model that's attached to an Order. As you know, a Payment holds information that is not directly related to an Order, such as the payment gateway or the payment ID. Sometimes you're also going to find Orders that have more than one Payment. Lots of sites allow you to add a new item to an existing Order to be shared together with it. You might also have Orders that do not have Payments at all.

Lots of sites allow you to add a new item to an existing order to be shared together with it. You might also have orders that do not have payments at all. You might have used a coupon to avoid a payment. With that in mind, it makes sense to have payment information in its own model. For that, I created some things inside the payment module. As you can see, this one has a little bit of a different structure compared to the other ones we've been building. And the reason is I want to start introducing new different types of structures. Lots of times, the usual grouping by type makes sense. Lots of times, grouping by feature makes sense as well. This is not yet a complex module, so you don't have a lot to see here yet.

Lots of times, grouping by feature makes sense as well. This is not yet a complex module, so you don't have a lot to see here yet. But as we build the payment module, you're going to see how we can fill this folder with things that are grouped because they belong together and not because they are of the same type. With that said, let's go through what I did. First, I created an infrastructure folder which holds a database and the providers. On the PaymentServiceProvider, we're just instructing where to load migrations from. On the database folder, we have factories and migrations. So inside migrations, we have a migration for the payment table, which is fairly simple. Total and cents, the status, the paymentGateway, the paymentId, the userId, and the orderId.

So inside migrations, we have a migration for the payment table, which is fairly simple. Total and cents, the status, the paymentGateway, the paymentId, the userId, and the orderId. So we basically extracted information from the orders table. We also have the Payment model, which is also very simple and holds two relationships: User and Order. I have updated the task to run some assertions against the Order's latest payment. And this is also a relationship. If we go to Order, we can see that we have the payments relationship and also the lastPayment relationship, which just returns the last record of a payment. Then we're just asserting that the Order is paid, that the gateway is paybody,

which just returns the last record of a Payment. Then we're just asserting that the Order is paid, that the gateway is paybody, that we have a payment ID of 36 characters, which is an UUID, that the total was $60,000, and that the payment user is the User we created. On the implementation, also very simple changes. I've just added a payment creation right here using the data we've obtained previously. All right, this isn't a lesson, just a heads up on what's being changed before you watch the next lesson. See you later. Bye-bye.