Should PaymentResponse include totalAmount and if so must it be one of the supplied totals

[adrianba]

PR #211 introduced the idea of including the totalAmount in the PaymentResponse. The idea is that since different totals can be provided using PaymentDetails.total and PaymentDetailsModifier.total then the user agent should include which one was chosen in the response.

There was some discussion of this on the telcon today.

I think there are three options to consider:

1. Leave the spec as is; or
2. Remove totalAmount from PaymentResponse; or
3. Leave totalAmount but remove the text that requires that the value be one of the provided totals.

My preference is (1) or (2). I don't mind which.

[ianbjacobs]

Hi @adrianba,

In the payment app task force we've been discussing scenarios where a payment app might change the total before the user authorizes payment, for example after application of a discount. Presumably if this is possible in the payment app, it's because the app distributor
and the merchant have a private agreement that this is ok.

In this case, the "authorized total" may not be one that the merchant sent to the payment app.

If we anticipate this scenario, then:

• The spec should not constrain the total to be something that the merchant provided.
• The spec should advise the merchant to check the total that was sent back in the response.

So that would lean toward your option 3 (if I understood correctly).

Even if we wanted to say "payment apps much not change totals" I'm not sure we can
stop them in practice from doing so. So merchants should check the response.

Ian

[adrianhopebailie]

• I think there is value in having the authorized amount in the response. This is common in most payment message standards today
• I agree with @ianbjacobs reasoning above for not constraining this.

So, my preference is for 3 but would be okay with 2.

[msporny]

So merchants should check the response.

How do merchants know the response wasn't tampered with in transit? That is, if we're putting the total in there so the merchants can feel safe that the amount requested was the amount paid (and we have no MiTM protection on totalAmount), doesn't that defeat the purpose of including the value in the response?

[ianbjacobs]

@msporny wrote:

How do merchants know the response wasn't tampered with in transit?

I assume that payment apps that wish to provide additional guarantees can use digital signatures generally. I would not expect the API to have built-in support for digital signatures.

That is, if we're putting the total in there so the merchants can feel safe that the amount requested was the amount paid (and we have no MiTM protection on totalAmount), doesn't that defeat the purpose of including the value in the response?

It seems to me that in many or most cases the merchant-sent total (call it "T") will be the same as the total received in the payment response. So a check that the response includes "T" would make a strong case that no tampering has occurred.

[dlongley]

So a check that the response includes "T" would make a strong case that no tampering has occurred.

I would always send "T" then when I wanted to fool the merchant. :)

[ianbjacobs]

What data would convince the merchant? That data can be signed, of course.

Ian

[dlongley]

What data would convince the merchant? That data can be signed, of course.

Signed data or some kind of transaction ID that they can check via PSP, etc. I don't think just getting a value in (with no security around it) will work.