From 7bcb32411fe69a74052867ea07b5f6439f81283b Mon Sep 17 00:00:00 2001
From: Ade Bateman <bateman@acm.org>
Date: Thu, 28 Apr 2016 11:31:05 -0700
Subject: [PATCH] Remove issue #48 label.

Fixes #48.

PR #162 refactored the supportedMethods and payment specific data
fields. Issue #3 discusses supporting multiple currencies and issue #4
discusses price per payment method and we should consider specific
proposals for those issues.

PR #162 replaces the `sequence<DOMString>` with
`sequence<PaymentMethodData>` so we now use objects.
---
 specs/paymentrequest.html | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html
index 4f405f52..f5d48f41 100644
--- a/specs/paymentrequest.html
+++ b/specs/paymentrequest.html
@@ -354,12 +354,6 @@ <h2>PaymentRequest constructor</h2>
           for a deposit, pre-auth for a later payment, making recurring payments, and more.
         </div>
 
-        <div class="issue" data-number="48" title="Should list of accepted payment methods be strings or objects?">
-          There is an open issue about whether the list of supported payment
-          methods should be passed to the user agent as a simple sequence of
-          strings or as a more complex and flexible object structure.
-        </div>
-
         <div class="issue" data-number="51" title="Should the payment API be more conversational or less conversational?">
           There is an open issue regarding whether the current pattern of using
           events for exchange of data between the user agent and the website is