Fabric transaction workflow

The basic flow of fabric transactions:

1.  Users of the blockchain send request for a transaction to one or couple of peers This is called transaction proposal. 
2. Peers simulate the transaction using chaincode, parameters and state of the ledger and return read-write set (delta of changes result from simulation). This is called endorsement response and is with peer individual crypto key. The endorsement response is sent back to users by peers.
3. Then those endorsement responses are sent by users to ordering service, they are validated for authenticity, spending problem and against different policies, and if result is OK, this is called transaction validation, then this read-write set is send to peers to update the ledger and the database.

So you can send transaction proposal to peers in orgA and orgB and got there endorsement responses and decide do you want to send them to orderer. If you execute transaction proposal and got endorsement results, but stop here (not send them to orderer) no changes will be made to the ledger.

In endorsement results you have identities (peers and there organization), so you can create logic to push the results to orderer or to stop the transaction and you can identify who is the initiator of the
request etc.

Also in version 1.1 there is more elegant solution for this - system chaincode plugins. If I am not wrong there will be the option to plug your custom system chanicode (plugins) in runtime (using golang) and those plugins will have low level access to the data and the flow so you will be able to execute custom logic in different part of the process.