Redefinition of BasicCardResponse to address Issue 9

Also revised property names for nameOnCard, pan and securityCode to be
more descriptive and consistent.
Added some major credit card brand payment identifiers and tidied up some basic card response fields
Fixed incorrect issue reference for #19

specs/basic-card-payment.html

@@ -142,9 +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>
-      </table>
+        <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>diner</td><td>Diners Club</td></tr>
+        <tr><td>jcb</td><td>JCB</td></tr>
+	  </table>
     </section>
 
     <section id="init-data">
@@ -164,12 +169,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 +184,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>

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.