user62184: Let's observe direct unidirectional lightning channel between Alice and Bob.
How does this start technically:

They first create a 2-2 address C.
They agree on the funds Alice will put into C, say 1BTC.
Bob makes a "conditional refund 2-2 transaction" that has 3 conditions:
a) if Alice put 1BTC into address C
b) if nLock time passed between the time she put money in
c) in no transaction was made from C and put on blockchain
then Alice gets 1BTC back from this address.
He signs that transaction and sends to Alice. Alice can sign and broadcast this transaction after nLock time to retrieve her 1BTC if a) b) and c) are fulfilled.
Alice now puts 1BTC into 2-2 address C.

EDIT: Can you confirm each step.
For example: Is step 2 needed, or can Bob in step 3 just say if nLock time passed and no transaction was put on blockchain from C, whoever put money in C gets its money back in full amount.

user5152: Yes .
I like this video as well, explaining the u and b directional channel.
The Lightning Network Explained (Litecoin/Bitcoin) 

user29432: Many different approaches for payment channels exist. They differ in the way that refund from the payment channel is guaranteed. 
One solution is having Bob to send Alice presigned but timelocked refund transaction, which simply spends from C (from output that Alice will use to fund C) and refunds Alice. As you say the amount must beforehand be agreed upon so that it is correctly reflected by the presigned refund transaction; but it is not necessary to make any conditional checks as you mention them in step 3 since if C's coins have been already spent or not allocated at all the refund transaction will immediately be invalidated. After Bob sends Alice the refund transaction, then Alice can make a funding transaction.
Alternatively for unidirected payment channels, Alice could make use of a more complex contract using OP_CHECKSEQUENCEVERIFY (https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki). The contract would be something like in the example "Escrow with Timeout" but without the 3rd-party Escrow and only using Alice and Bob. In this way Alice would be assured that no matter how much she initially funds the payment channel, she will be solely able to spend from it again in the future at a time she specifies within the contract. There would therefore not be a need for a presigned refund transaction.
Updating the state of the payment channel is similar in both cases.

62184: <p>Let's observe direct unidirectional lightning channel between Alice and Bob.</p>

<p>How does this start technically:</p>

<ol>
<li>They first create a 2-2 address C.</li>
<li>They agree on the funds Alice will put into C, say 1BTC.</li>
<li><p>Bob makes a "conditional refund 2-2 transaction" that has 3 conditions:</p>

<p>a) if Alice put 1BTC into address C</p>

<p>b) if nLock time passed between the time she put money in</p>

<p>c) in no transaction was made from C and put on blockchain</p>

<p>then Alice gets 1BTC back from this address.
He signs that transaction and sends to Alice. Alice can sign and broadcast this transaction after nLock time to retrieve her 1BTC if a) b) and c) are fulfilled.</p></li>
<li>Alice now puts 1BTC into 2-2 address C.</li>
</ol>

<p>EDIT: Can you confirm each step.</p>

<p>For example: Is step 2 needed, or can Bob in step 3 just say if nLock time passed and no transaction was put on blockchain from C, whoever put money in C gets its money back in full amount.</p>
 5152: <p>Yes .
I like this video as well, explaining the u and b directional channel.
<a href="https://www.youtube.com/watch?v=MpfvhiqFw7A" rel="nofollow noreferrer">The Lightning Network Explained (Litecoin/Bitcoin)</a> </p>
 29432: <p>Many different approaches for payment channels exist. They differ in the way that refund from the payment channel is guaranteed. </p>

<p>One solution is having Bob to send Alice presigned but timelocked refund transaction, which simply spends from C (from output that Alice will use to fund C) and refunds Alice. As you say the amount must beforehand be agreed upon so that it is correctly reflected by the presigned refund transaction; but it is <em>not</em> necessary to make any conditional checks as you mention them in step 3 since if C's coins have been already spent or not allocated at all the refund transaction will immediately be invalidated. After Bob sends Alice the refund transaction, then Alice can make a funding transaction.</p>

<p>Alternatively for unidirected payment channels, Alice could make use of a more complex contract using OP_CHECKSEQUENCEVERIFY (<a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki" rel="nofollow noreferrer">https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki</a>). The contract would be something like in the example "Escrow with Timeout" but without the 3rd-party Escrow and only using Alice and Bob. In this way Alice would be assured that no matter how much she initially funds the payment channel, she will be solely able to spend from it again in the future at a time she specifies within the contract. There would therefore not be a need for a presigned refund transaction.</p>

<p>Updating the state of the payment channel is similar in both cases.</p>
