ECC is mostly used for signing stuff and we couldn't find a way to use it for encryption/decryption.
It is possible to use ECC with an integrated encryption scheme (IES), where a single-use symmetric key is generated using a secret based on a public key, in such a way that only the holder of the private key can re-derive the secret and thus the symmetric key. The message is then encrypted using the symmetric key, which is subsequently discarded; the only data stored/transmitted are the ciphertext (with metadata such as IV/nonce and integrity tag) and a value computed using the recipient's public key. This is a hybrid cryptosystem rather than directly encrypting using asymmetric crypto, and requires agreement on the IES parameters, but it's secure, works on arbitrary-size messages, and is tolerably performant (certainly better than RSA with very large keys). I don't know how widespread support for it is, though, especially in hardware tokens.
I'm skeptical that your users will accept this scheme, though. Needing to carry a hardware token rather than just remember a password is a big step up, and while it's one that security experts have been pushing for years (security tokens can protect against attacks not even the best password is proof against), adoption has been terrible. Meanwhile, tons of companies store literal payment information - credit/debit cards or bank account+routing numbers, to say nothing of things like digital (or physical) gift cards, coupon codes, and loyalty points - not to mention the actual prices that will be charged - and don't generally have a problem with people stealing the DB full of payment-ready info and running off to get rich with it.
Given all that, this feels like massively overcomplicating things. Let's suppose, against all likelihood, that the value of these vouchers is one million USD, a life-changing amount for most people and sorely tempting even for those with cushy software engineering jobs, but scarcely worth nation-state interest. It's also easily enough to be worth taking some basic precautions with, like creating an audit log of when each voucher is created and who it's created for and in what amount and with what expiration and so on. Any attempt to redeem the voucher should obviously consult the log to ensure the voucher and amount is valid, and log the attempt (succeed or fail) so that the voucher can't be used again or anything like that (beware the time-of-check/time-of-use race condition). Permission to create or read log entries should be tightly limited to the services that need it, and permission to edit or remove them shouldn't exist at all.
Now, you might be objecting "hey, that's not as secure as end-to-end asymmetric encryption with hardware-resident private keys!" but in practice, it really is. An attacker who can edit the log directly can almost certainly also carry out other attacks, such as modifying a legitimate user's public key such that the voucher is encrypted to the attacker's public key instead (and hence decryptable by the attacker), or modifying the system to generate a voucher for the attacker even though they aren't eligible, or modifying the system to make it always give the attacker the voucher's deal, or modifying the system to pass on every token generated to the attacker too, or extracting the voucher-generating code and running it directly, or several other equivalent attacks. You need either to actually prevent insider threats, or to accept the risk.
The security measures to prevent these attacks are all the same, and in common use in software enterprises: mandatory code reviews before merge, restricted access to the production environment, no ability to deploy code directly, pervasive monitoring/logging/alerting of suspicious activity, etc. Combine with measures that are truly standard operating procedure, such as using TLS (to prevent man-in-the-middle attacks) and encryption at rest (to prevent attackers from stealing DB drives or backup tapes and reading secrets out of them), and you've prevented all the attacks you were worried about, and more besides (which your proposed solution wouldn't have addressed, at least not alone).