Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Validate_CreditCard Component Proposal

Proposed Component Name Zend_Validate_CreditCard
Developer Notes
Proposers Thomas Weidner
Zend Liaison TBD
Revision 1.0 - 14 June 2009: Initial Draft. (wiki revision: 6)

Table of Contents

1. Overview

Zend_Validate_CreditCard is a rewrite of Zend_Validate_Ccnum and adds functionality.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will check if credit cards are valid
  • This component will allow to check against a online service for more security and redundancy
  • This component will not add this services but only the interface for them
  • This component will validate against all known credit card institutes

4. Dependencies on Other Framework Components

  • Zend_Validate_Exception
  • Zend_Validate_Abstract

5. Theory of Operation

The component is a rewrite of the actual available Zend_Validate_Ccnum validator. The actual available validator should be renamed to Zend_Validate_CreditCard for usability. The old class would be a wrapper for the new class but with a notice for depreciation.

This component is able to check against 16 different credit card institutes. The actual component will be used as "generic" validator when no credit card institute is given.

Additionally this component will add a interface which allows to use external service classes for the validation of a credit card. Some credit card institutes provide a online API for this case. But many of them are payed-services and not available for free.
This component will also work offline and allows therefor several levels of validation.
Level 1.) Generic - as with the actual component - very unsecure
Level 2.) Institute specific - offline test specific to each institute - more secure
Level 3.) Online - needs a online connection and a service class - most available security

6. Milestones / Tasks

  • Milestone 1: [DONE] Proposal finished
  • Milestone 2: [DONE] Proposal accepted
  • Milestone 3: [DONE] Coding finished
  • Milestone 4: [DONE] Unit tests finished
  • Milestone 5: [DONE] Documentation finished
  • Milestone 6: [DONE] Component moved to core

7. Class Index

  • Zend_Validate_CreditCard
  • Zend_Validate_CreditCard_Interface

8. Use Cases


Level 1 - works like actual component


Level 2 - validation for one credit card institute


Level 3 - using a online check
Note that the number is also checked with level2 which means that when Level2 failes, the online check is not processed

9. Class Skeletons



Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jul 05, 2009

    <p>great proposal!<br />
    few questions though</p>

    <p>- does component operate with ccnum only? because actual card validation involves expiration date and sometimes adress verification & card security code (<a href="">wiki</a>)</p>

    <p>- shouldn't component automatically get card issuer from card number prefix according to this table <a href="">(wiki)</a> ?</p>

    <p>- what information card institute API should provide? for example, should it check if card is canceled or expired?</p>

    <p>- shouldn't online checkers be called "adapters"? so interface class will be Zend_Validate_CreditCard_Adapter_Interface</p>


    <p>Denis Portnov</p>

    1. Jul 06, 2009

      <p>*) Expiration date, Adress verification and CSC are only known by the CCI. As this algorithm is not available (only known by CCI) there would be no proper way to integrate it.</p>

      <p>*) Already supported... read the proposal.<br />
      But this could also lead to the problem that you only accept Visa and your customer gives AMEX... still true as long as you don't define the CCI.</p>

      <p>*) This depends on the CCI as, for example, only CCI would know if the card has been canceled. The offline verification still must return true for such a card.</p>

      <p>*) No, because within the validator itself we will not have online APIs integrated. The validator just provides a interface for you to integrate this API into the validator. This APIs are all payed services so there would be no way to integrate them except we know how the API works, and therefor you have to pay. These APIs are not allowed to be delivered to non-CCI customers.</p>

  2. Jul 25, 2009

    <p>In some instances you might be only able to use certain credit card providers for your billing services, for example you can only process VISA and MasterCard.</p>

    <p>The following API should be possible then:</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    new Zend_Validate_CreditCard(Zend_Validate_CreditCard::AMERICAN_EXPRESS | Zend_Validate_CreditCard::VISA);

    <p>Which would require the constants to be all Integers.</p>

    1. Jul 25, 2009

      <p>What ever content the constants will have (this is not part of this proposal),<br />
      the above way will not be supported.</p>

      <p>You can still simply add 2 validators to your chain, one for AMEX and one for VISA.</p>

  3. Jul 28, 2009

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Framework Acceptance</ac:parameter><ac:rich-text-body>
    <p>The Zend Framework Team is pleased to accept this proposal for immediate development in the Standard Incubator.</p>

    <p>We ask that you follow the requirements below when developing the component:</p>
    <li>Should allow validating multiple types with a single call
    <li>Binary masking or array of types to attempt</li>
    <li>rename "onlineCheck" to simply "service"</li>
    <li>Should allow passing service objects to constructor via options array</li>