Payment-request: Are integer values for PaymentCurrencyAmount.value left as integers?

[ianbjacobs]

Hi @marcoscaceres, @rsolomakhin, @adrianba,

I was asked today whether integer values (PaymentCurrencyAmount.value) are preserved as integers, or whether ".00" is appended by implementations.

I don't see anything in the algorithm [1] about this type of conversion. I think the desired behavior is "if you get an integer, leave it as an integer."

Is that how implementations behave today?
Should the spec say anything different?

Thanks!
Ian

[1] https://w3c.github.io/payment-request/#validity-checkers

[rsolomakhin]

We append decimals based on the currency. Japanese Yen does not have decimals, for example. However, if the merchant specifies fractions of a cent, we preserve it. We're using ICU library for this. Our code:

https://cs.chromium.org/chromium/src/components/payments/core/currency_formatter.h

[ianbjacobs]

On Sep 18, 2017, at 11:09 AM, Rouslan Solomakhin [e-mail] wrote:

We append decimals based on the currency. Japanese Yen does not have decimals, for example. However, if the merchant specifies fractions of a cent, we preserve it.

If I were to type “10” in USD, would the merchant receive “10” or “10.00”?

Ian

We're using ICU library for this. Our code:

https://cs.chromium.org/chromium/src/components/payments/core/currency_formatter.h

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

--
Ian Jacobs [e-mail]
https://www.w3.org/People/Jacobs/
Tel: [phone]

[rsolomakhin]

Our formatting is for display only. The payment app receives the raw amount string. (The amounts defined as strings in the API.)

[ianbjacobs]

Ok, thank you.

Should we say in the spec something like "Do not transform valid values?"

Ian

[rsolomakhin]

I think it would be sensible for the payment handler spec to clarify that the "total" amount must not be modified from what the merchant sent in any way.

[marcoscaceres]

Yeah, we could add a note. The spec (and tests!) is certainly clear that implementations shouldn't change the values (but can be formatted for display however is appropriate, of course).

[ashokmisra]

If I were to type “10” in USD, would the merchant receive “10” or “10.00”?
Not sure if this was answered explicitly. Seems like the merchant would receive 10.00. I believe most processors deal with auth/charge amounts as positive integer in the smallest currency unit i.e. to auth 1 USD you need to send '100' and to auth 100 JPY, 100 needs to be sent.
So is there any harm in using the convention most payment processors follow ?

[marcoscaceres]

If I were to type “10” in USD, would the merchant receive “10” or “10.00”?

10 goes to the API - not to the merchant.

For "basic-card", "USD" and "10" is formatted a "USD$10" or whatever the OS convention is.

For a tokenized payment handler, it will need to interpret "US" and "10" appropriately. It's outside the scope of the API. We don't touch the values or change them... we only validate them.

Seems like the merchant would receive 10.00

In the case of basic card, the merchant gets a credit card details - and it's their responsibility to charge the correct amount.

In the case of a tokenized payment, see above.

So is there any harm in using the convention most payment processors follow ?

It's the merchant's responsibility to manage currencies and values. Same reason we don't sum up totals, etc.