PaymentRequest Mojo bindings.

components/payments/payment_request.mojom

Index: components/payments/payment_request.mojom
diff --git a/components/payments/payment_request.mojom b/components/payments/payment_request.mojom
new file mode 100644
index 0000000000000000000000000000000000000000..2332490db9ae7d58371695876f0e61ac92800121
--- /dev/null
+++ b/components/payments/payment_request.mojom
@@ -0,0 +1,67 @@
+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+module payments.mojom;
+
+struct ShippingAddress {
+  string region_code;
+  array<string> address_line;
+  string administrative_area;
+  string locality;
+  string dependent_locality;
+  string postal_code;
+  string sorting_code;
+  string language_code;
+  string organization;
+  string recipient;
+};
+
+struct PaymentResponse {
+  string method_name;
+  string stringified_details;

[palmer, 2016/03/08 22:49:36]

This is vague and weakly-typed. Can you document what goes in here, or split out
the details into separate fields, or use richer types?

[please use gerrit instead, 2016/03/10 00:38:05]

I've documented stringified_details and stringified_data. How does it look to
you?

+};
+
+interface PaymentRequestClient {
+  OnShippingAddressChange(ShippingAddress address);
+  OnShippingOptionChange(string shipping_option_id);
+  OnPaymentResponse(PaymentResponse response);
+  OnError();
+  OnComplete();
+};
+
+struct CurrencyAmount {
+  string currency_code;

[palmer, 2016/03/08 22:49:36]

currency_code, region_code, language_code, et c. feel more like enums than
strings, to me. It's good to keep IPC messages as type-constrained as possible.
(https://www.chromium.org/Home/chromium-security/education/security-tips-for-ipc)

[please use gerrit instead, 2016/03/10 00:38:05]

Done.

[haavardm, 2016/03/10 12:46:57]

I'm skeptical about enuming any of the input from the JS api, as long as the
spec is not enuming them. What if new currency codes are created (think new
bitcoin like inventions).  I don't think chromium should add restrictions like
that and I think it's best if currency code is passed unchanged to the payment
app. I'm not sure I see the security problems for these strings as they are not
blogs of data, they are pure string values. 

+  string value;

[palmer, 2016/03/08 22:49:36]

Hmm, a string for money feels odd. Why not use a tuple of ints?

struct CurrentAmount {
  string currency_code;
  int64 units;
  int16 thousandths;
};

[please use gerrit instead, 2016/03/10 00:38:05]

Done.

[haavardm, 2016/03/10 12:46:57]

The payment request api defines it as string, so I'm not sure blink should
redefine that. It's up to the payment app to interpret the string:
https://github.com/w3c/webpayments/issues/40 

+};
+
+struct PaymentItem {
+  string id;
+  string label;
+  CurrencyAmount amount;
+};
+
+struct ShippingOption {
+  string id;
+  string label;
+  CurrencyAmount amount;
+};
+
+struct PaymentDetails {
+  array<PaymentItem> items;
+  array<ShippingOption> shipping_options;
+};
+
+struct PaymentOptions {
+  bool request_shipping;
+};
+
+interface PaymentRequest {
+  SetClient(PaymentRequestClient client);
+  Show(array<string> supported_methods,
+       PaymentDetails details,
+       PaymentOptions options,
+       string stringified_data);
+  Abort();
+  Complete(bool success);
+};