Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Redefinition of BasicCardResponse to address Issue 9 #25

Closed
wants to merge 5 commits into from
Closed

Redefinition of BasicCardResponse to address Issue 9 #25

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
54c5839
Redefinition of BasicCardResponse to address Issue 9
Mar 4, 2016
bc8bc21
Added some major credit card brand payment identifiers and tidied up …
Mar 5, 2016
d13bb29
Fixed case of cardholderName
Mar 5, 2016
0d3df46
Fixed incorrect issue reference
Mar 6, 2016
78fa939
Removed Maestro specific fields
Mar 11, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
41 changes: 20 additions & 21 deletions specs/basic-card-payment.html
View file
Open in desktop
Expand Up @@ -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>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest we namespace these for this payment method because it's quite possible (likely) that we'll have a "tokenized card payments" or "encrypted card payments" spec pretty soon.

<tr><td>basic-card-visa</td><td>Visa (Credit, Debit, Delta or Electron)</td></tr>
<tr><td>basic-card-mastercard</td><td>MasterCard and EuroCard</td></tr>
<tr><td>basic-card-amex</td><td>American Express</td></tr>
<tr><td>basic-card-discover</td><td>Discover</td></tr>
<tr><td>basic-card-maestro</td><td>Maestro</td></tr>
<tr><td>basic-card-diners</td><td>Diners Club</td></tr>
<tr><td>basic-card-jcb</td><td>JCB</td></tr>


<section id="init-data">
Expand All @@ -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>
Expand All @@ -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>
Expand Down
2 changes: 1 addition & 1 deletion specs/paymentrequest.html
View file
Open in desktop
Expand Up @@ -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.
Expand Down