Simply paying for the payload delay in the transactor would be wrong. If we look at how it works in gem5, then the port is not responsible for paying for the header and payload delay. This is the responsibility of the receiving SimObject. The transactors are just different implementations of gem5 ports. Therefore, they should also not touch the header and payload delay and let the receiving module handle the delay. However, in this case, the receiver is a SystemC module that is not aware of the gem5 semantics, which makes it complicated. If the transactor would pay for the full payload delay, then this would mean that the transactor is an actual module that buffers all data and waits for the end of the packet before forwarding it to the SystemC world. However, the transactor should only translate between gem5 and TLM and not influence the timing.
Let me explain a bit of the TLM protocol and how the transactors work:
The TLM base protocol is a four phase protocol (BEGIN_REQ, END_REQ, BEGIN_RESP, END_RESP). When the slave port receives a packet from the gem5 world (recvTiningReq), it sends a BEGIN_REQ to the SyctemC world and blocks the port. Upon receiving an END_REQ from the SystemC world, the port is unblocked. When the port receives a BEGIN_RESP from the SystemC world it sends a response packet to the gem5 world (sendTimingResp) and acknowledges to the SystemC world by sending an END_RESP.
The BEGIN_REQUEST needs to be send exactly when the gem5 packet header arrives at the transactor port. This is current time plus header delay. Then the receiver (a SystemC module) is responsible for modelling the time required for accepting all the data. This is simply done by sending the END_REQ after a certain time. Asuming that the request carries data, the time for transporting this data is modeled by the receiver. It simply delays the END_REQ for a certain amount of time. If we assume that the SystemC module that receives the request, can handle incoming data at lower or the same speed as the XBar, everything should work fine. If the XBar is limiting the speed of data transport, then yes, actually we should pay for the payload delay somewhere. However, I don't have a solution for this problem.
Maybe someone has any suggestions?

Thanks for the explanation. I think I understand now. I think this is a perfectly fine solution, but it would be helpful if you included a little more detail in your comment. Maybe something like "We throw away the payload delay and expect the System-C object to be responsible for modeling this delay. This can lead to incorrect delays if the X-Bar's payload delay is longer than than the System-C module's delay between BEGIN_REQ and END_REQ". Feel free to modify this to make it more clear, of course.
Another option, if you feel like implementing it (and don't feel any pressure to do this), is to save the payload delay and then check to see if it matches the delay between BEGIN_REQ and END_REQ. If it doesn't match (or at least if it is higher), then you could issue a "warn(...)". 
I think it's important to document this as one of the intricacies of the gem5-System-C bindings, but other than adding something to the comment, I'm happy with this patch.

Yes, I agree, its very important to document this. I updated the patch and hope it is clearer now.
I had the same idea about the warning, I will see if I manage to implement this.