In order to set up a payment channel between a sender and a receiver, the two parties must first agree on three parameters for the channel:

1. sender public key
2. receiver public key
3. channel expiration date

These parameters are contained in ChannelParameters, from which a channel funding address can be derived using getFundingAddress. The transaction which pays to this address is the channel funding transaction, and information about it is contained in a FundingTxInfo. So, the channel funding transaction will contain an output which pays to the address returned by getFundingAddress, and once this transaction is created and in the blockchain, a SenderPaymentChannel and ReceiverPaymentChannel instance can be created, after first creating the FundingTxInfo instance. FundingTxInfo contains three pieces of information about the funding transaction:

1. hash/transaction ID
2. index/vout of the funding output (paying to getFundingAddress address),
3. value of the funding output (paying to getFundingAddress address)

With ChannelParameters and FundingTxInfo, the sender can create a new SenderPaymentChannel, plus the first channel payment, using channelWithInitialPaymentOf. channelWithInitialPaymentOf takes two additional arguments:

1. a signing function which, given a hash, produces a signature that verifies against cpSenderPubKey in ChannelParameters
2. the value of the first channel payment

The sender will want to use flip signMsg senderPrivKey as the signing function, where senderPrivKey is the private key from which cpSenderPubKey is derived. channelWithInitialPaymentOf will return the first channel Payment as well as the new SenderPaymentChannel state. The new state is stored, and the Payment transferred to the receiver.

The receiver will now create its own channel state object, ReceiverPaymentChannel, using channelFromInitialPayment. channelFromInitialPayment takes the same ChannelParameters and FundingTxInfo as was provided by the sender, and, in addition, the receiver signing function (used to produce the settlement transaction that closes the payment channel), and the first channel Payment, received from the sender. The receiver will want to use flip signMsg receiverPrivKey as the signing function, where receiverPrivKey is the private key from which cpReceiverPubKey is derived.

Now the payment channel is open and ready for transmitting value. A new Payment is created by the sender with sendPayment, which yields a new payment, that increases the total value transmitted to the receiver by the specified amount, and an updated SenderPaymentChannel state. The receiver will verify and register this Payment on its side using recvPayment, which, on success, returns the value received with this payment plus the updated ReceiverPaymentChannel state object.

Payments can flow from the sender to receiver until either the channel is exhausted, or getting close to expiration (see important note below). In either case the receiver will use getSettlementBitcoinTx to create the settlement Bitcoin transaction, and publish this transaction to the Bitcoin network. The settlement Bitcoin transaction pays the total value transmitted over the channel to the receiver and the rest back to the sender.

IMPORTANT: Channel setup is risk free because the sender can derive a refund Bitcoin transaction using getRefundBitcoinTx, which returns the bitcoins used to fund the channel back to the sender. This refund transaction, however, is not valid until the expiration date specified in ChannelParameters, but it is paramount that the value receiver gets a settlement transaction included in a block before the refund transaction becomes valid. Due to the fact that Bitcoin network time is allowed to drift up to two hours from actual time, and the fact that finding new Bitcoin blocks does not occur according to any schedule, it would be wise for the receiver to publish a settlement transaction at least 4 hours before the specified channel expiration time, and possibly earlier, if the receiver wants to be cautious.