Sequence Diagram from Class Diagram

I'm doing a little UML project where an User has to buy a ticket through the use of a credit card (that he/she owns). There are 3 types of ticket: single use ticket, half day ticket and full day ticket, all of which are subclass of the abstract Ticket class.

The sequence diagram must represent the action of buying one of these kind of ticket, however I'm struggling to implement it (I'm using STARUML for this project).

This is how I would had it implemented

You are already using the correct element for this: A combined fragment with alt-operator.

However, some things are unclear: In your operands you have a text (e.g."Single Use"). I wonder what this is. If it is a guard, then it needs to be in square brackets. Typically the guard will use some attribute of the type represented by the lifeline with the first message in the operand, Ticket in this case. It doesn't have such an attribute, but we could interpret this as the result of some TypeOf()-function.

The next thing is, that a Ticket generalizes Single Use Ticket, so each object of type Single Use Ticket is also a Ticket. Then, why is a Ticket object communicating with a Single Use Ticket object? That would only make sense, if Ticket had an association to Single Use Ticket, which it hasn't. Therefore, the four Ticket lifelines should be only one and all the getCost-messages would be directed to the same lifeline that sends them.

I understand, that you want to express, that the implementation of getCost depends on the type of ticket. However, this would only be visible in a sequence diagram, when the implementation leads to different messages being sent. This is not the case here.

It is also strange, that Ticket.buy expects a parameter of type Ticket. When you send a buy-message to a Ticket object, what is it supposed to do with another Ticket object?

One mistake in the diagram is, that your reply messages are not consistent with the synchroneous messages. Reply messages must return to the lifeline, that sent the synchroneous message, because "synchroneous" means that the sender is waiting for the reply.

You are using found messages for the messages coming from the user. I would rather use messages from the frame of the diagram, because in principle you know, where they come from, you just choose not to model it.

One final recommendation: Lifelines can represent attributes or parameters. Therefore, you should show the name of the parameter or attribute in the head of the lifeline, e.g. cc:Credit card. If you are omitting the name, the colon in front of the type remains.