Two important parts of lightning invoices are preimages and payment hashes. A preimage is 32 random bytes. When you hash it you get a payment hash. The payment hash is explicit in the seller's invoice and he gives to the buyer so he can pay the invoice with his lightning wallet. The buyer effectively "purchases" the preimage by sending a payment to an HTLC which says that the seller can withdraw the money from that HTLC only if he discloses the preimage to the buyer and signs the transaction with his private key. If he doesn't do that, the sender gets his money back after two weeks because of a timelock. The preimage + the invoice itself constitutes a proof of payment, because once the buyer has both, he must have deposited the money into the HTLC and that HTLC must have been settled by the seller (i.e. he withdrew the funds).

What we do for lightning escrow is, we generate the preimage and don't disclose it to the seller. We just give him the payment hash. He uses that payment hash to generate an invoice. The buyer attempts to send money into the HTLC containing that payment hash but the seller cannot withdraw the money without disclosing the preimage, which he doesn't have because our company keeps it secret. He can, however, acknowledge that the escrow contract is funded -- but he cannot withdraw the funds without the preimage.

What we do then is, if after 10 business days neither party has opened a dispute, we disclose the preimage to the seller, who then uses it to withdraw his money. If there is a dispute, we investigate and may either decide to give the preimage to the seller -- thus settling the invoice -- or withhold it, which causes the payment to automatically cancel once 2 weeks pass.

So we do escrow without taking custody of the money. We don't even have to run a lightning node on our server :D

The original version of the backend protocol is free and open source: http://github.com/supertestnet/hodlcontracts

I am currently revising the protocol and will release a new free and open source version when it is ready.

this eventually needs to be decentralized, right?

I don't think decentralized escrow is possible. The best I could probably do in the future is a federated oracle, where a group of people (e.g. 11 of 15) have to agree that some real world event happened in order to release the funds. But federations also have their downsides compared to just picking one person to trust.

Instead of making a decentralized escrow, what I hope happens is that lots and lots of people run an escrow service so that bitcoiners can choose from among them. Imagine if Marty Bent, Matt Odell, Stephan Livera, and many others all ran an escrow service and you could create an escrow contract using any of their nodes as the trusted party. (All non-custodial of course.) A bunch of independent centralized escrows could perhaps be just as good as one decentralized one.