Every Sale You Make, on One Screen

Rentals, purchases and transaction orders all land in the same ledger. Read the payment status, the gateway that handled it and the refund history without opening anything, then go straight to the invoice when somebody asks for one.

Create Your Free Account See Our Pricing
Every Sale You Make, on One Screen

The Question Is Never "Did We Sell Anything"

You already know roughly how the month is going. The questions that actually cost you time are much narrower. Did this person pay. Which card did it go through. Why does the platform think they still owe you money. Did the refund we promised on Friday actually happen. An orders screen earns its place by answering those in one glance rather than by being a second sales report. Every row here carries the order number, who placed it, what it came to, whether it settled, whether it was refunded and which gateway was involved, so most of those questions are answered before you have clicked anything. The customer identities in the screenshot are blurred for privacy. They are not blurred in the product.


Vodlix Content Search
Four ways in, not one

Filter by subscription ID, by content ID, or by user ID and username, and search across orders on top of that. Whatever detail a customer happens to give you is enough to land on their row.

Vodlix Rental and Purchases Manager
Rentals and purchases together

A timed rental and an outright purchase behave very differently for the viewer, but they are both money you took. Keeping them in one ledger is what makes the numbers add up at the end of the month.

Vodlix Payment Gateway Integration Icon
The gateway on the row

Each order says which provider handled it, so a problem that turns out to be one gateway misbehaving shows itself as a pattern rather than as a run of unrelated complaints.

orders-lifecycle.png

A Rental and a Purchase Are Not the Same Order

Both start the same way. Somebody pays, access opens, and a row appears. What happens next is the whole difference. A rental runs on a window, and when the window closes the access closes with it, which is why the expiry has to be tracked against the order rather than assumed. A purchase has no expiry, so the entitlement has to survive a new device, a reinstall and a change of phone. Refunds cut across both. A refund closes the access but keeps the order, because deleting the record would take the evidence with it. Six months later, when somebody disputes a charge, the row is still there with its amount, its gateway and its refund marked against it. This is the operational half of rentals and purchases, and it sits inside the wider set of monetization models alongside subscriptions and advertising.


The Orders That Did Not Go Through

Most of the work in an orders screen is not about the sales that worked. An order that never settled shows as unpaid rather than quietly failing to appear, and the row carries an extra control for dealing with it, so a payment caught halfway does not need a developer or a trip to your provider's own dashboard. Orders that were paid and then reversed keep their refund marked underneath the amount, which means the history reads correctly rather than looking like a sale that never happened. Every order also has its invoice one click away, which is the thing customers ask for most and the thing that is most annoying to produce by hand. Where money moved through a viewer's balance instead of a card, the matching entry appears in their wallet under the subscribers manager, and the account behind the order is covered by user management.


Where the Orders Go Next

One order is a support question. All of them together are your business. The same rows roll up into the sales dashboard and into reports and analytics, so revenue by title, by month and by gateway comes out of the orders themselves rather than out of a spreadsheet somebody maintains. Anything that changes what a customer pays is attached to the order too, whether that is a discount or a gift voucher they redeemed, and the provider that moved the money is one of the payment gateways you have switched on. If your finance team would rather work in their own tools, orders are readable through the REST API as well.


Frequently Asked Questions

Have questions about taking advantage of this limited-time offer? Check out the FAQ for answers.

What is a TVOD order?
TVOD stands for Transactional Video on Demand, which simply means the viewer pays for one thing rather than for a subscription. That covers renting a film for a set period and buying it outright to keep. Each of those transactions creates an order, and the Orders Manager is where all of them live.
How do I find one specific order?
You can filter by subscription ID, by content ID, or by user ID and username, and there is a general search across orders as well. In practice that means whichever detail the customer gives you is enough, whether they quote an order number, name the film, or only remember the account they signed up with.
Can I issue a refund from here?
Refunds are recorded against the order and shown underneath the amount, so the row tells you what was taken and what was given back. The order itself is kept rather than deleted, which matters months later when a chargeback or a query arrives and you need to show what actually happened.
What happens to an order that never got paid?
It stays visible as unpaid instead of disappearing, and the row carries an extra control the settled orders do not have. That is deliberate. An order stuck partway through is the one most likely to turn into a support ticket, so it needs to be easier to find than the ones that worked.
Can customers get an invoice?
Yes. Every order has its invoice available directly from the list, which is the request that comes in most often and the one that takes longest if you have to assemble it by hand. Business customers in particular tend to ask for one before they will expense anything.
Does the order show which payment provider was used?
It does. The gateway appears on the row, so if one provider starts failing you see it as a run of orders sharing the same name rather than as a handful of unconnected complaints. That is usually the difference between noticing on the day and noticing at the end of the month.
How is this different from the Sales Dashboard?
The Sales Dashboard answers questions about the business, such as how the month is going and which packages are growing. The Orders Manager answers questions about one transaction. You need both, and they are built from the same underlying records, so the totals on one always agree with the rows on the other.
Can I get at orders from my own accounting system?
Yes. Orders are available through the Vodlix REST API, so an accounting package, a finance dashboard or a reconciliation job can read them directly. That is usually a better route than exporting by hand every month, and it keeps one set of records rather than two that slowly disagree.