Sum-based sliding rate limiting with Redis and Lua
There might be one correctness issue here: 

If a customer makes just one purchase all week with the transaction amount exceeding the cap, do you still want to throttle the transaction? Just wanted to bring that up in case you missed this corner case.

Since you talk about performance, you will want to consider which of the two are important to you: 


request latency - each request completing within a fixed time
throughput - number of requests served from the cache in a time period.


You can have higher latency, but still maintain a high throughput as long as the transactions are not serialized.

One suggestion I had that might help with both is that you can pull the following:

--[[
Cleaning up old entries up to @minSecond (in our example,
minSecond = Now (Epoch time in secs) - 604800 (nb of secs in a week)):
--]]
redis.call('ZREMRANGEBYSCORE', userKey, '-inf', @minSecond) 


outside into a separate call or issue it lazily.

Lazy techniques can be:


GC once every 'N' calls,
run GC as a cron / batch job once a day for all customers
Do GC only if the size of the sorted set is greater than a fixed threshold 


This will make individual transactions potentially faster at the expense of a larger memory footprint.

This might have some performance implication, so I would do some benchmarking just for that one call. 

If you're okay with being slightly inaccurate about the cap on spending per customer, there are two things you can potentially play with:


Use Exponential Moving Averages. This will allow you to not do a range query on the sorted set, and instead do a constant time query. There's plenty of resources on this topic on the inter-webs.
Use daily aggregates. Whenever you get a query, you will need to look-up exactly 7 key-value pairs. Ofcourse this will not work if you want precision.


Otherwise, your existing approach will get the job done.