Hard to manage user Stories/Tickets because the completion can take up to 2 sprints!

How is the team currently refining the incoming work on the Product Backlog?

It sounds as though it is not in a "ready" state for Sprint Planning in Scrum, nor that it could reach a commitment point in Kanban.

We mark the user stories as "ready" once they provided everything that we need (connection details, NDA, etc.) However, in the middle of development the issues that I mentioned arises. Sometimes even the client de-prioritizes the integration and there's nothing that we can do about that. What we can do is take in new requests which we don't have any lack of.

These are generally easy but unpredictable due to blockers like incomplete information from clients or delays in their development/testing. 

Why is the client development/testing included in your Definition of Done?  Are you delivering work that meets the specifications that you have discussed with the client in a Sprint?  Create your Definition of Done so that it does not require client validation. At most they will have to wait for another Sprint to get any revisions that they ask for and it will probably fit into their "delay". 

The commitment for a Sprint is to the Sprint Goal not to a set of tickets selected in Jira. The tickets can, and in most cases I've seen will, change during the Sprint as more is learned due to the work being done.  Stop worrying so much about how many tickets your Developers mark as "done" (i.e. velocity) and focus on the value that you are delivering to the clients in each Sprint.  Are you delivering usable increments of Product updates in each Sprint? That is what is most important, not how many tickets you mark as "done" or "closed" in Jira.

...provide the metrics senior leadership wants.

Then maybe it is time to work with senior leadership to help them understand what kind of metrics make sense to be generated.  Generating graphs/charts of how many Jira tickets are being "done" in Sprints tells nothing about the value and quality of the work being delivered to the client.  I suggest you check out the Evidence-Based Management Guide offered here on Scrum.org. It might be a good starting point for you. 

Hi Marvin,

If I understand you correctly you have two workstreams and one team that works on both.

1. Enhancements /Changes 
2. Client requests

I have worked in this kind of scenario and came across the same issue that you mentioned where client request takes up sometime and Changes are not completed at the end of the sprint.

My suggestion would be to use Kanban for client request part as they are of add-hoc nature, and it is best to keep this out of the sprint (let sprint backlog be only enhancements and any bugs related to them). Let client request tickets be reported separately like how many requests you solved in a week/month. Have a look at metrics like cycle time, lead time. The enhancements reporting would be based on sprint metrics. Again, discuss with your management and finalize on this.

In my previous experience we had done something like this -every sprint one person (some senior developer) would look at client requests and would not be an active contributor on the sprint. His primary work would be client request, but he would assist in the sprint by doing some Testing/code review when required. 

You will have to figure out with your team, how you would want to handle this and then make the suggestion to the management so that all are aligned with the approach. But my suggestion is to not mix-up client request with Enhancements.

Our velocity is hampered by client requests.

Kanban method also encourages the "Pull" approach than "Push" approach in taking the work. But in a timeboxed sprints and planned backlogs, the adhoc client requests also should be filtered. Not all the request could be "pulled" in a sprint because it is simple and ready, but its priority needs to be checked. If the tickets are added/dropped in the middle of the sprint and if that impacts the sprint goal that is planned for the sprint, then PO can check if some requests can wait for later sprints.

While our team is organized and manages tickets well, it's hard to capture everything in JIRA and provide the metrics senior leadership wants

Using kanban board is a good idea for "Transparency" about work in progress and identify if there is inefficiency in the way the tasks are handled by the team. How the team is manages the tickets well while they are not able to capture what they do ?. Why the team wants to take work which is beyond visualising it ? imo, This also a problem of no proper prioritisation. PO plays major role in the effectiveness of the team.

Can you make it visible the problem of no proper prioritisation, readiness, and sizing in your kanban board and metrics ?