What is the best way to implement micropayments with Ripple?

Question

I'm interested in the following use cases:

1. Web content
2. Voice and media traffic

For the first case, it would be ideal to be able to include some sort of proof in a custom HTTP request header showing that the client has made the payment. The server should be able to check this proof and verify that the payment has indeed been made, and then reply with the requested resource or return an error.

It may be a payment (required), or it may be a donation/tip (voluntary); in the latter case the server may collect these and verify them later.

For the voice and media case, the idea is to incentivize independent relay nodes to forward traffic for clients behind NAT/firewall or simply those who wish to add a layer of anonymity (similar to Tor). Again, these could be "metered" payments (e.g. 0.0001 XRP per 10 MB, or say for 30 minutes), or they could be tips. The speed would be extremely important in this case.

As I understand it, there are two ways to do micropayments:

1. On-ledger: These are payments made on the ledger and verified by the recipient using the transaction ID. This may be too slow, depending on the use case.

2. Signed transactions: Here the sender simply sends a signed transaction to the recipient, who can verify instantly if the sender has sufficient funds. Double-spending is possible in this case.

What would be ideal is if we could generate some sort of bearer token that could be passed around over multiple payments before it is finally redeemed on the ledger.

It would be even more awesome if these bearer tokens were anonymized using blind signatures.

Has anyone implemented micropayments with Ripple, and are there any guidelines/recommendations on how to go about it?

Answer 1

Pre-signed transactions won't work the way you want due to how Ripple uses a simple sequence number. The only downside to doing small transactions via Ripple is the 0.000010 XRP transaction fee and the 2-20 seconds (or so) delay between signed ledgers.

Normally a merchant generates the payment information. E.g. "send 1 USD to account A, destination tag 123 (any 32 bit number), invoice ID 0x12345678 (256 bits of data)", often this would be with a Ripple URI (note that page doesn't document how or if an invoice id can be specified in a Ripple URI). The customer then selects the URI and is taken to the send page in their configured client (currently now always ripple.com/client) with all that information pre-filled in. The merchant then listens on their connection to a Ripple server (either local or remote) for information on payments to their account and uses the destination tag and/or invoice id to update payment status for individual customers or invoices. Normally merchants should handle the possibilities of one invoice being paid via multiple transactions and overpayments or the like as well.

You could have the customer provide the transaction hash(es) as you suggest, but that's not normally done and is usually more work for the customer for no reason.