Re: [w3c/webpayments-methods-card] Say how we integrate with PaymentRequest (#23)

marcoscaceres requested changes on this pull request.



> @@ -180,6 +185,22 @@
       </p>
 
       </section>
+
+      <section>
+      <h3>Processing incoming payment method data</h3>
+
+      <p>When the PaymentRequest API is to pass data to a payment app supporting basic-card as part
+      of the <a>paymentRequest.show()</a> algorithm, the payment app must process any non-null

Also, it's not just .show(), it's also, "canMakePayment()"

> @@ -222,6 +243,14 @@
       </dl>
 
       </section>
+
+      <section>
+        <h3>Providing outgoing payment responses</h3>
+
+        <p>When the <a>user accepts the payment request algorithm</a> runs in the context of a
+        payment app supporting basic-card, the payment app must provide back the relevant data in a
+        <code>BasicCardResponse</code> dictionary.</p>

nit: s/`<code>`/`<a>`

> @@ -222,6 +243,14 @@
       </dl>
 
       </section>
+
+      <section>
+        <h3>Providing outgoing payment responses</h3>
+
+        <p>When the <a>user accepts the payment request algorithm</a> runs in the context of a
+        payment app supporting basic-card, the payment app must provide back the relevant data in a
+        <code>BasicCardResponse</code> dictionary.</p>

Is there a chance that converting from a random app to a BasicCardResponse would fail? If so, should we reject? 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-methods-card/pull/23#pullrequestreview-39943264