Vertically slicing backlog items on a back-end COTS implementation

I have spent a lot of time reading up on the principles of scrum and feel fairly confident in the need to:

1. Ensure the backlog item is vertically sliced (and delivers real business value when delivered standalone)
2. Ensure the backlog item is small enough to be delivered within a sprint
3. Ensure the backlog item is understood well enough by the PO so that they can effectively prioritise, discuss with external stakeholders, and communicate the value.
4. Ensure the backlog item is not forced into a certain format (e.g. user story for the sake of a user story)

Whilst I understand the reasoning behind these principles, I am finding implementing them in practice to be nigh on impossible. The project I am working on is a highly technical project to implement a new order management system for a retailer. The project can essentially be split into two streams:

1. Implementing the off-the-shelf order management system & doing all the required configuration (e.g. configuring the fulfilment workflows and logic, creating retailer accounts, setting up locations, product catalogue etc.)
2. Building the middleware components that will allow the OMS to communicate with up & downstream systems i.e. interface the order from the eCommerce system to the OMS, communicate between the OMS and the payment gateway, pass the order from the OMS down to the WMS, interface pick / pack / ship updates back into the OMS etc. This is a highly technical workstream using Apache Kafka and building routers, mediators etc.

In the discovery period there was a significant amount of work to map out the order workflows, document all the happy & unhappy paths, discuss all sorts of business needs such as how to handle cancellations, how to handle short picks etc. I was not present for the discovery phase but have access to all these flows and notes taken.

I have joined the project in sprint 2 and as you might not be surprised to hear, the product backlog is a sea of highly technical tasks (which are almost impossible to understand to anyone who is not a technical architect or developer). These tasks are clearly all important and required to do things like setting up Kafka topics, building routers & mediators, configuring workflows etc. The trouble is, the PO is not really able to drive anything and instead it's the technical architect & leads that are writing all the backlog items, and then the BA's / PO are playing an admin role to get these tickets created in JIRA, categorised, put into sprints, estimated etc (but really this is all blindly following the guidance of the techies as the backlog items are too complex for non-techies). 

What I'm really struggling with is all these technically complex backlog items are clearly key chunks of work to deliver what is a highly technical product. I wouldn't question that as the tech leads are highly competent. And they clearly understand how all the backlog items fit together, sequence etc.

However my gut feeling tells me that the following things go against best practice (whatever that actually means):

1. The backlog items dont appear to be vertically sliced and dont seem to deliver value to the business standalone. But really I dont see how this would be possible because the project isnt delivering any user functionality - and the integrations & OMS only really serve any value to the business / customers once they are fully developed/configured, and can be used to handle orders from the ecommerce store. 
2. They are too technical to be understood by the PO/BAs, so it's very difficult to discuss with external stakeholders, or do proper prioritisation without just blindly following the steer of the techies. 

The customer placing their order online really is abstracted from all this complexity in the order management system, and really if you tried to write user stories from their perspective it would be pointless. They just want to get their order delivered by the date promised, and if cancelled they want to be informed and given a refund. Equally the internal staff never 'use' these integrations or OMS in a functional sense, they just rely on it working to route orders to the right place, orchestrate the workflows and manage / disseminate order updates to the right place. 

I dont want to get too hung up on how things 'should work', at the expense of common sense and what's right for the context of the specific project. But I just have this gut feeling that I'm completely missing something - and most importantly I'm trying to work out where I can add value as a BA that has turned up in this highly technical project. 

It seems ALL the resources online that discuss how to approach backlog items, slicing etc all seem to presume that it's software being built that is delivering functional features to human end users. In reality I feel this is a tiny proportion of projects. Far more common seems to be the implementation of COTS systems, often back end systems which require complex integrations with up & downstream systems, and which execute workflows in support of a much wider business process. These kind of projects never seem to be discussed online (at least not that i can find), and when they are, no one actually gives concrete examples of how they have managed such a project in an agile fashion. 

Any help for a confused BA would be much appreciated.

Thanks