[raverbashing]

You certainly don't want your service caring about a test currency.

Nobody is pricing their services in test currency

They are either pricing in $ or in "units" and then converting upstream

This is an even bigger foot gun than what's happening here

[skissane]

AWS supports billing in multiple currencies: https://repost.aws/knowledge-center/supported-aws-currencies

So how is it a "foot gun" to add XTS as an additional currency, for internal use only?

I presume AWS sets its prices in USD, and then converts them to the other currencies using the relevant exchange rate - the services themselves don't know about UAE dirham, but the billing system does. So XTS just becomes another exchange rate. You could even fix it as 1 XTS = 1 USD, although choosing a different exchange rate than parity is likely to surface more bugs.

[raverbashing]

> AWS supports billing in multiple currencies

Of course. I'm not saying that it doesn't.

Read it again

I'm saying, the conversion to (any) currency needs to be done downstream of the service (to a general billing service). The service needs to bill "credits".

> presume AWS sets its prices in USD, and then converts them to the other currencies using the relevant exchange rate

Yes that's what I wrote in the first post

[berkes]

> The service needs to bill "credits"

When talking about e2e tests, it matters where the e's are. If they are at the public interface of "the service", then, indeed, you'd test against "credits".

But ideally, there'd be e2e tests that test the consumers' experience, where the 'e's are the web interface, emails, CLI and other things consumers click on, read, enter etc. This is where a "test currency" makes sense.

[raverbashing]

Yup, this makes sense for e2e.

You can have your billing service billing in the test currency for e2e (and probably with a value that does not match the USD) so you can test "ok this should cost 1 credit so in the end I should have 18 $currency"