> The API should not support negative amounts/signed numbers. Amounts are typically reflected as positive, unsigned values, and their behaviour (i.e. debit/credit) should be governed by the transaction type itself. > > Payment requests, along with fees, taxes, and discounts are typically modelled as separate transaction types (and/or as sub-types of a parent payment transaction). Refunds, and reversals (such as fee refund, tax refund, and discount refund) of those items should be different transaction types altogether, with a "credit" behaviour. However, these are likely outside the scope of the PaymentRequest, and are handled directly from the merchant to the customer. Personally, I agree with you as someone that is familiar with this approach in most payments messaging. But right now we seem to be leaning toward transaction types being the domain of each payment method. See #19 and provide your feedback if you disagree. So if we don't support the total being negative then it would imply that each payment method must define a custom data model to specify transaction types. Not a terrible solution but I think we should see this in a proposal (perhaps the standard card types should be proposed as a PR to the basic card payment spec as an example?) before we enforce business rules like this at the API data model level. --- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/w3c/browser-payment-api/issues/119#issuecomment-214391089
Received on Monday, 25 April 2016 15:24:07 UTC