diff --git a/specs/basic-card-payment.html b/specs/basic-card-payment.html
index b63a99ad..70810cbc 100644
--- a/specs/basic-card-payment.html
+++ b/specs/basic-card-payment.html
@@ -142,8 +142,14 @@ <h2>Payment Method Identifier</h2>
 
       <table>
         <tr><th>Identifier String</th><th>Description</th></tr>
-        <tr><td>visa</td><td>VISA cards</td></tr>
-        <tr><td>...</td><td>...</td></tr>
+        <tr><td>visa</td><td>Visa (Credit, Debit, Delta or Electron)</td></tr>
+        <tr><td>mastercard</td><td>MasterCard and EuroCard</td></tr>
+        <tr><td>amex</td><td>American Express</td></tr>
+        <tr><td>discover</td><td>Discover</td></tr>
+        <tr><td>maestro</td><td>Maestro</td></tr>
+        <tr><td>diners</td><td>Diners Club</td></tr>
+        <tr><td>jcb</td><td>JCB</td></tr>
+        <tr><td>unionpay</td><td>Union Pay</td></tr>
       </table>
     </section>
 
@@ -164,12 +170,12 @@ <h2>Payment Method Response</h2>
       <h2>BasicCardResponse</h2>
       <pre class="idl">
         dictionary BasicCardResponse {
-          required DOMString nameOnCard;
-          required DOMString pan;
+          required DOMString cardholderName;
+          required DOMString cardNumber;
           required DOMString expiryMonth;
           required DOMString expiryYear;
-          DOMString securityCode;
-         
+		  DOMString cardSecurityCode;
+		  
           BillingAddress? billingAddress;
         };
       </pre>
@@ -179,28 +185,22 @@ <h2>BasicCardResponse</h2>
       </p>
 
       <dl>
-        <dt><dfn><code>nameOnCard</code></dfn></dt>
-        <dd>The <code>nameOnCard</code> field contains the card holder's name as it appears on the card.</dd>
-        <dt><dfn><code>pan</code></dfn></dt>
-        <dd>The <code>pan</code> field contains the card number or primary account number (PAN) for the payment card.</dd>
+        <dt><dfn><code>cardholderName</code></dfn></dt>
+        <dd>The <code>cardholderName</code> field contains the cardholder's name as it appears on the card.</dd>
+        <dt><dfn><code>cardNumber</code></dfn></dt>
+        <dd>The <code>cardNumber</code> field contains the primary account number (PAN) for the payment card.</dd>
         <dt><dfn><code>expiryMonth</code></dfn></dt>
         <dd>The <code>expiryMonth</code> field contains a two-digit string for the expiry month
         of the card in the range <code>01</code> to <code>12</code>.</dd>
         <dt><dfn><code>expiryYear</code></dfn></dt>
         <dd>The <code>expiryYear</code> field contains a two-digit string for the expiry year
         of the card in the range <code>00</code> to <code>99</code>.</dd>
-        <dt><dfn><code>securityCode</code></dfn></dt>
-        <dd>The <code>securityCode</code> field contains a three or four digit string for the
-        security code of the card (e.g. sometimes known as the CVV, CVC, or CID).</dd>
+        <dt><dfn><code>cardSecurityCode</code></dfn></dt>
+        <dd>The <code>cardSecurityCode</code> field contains a three or four digit string for the
+        security code of the card (sometimes known as the CVV, CVC, CVN, CVE or CID).</dd>
+		
       </dl>
 
-      <div class="issue" data-number="9" title="Different card schemes have different mandatory field requirements">
-        There is an open issue highlighting that different card schemes have different manadatory
-        requirements. This suggests that there might be a base credit card message format that supports
-        the minimal set of required fields such as PAN and expiry date and other derived message formats
-        based on the this that adds other fields such as start date.
-      </div>
-
       </section>
 
       <section>
diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html
index aa33d8c9..92296ef1 100644
--- a/specs/paymentrequest.html
+++ b/specs/paymentrequest.html
@@ -341,7 +341,7 @@ <h2>PaymentRequest constructor</h2>
           currently described in the specification.
         </div>
 
-        <div class="issue" data-number="18" title="Should the API handle pre-auth, recurring payments, and similar scenarios">
+        <div class="issue" data-number="19" title="Should the API handle pre-auth, recurring payments, and similar scenarios">
           There is an open issue about whether the API should handle occasions when a site wants to request a payment
           method but not actually make a charge immediately. These may include identification validation, pre-auth
           for a deposit, pre-auth for a later payment, making recurring payments, and more.