Story Point Handling

I'm not sure what you mean by "using" Story Points. Estimates, including Story Points, have limited value after Sprint Planning. Consider that a team has a decent shared understanding of what a Story Point is and tracks their completed Story Points in each Sprint. Unless there's a significant change in the team's capacity, it's highly likely that the Sprint being planned will have a similar completion rate to recent previous Sprints.

The Scrum Guide doesn't give guidance for what to do with unfinished work at the end of a normal Sprint, but does give guidance for what to do with unfinished work due to a canceled Sprint. I do recommend following this guidance in most cases. The Product Backlog Item goes back onto the Product Backlog and is ordered with the other work, including any feedback from the Sprint Review. When considering the order, I do consider the fact that some work has been done and that it is wasteful to start and not finish work. If the work is still relevant, I do encourage it to be finished in the next Sprint as often as possible, but it's not a firm rule.

From a Jira perspective, I do not like to close issues that aren't actually done. Doing so would break traceability with my version control system and CI server to link the issue to the work that it represents. Moving the issue between Sprints or between a Sprint and the backlog is often sufficient. The use of labels and custom fields can be helpful in more complex environments.

I prefer to not reestimate work, so once the team estimates a Product Backlog Item and agrees, that's it. It becomes a fixed value. If there are discrepancies, that is something that can be discussed at a Sprint Retrospective to help figure out what was missed and improve for the future.

What are your opinions and suggestions and do you have experience in handling not completed tickets it in JIRA?

Any work that has not been completed, and which still remains to be Done, should be accounted for on the Product Backlog. That work may then be planned into a future Sprint.

The Product Backlog should always indicate how much work is believed to remain, and hence estimates ought to be kept up-to-date by the Development Team.

The toolset used, if any, is irrelevant.

The story points have been used, but there was more complexity or time needed that estimated.

I'm with @Thomas Owens on not understanding what you mean by story points being used.  A story point is a guess based on the information you have at the time you make the guess.  They are nothing more than that.  And in the true definition of Story Points, they are not representative of any kind of unit.  They are relative to other guesses you have made.  

I have 2 answers for every case you described. 

1. The team needs to decide how to address each case and not come up with a standard process.
2. The work needs to be completed when the team feels it is appropriate to do so.

I have seen cases where an original estimate was a 3 and it ended up taking 2 two week Sprints to complete.  I have also seen cases where an estimate of a 13 took 2 days to complete.  You are guessing based on the information you have.  As new information is obtained, everything can change. Stop making Story Points into something they were not intended to be. Here is a blog post by the man that has been said to have created Story Points that might help you understand their use.  https://ronjeffries.com/articles/019-01ff/story-points/Index.html

I personally agree that anything not finished should be put into the Product Backlog and ordered appropriately with other items that are there.  I do not believe that something not finished must go into the next Sprint.  Sure, not completing work can be considered waste but sometimes the work that has been completed can be enough for a potentially releasable increment. As I stated in #1, every case needs to be addressed individually not by a standard process.