It kind of does. You still have all the same backend logic, but now it doesn't have to run concurrently with a user interface. You can take a queue of operations, process operations off the queue and send their results back. Isn't that a pretty reasonable way for a system to behave? More than a few systems do this internally, with some kind of central message queue.

>>> Having a website just isn't necessary for some of the day-to-day operations vs just sending CSV/Excel files back and forth for reconciliation, settlement, accounting purposes.

>> This doesn't end well when there are hundreds of thousands of "reconciliation, settlement, accounting purposes" to support.

> It kind of does. You still have all the same backend logic, but now it doesn't have to run concurrently with a user interface.

Problem is, there is no self-administration capability when a feed file is the sole transaction mechanism. This can work when the volume is relatively small, say a few dozen customers, or if the Merchant is known to be sophisticated enough.

> You can take a queue of operations, process operations off the queue and send their results back. Isn't that a pretty reasonable way for a system to behave?

Not when there are capability requirements beyond batch processing, such as independent transaction research and/or manual corrections. Both are very common needs with Merchants lacking a dedicated system development department.

EDIT:

Consider a local bar or food truck which accepts credit/debit/gift card payments.

Even if they use host capture and a canonical credit card terminal, the Merchant will certainly want to reconcile their receipts with the end-of-day settlement.

This is not functionality "CSV/Excel" files and batch processing interfaces can provide.