topLevelOrigin is a weird name

[domenic]

I don't think we've ever used "top level" in a public API before.

We do have window.top though. Maybe topOrigin is a bit better.

Is there any way of referring to this by its actual function? For example its description says "This attribute is a string that indicates the origin of the top level payee web page." Could payeeOrigin work? (If not, that description is probably not great.)

[rsolomakhin]

I don't think we've ever used "top level" in a public API before.

Innovation? ;-)

For a bit of context, we want to distinguish between the origin of the top-level context and that of the sub-iframe within that called new PaymentRequest(). This can happen, for example, if https://mom-and-pop-shop.com embeds an iframe from https://payment-processing-corp.com in the checkout page. In this case, the topLevelOrigin is https://mom-and-pop-shop.com and the paymentRequestOrigin is https://payment-processing-corp.com.

[domenic]

Could you give an example of why this is a necessary capability for payment handlers? For example, do the basic-card or ApplePay payment handlers change their behavior based on top-level origin vs. PaymentRequest origin?

[rsolomakhin]

Could you give an example of why this is a necessary capability for payment handlers?

Google Pay whitelists the origins that are allowed to use it. (You can get on the whitelist by registering for a merchant account.) When working with large partners, it's simpler to whitelist a single paymentRequestOrigin, such as https://payment-processor.com, instead of 10,000 topLevelOrigins of the small shops that are using https://payment-processor.com.

do the basic-card or ApplePay payment handlers change their behavior based on top-level origin vs. PaymentRequest origin?

If the paymentRequestOrigin is not on the whitelist for Google Pay, it will not be displayed as an option in the payment sheet. Other partners have expressed the desire to also whitelist based on the topLevelOrigin.

[domenic]

Right, I understand the motivation for paymentRequestOrigin. The motivation for topLevelOrigin is less clear; I guess that's the "other partners". It seems strange to design a system that changes its behavior in that way based on who is embedding you...

[rsolomakhin]

Shall we mark topLevelOrigin at risk and ask around in Singapore whether payment handler writes would need it?

[domenic]

I dunno, I'm not an expert on writing payment handlers so I'm not sure how strongly my skepticism should be weighted. But starting conservative and gathering concrete customers before finalizing a feature makes sense to me as a general principle?

[rsolomakhin]

@anthonyvd: Could you solicit feedback on this in your payment handler break-out session at the next face-to-face?

[adrianhopebailie]

@domenic if a merchant.com uses paymentprocessor.com then the most reliable information that the payment handler can provide the user about who is being paid is the origin merchant.com.

I think there are two pieces of information that are important to the payment handler (and possibly the user of the payment handler):

1. Who is being paid
2. Who is processing the payment (accepting the payment request response)

Sometimes these are the same but sometimes they are different. This design accommodates the case when they are different.

[adrianhopebailie]

Some more context...

The PH needs to know:

1. So it can present this to the user during the authorization of the payment and/or make risk or business process related decisions about the payee (are they blacklisted? are they a specific category of merchant that is restricted? does the user have a discount coupon for this merchant? etc)
2. So it can make risk decisions regarding the payment itself and the user's privacy (do I trust this processor for this payment method? do I need to sign/encrypt the payment response and if so how? etc)

For some use cases simply requiring the origin will not be enough. If we can safely say that knowing the origin is not enough for any of these use cases then maybe we can take this out?

[anthonyvd]

Chatted about this at the F2F, it looks like this is just a naming issue rather than a use case issue. The group agrees that topOrigin is more appropriate.