Also a little more frontend to handle possible failure modes

Connections could probably be in a per-thread cache or something but
redemption costs are going to dwarf database opening costs.

Also, filesystem caches and no benchmarks and all that.

They have weird names in the Stripe API but there's no reason to preserve
that.

transaction rollback logic relied on exceptions, stripe charge function
signaled failure with Either, thus stripe failues had no effect on transaction
rollback

`catch` is not a good way to assert something is thrown

A POST to the charge endpoint is not actually a simple request according to
the CORS spec but this demonstrates that the CORS middleware at least fits in
place.

The next step is to replace simpleCors with a policy that's compatible with
use of our endpoint.

This is to make sure that we don't leak keys in the argument and hence
in logs etc.

let more "fixed" parameters come first and then the dynamic ones so
that one can do currying with the immutable parameters applied.

Stripe developer dashboard provides a few keys and we specifically
need to use the secret key.

If for "some reason" Stripe servers returned a mismatched voucher
code, return http 500 status.

Mark the voucher as paid if the stripe charge API returns a Charge
object.