4 ms·

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 "unit

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 3mo ago
AWS supports billing in multiple currencies: https://repost.aws/knowledge-center/supported-aws-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 3mo ago
  > 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 3mo ago
    > 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 3mo ago
      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"

skissane 3mo ago

AWS supports billing in multiple currencies: https://repost.aws/knowledge-center/supported-aws-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 3mo ago
> 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 3mo ago
  > 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 3mo ago
    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"