Re: [w3c/browser-payment-api] Remove issue #119 note and assert that total should be non-negative (#168)

+1 to merge

I think this is is the best approach to this issue. 

Passing a negative amount to payment systems is very dangerous because traditionally they only deal in unsigned numbers and use transaction types to decide if the settlement effect of the transaction is a debit or credit.

> For the first version of the specification, I propose that we shouldn't try to address the meaning of a negative total. Changing the direction of the payment request and supporting things like refunds should be out of scope (at least for now).

I would assert that it should never be in scope. This API shouldn't require any more knowledge about how a payment is processed than it does already. We have resolved to push the concept of transaction types to the payment method and I hope we stick to that.

I had previously asserted that it seemed like a bad idea to enforce these kinds of business rules (no negative amounts) at the API layer but after a conversation with @lyverovski it was pointed out that if we leave it to the payment method to define what a negative amount means, then merchants that wish to submit a request that can be processed by multiple payment methods are unable to decide if they should use a negative number or not (one payment method may require it and another may use a transaction type defined in the payment method data).

By not allowing negative numbers in the total we avoid this entirely and payment methods are free to assume they will always get a positive number and can define custom data like transaction types to facilitate refunds or other credits.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/pull/168#issuecomment-215662761