Support for negative amounts

[adrianhopebailie]

#101 changed the formatting rules for amounts so that the value is not signed (per the resolution of the group at w3c/webpayments#57).

Part of this PR is being reverted (See #120) to reflect the proposal by the @adrianba to use signed numbers as the mechanism for indicating negative amounts and/or refunds.

PR #111 proposes an alternative mechanism for annotating line items such that the flow of funds (debit or credit) is defined as an attribute of the PaymentItem. However, some commentors have suggested that the TramsactionType of a payment request should be defined at a global level for the request and not per line item so this PR needs to be tweaked and further discussed before it can be merged.

The motivation for using such a mechanism (as opposed to signed numbers) is that it conforms to financial industry norms and existing payment messaging standards like ISO20022 and ISO8583.

[kirkalx]

I'm wondering how this would fit in with payment methods that inherently do not support negative amounts (e.g. bitcoin). Would it be up to the Payment Mediator to recognize that the payment request is not compatible with that payment method? Or is the payment app forced to accept the payment request and try to achieve something logical?

[sideshowbarker]

I'm wondering how this would fit in with payment methods that inherently do not support negative amounts (e.g. bitcoin). Would it be up to the Payment Mediator to recognize that the payment request is not compatible with that payment method?

Yes that, I would think. Anything else would seem to not make sense.

Or is the payment app forced to accept the payment request and try to achieve something logical?

That would seem pretty absurd and I don’t see how it could be enforced anyway.

Regardless it seems like the spec needs to unambiguously state what the processing requirements are.

[webpayments-specs]

I think if you separate the total from the value / amount for items this
becomes clearer. The negative amount applies to items within the
collection of things being charged, not to the overall transaction. Or at
least that is what I think should happen. The total cannot be negative.
That makes no sense. But individual items can act as a discount.

NOTE: I know that in accounting you can have a negative amount that acts as
a credit memo. But this isn't a payment scheme for accountants. We are
not trying to handle refunds (at least not at this stage, and not as
payments).

On Mon, Apr 4, 2016 at 9:04 PM, Michael[tm] Smith [email protected]
wrote:

I'm wondering how this would fit in with payment methods that inherently
do not support negative amounts (e.g. bitcoin). Would it be up to the
Payment Mediator to recognize that the payment request is not compatible
with that payment method?

Yes that, I would think. Anything else would seem to not make sense.

Or is the payment app forced to accept the payment request and try to
achieve something logical?

That would seem pretty absurd and I don’t see how it could be enforced
anyway.

Regardless it seems like the spec needs to unambiguously state what the
processing requirements are.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#119 (comment)

Shane McCarron
Projects Manager, Spec-Ops

[halindrome]

(I tried to send this as email but I did it from the wrong address.)

I think if you separate the total from the value / amount for items this becomes clearer. The negative amount applies to items within the collection of things being charged, not to the overall transaction. Or at least that is what I think should happen. The total cannot be negative. That makes no sense. But individual items can act as a discount.

NOTE: I know that in accounting you can have a negative amount that acts as a credit memo. But this isn't a payment scheme for accountants. We are not trying to handle refunds (at least not at this stage, and not as payments).

[kirkalx]

Thanks halindrome, sounds good. So whether or not the total field is made separate (as in #111 for example), then the spec can make clear that it must be non-negative.

[halindrome]

If my assertion is correct, then yes. However, I have been confused about what is in the items object before ;-)

[rvm4]

I agree, negative items are likely to be inclusive taxes or discounts. Such things would never drop the total amount below zero. I also agree that negative amounts representing refunds should be out of scope at this point.

[corwinAmbre]

Refund would be done by the merchant and therefore not linked to a payment method available to him in his wallet (and it'll also imply other processes like customer support for instance).
In case of a total equals to 0, no transaction should be started with payment method at all but API should directly send "validated response". It may be tricky for security as call will be done from browser but not all payment methods will support transactions at 0 (and most of them may charge merchant even for free transaction).
Negative amounts should not be allowed through payment API. If total amount is negative, most probably it'll be transformed as a future discount inside merchant website and not a real transaction

[adrianhopebailie]

I wonder why we would enforce that that the total can't be negative?

Surely the ability to process a negative amount is entirely dependent on the payment method and since we are asserting that the browser has no knowledge of payment methods or how they work we should leave it to the payment app to figure out if this is an error condition or not.

[halindrome]

Interesting point. We would need to make it clear that payment methods are permitted to throw an error if they cannot handle negative amounts.

[corwinAmbre]

It could be a solution yes but I'm still wondering why a negative payment would be an option for a merchant except for refund. Having the possibility to call a negative amout in payment could create a high security risk for merchants as it would allow money to go back to the customer without prior check or control.
For refund, even if users could be able to ask for their order cancellation online, the refund process is mainly done asynchronously in back-end and is for the same payment method than the one used to pay. Allowing negative payments with the user who will decide which payment methods he wants to use would allow him to make an order with his credit card for instance and then launch refund on another payment account, moving transaction costs to the merchant instead of him.

[nickjshearer]

I wonder why we would enforce that that the total can't be negative?

...a negative amount is just describing an inverted payment request. If A requests a negative payment from B, then it follows that what's really happening is B is requesting payment from A. @halindrome's suggestion that sub-total items can be negative but the total itself cannot be seems more reasonable to me, as that would allow merchants to indicate things like discounts and the like to end users.

[kirkalx]

To be precise, A is requesting to pay money to B.

My main issue with a negative total is that this is incompatible with most (if not all) cryptocurrency payment methods, without reissuing the payment request in the opposite direction with a positive amount. This is because, for example, a basic bitcoin payment request might be represented as

{amount, currency unit, address}

A payment can be made to that address but it cannot come from that address. See https://en.bitcoin.it/wiki/From_address

[lyverovski]

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.

[adrianhopebailie]

@nickjshearer and @halindrome :

I asked the following because I wonder if we are trying to enforce business rules in the browser API which should be the domain of the payment apps:

I wonder why we would enforce that that the total can't be negative?

Any restrictions we place on the data that can be passed in the API implies we know enough about the uses of the API to do so. As @kirkalx points out this may not make sense for some payment methods but that doesn't mean it might not make sense for others.

I don't believe it is the job of the browser to enforce this business rule. If a payment method declares that it supports negative amounts and they will be interpreted a certain way then why should the browser prevent this?

[adrianhopebailie]

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.

[adrianhopebailie]

Resolved in PR #168

Awaiting proposals for transaction types, either per payment method or as a proposed change to the API