Here is one possible idea that I believe is almost what you want and quite likely (or so I hope!) both good enough and actually particularly good by incentizing all involved parties to collaborate to that goal. The basic idea is to incentize the recipient to sign for reception in a way that prevents him from lying just to collect the incentive.

Use multisig Bitcoin transactions, where the sender sends bitcoin into a multisig address requiring four distinct signatures, one from each party and a special throw-away one. The sender also performs his signature, authorizing a payment to the other two parties (say worth 9 dollar to the courier and 1 dollar to the sender) in a way that not only all other parties have to sign it, but beyond that yet another signature by the sender is required (using a fresh bitcoin address the sender generated only for this message). Instead of keeping the private key, the sender uses the public key of the recipient to encrypt the private key into a cyphertext that only the receiver can decrypt. This is possible with the ECC keys underlying bitcoin, although they are used in bitcoin in a different way, to generate signatures (but alternatively any other asymmetric crypto can be used, e.g. PGP/OpenSSL).

This way, only by completing the delivery can the payment proceed, and the sender cannot withdraw from his commitment anymore. It falls slightly short of what you desired (all payment going to the courier) because without an incentive to bother decrypting and finalizing the payment, it is likely that the recipient simply will not bother, creating significant risk to the courier of not getting paid. But with an incentive, and no means to change the split fraction, we can expect the recipient to usually (and with sufficient incentive, almost always) collaborate, which reassures the courier to go along with the scheme.

The obvious drawback of this scheme is that it requires off-blockchain communication, because (unless I am mistaken), partially signed multsig transactions do not get propagated across the network, and because of the encryption involved in transfering the private key to the fourth bitcoin address. Also, if you were not talking about a physical courier service, this solution does not apply, because having an encrypted communication channel to a sufficiently authenticated recipient (such that the sender already trusts sending to that person) implies that you can already pass any message without a courier as intermediary.

A maybe less obvious drawback is that the cypthertext attached to the message to be delivered must not be easily separated from the two, or your courier (or the wild west bandit robbing him) could just do that, and have only the ciphertext, not your message delivered in the hope that the recipient will collaborate in hiding the nondelivery by signing for collecting the incentive anyways. With digital messages, this can be achieved (e.g. xor the ciphertext with a hash of the message), but then again, for purely data-based messages, you do not need the courier if you have everything necessary for this scheme.

Seth wants to send Martha a message and is willing to spend 10 BTC to see it delivered. Charlie is happy to deliver it from South Dakota to Michigan at that price. Seth would like to ensure the message is delivered and Charlie wants to ensure he gets paid for his trouble.

They could do the following;

• Seth signs and encrypts the plaintext message (m1) to Martha into a cyphertext message (c1) using Martha's public key and his private key.
• Seth further encrypts the cypher text message with a nonce (n1) into a new cypertext message (c2)
• Seth builds a bitcoin transfer (t1) and adds the nonce (n1) to the transfers comment section and signs it. (t2)
• Seth then encrypts the signed transfer and nonce (t2) with Charlie's public key into a new message (t3).
• Seth then encrypts both the encrypted transfer (t3) and the nonce encrypted message (c2) with Martha's public key. This final package is good for shipping (c3)
• Charlie takes our package to Martha, it's a long trip but the 10btc is worth it.
• Martha decodes the package (c3) into it's parts the encrypted transfer (t3) and nonce encrypted message (c2)
• Martha gives Charlie the encrypted transfer (t3)
• Charlie decrypts the encrypted transfer (t3) into the a signed transfer and nonce (t2)
• Charlie tells everyone on the plant about the transfer (t2) including Martha. He wants to do this so people know he has the money.
• Martha takes the transfer (t2) and extracts the nonce (n1) and uses it to decrypt her message (c2) into the signed message (c1)
• Martha then decrypts the message (c1) again with her private key and gets Seth's letter (m1)

Lets see if I can make this a truth table;

Seth

(m1, seth_pk, martha_pub) => c1
(c1, n1) => c2
(t1, n1, seth_pk) => t2
(t2, charlie_pub) => t3
(t3 + c2, martha_pub) => c3

Martha

(c3, martha_pk) => t3, c2

Charlie

(t3, charlie_pk) => t2

Martha

(t2) => t1, n1
(n1, c2) => c1
(c1, martha_pk) => m1