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.

Read the integer value out of the amount string

Generate recognizable unpaid and double-spend responses

Pass paths to secrets in commandline arguments instead of secrets

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

Expose a browser facing API for creating Stripe charges

When the nixpkgs revision was bumped, the stack version in use was bumped.
The newer stack version uses a different cache layout and can't find any of
the cached artifacts in the old cache.

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.