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_Service_Payment Component Proposal

Proposed Component Name Zend_Service_Payment
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Service_Payment
Proposers Richard Thomas
Darby Felton, Zend liaison
Revision 1.1 - 1 August 2006: Updated from community comments. (wiki revision: 11)

Table of Contents

1. Overview

Zend_Service_Payment is a module to provide a standardized api for payment processing. Due to the large range of diffrences between processors this only suggests a base api, it does not attempt to abstract all of the settings and complicated nature of processors.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

Will provide a basic api layout for handling and processing of payments online

  • This component will provide a basic api
  • This component will provide a way to load various api's
  • This component will not attempt to fully abstract all of the settings of the various processors

4. Dependencies on Other Framework Components

  • Zend_Exception

5. Theory of Operation

Provide an easy to use basic api for handling payment processing

6. Milestones / Tasks

  • Milestone 1: design notes will be published here
  • Milestone 2: Working prototype checked into the incubator supporting use cases #1, #2, ...
  • Milestone 3: Working prototype checked into the incubator supporting use cases #3 and #4.
  • Milestone 4: Unit tests exist, work, and are checked into SVN.
  • Milestone 5: Initial documentation exists.

If a milestone is already done, begin the description with "[DONE]", like this:

  • Milestone #: [DONE] Unit tests ...

7. Class Index

  • Zend_Service_Exception
  • Zend_Service_Payment (factory class)
  • Zend_Service_Payment_Authnet

8. Use Cases

$authnet = new Zend_Service_Payment('authnet');
$authnet->setParam('x_login','login');
$authnet->setParam('x_tran_key','key');
$authnet->setParam('x_card_num','4111111111111111');
$authnet->setParam('x_amount','1');
$authnet->setParam('x_exp_date','11/11');
$authnet->setParam('x_po_num','test1');
$authnet->setParam('x_ship_to_country','test2');
$authnet->setParam('x_card_code','321');
$authnet->process();

9. Class Skeletons

]]></ac:plain-text-body></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

4 Comments

comments.show.hide

  1. Jan 16, 2007

    Mike Willbanks

    <p><strong>Class Index Naming:</strong><br />
    Zend_Service_Payment_Authnet should be -> Zend_Service_Payment_Adapter_Authnet or _Authorize</p>

    <p>An adapter could provide default behavior.</p>

    <p><strong>Zend_Service_Payment_Adapter Parameters</strong>:<br />
    The parameters could definitely use a map that will map comment inputs to an area.  A common interface for the comment types of input as to allow the switching of modules quickly.  Currently with the use case scenario this would not work.</p>

    <p>There will be more input than just a simple credit card.  They might have a bank account to tie into or in the future possible other options or internal options.  Therefore a Zend_Service_Payment_Type will be needed to contain the following types of payments.  This would also most likely take the need of a factory.</p>

    <p><strong>Zend_Service_Payment_Result</strong>:<br />
    Provide an interface or factory to retrieve the results.  These results should have the ability to like above retrieve the common items in a certain area with additional parameters in a separate area.</p>

    <p>I am actually working on a payment processing system at the present moment.  These are all major considerations that need to be made. </p>

  2. Jan 26, 2007

    Matthew Ratzloff

    <p>I think this is going to be a bigger class than what's laid out here. Zend_Payment would probably be a more appropriate name for it (much like how the Locale classes are split up).</p>

    <p>Classes like Zend_Service_PayPal or Zend_Service_Google_Checkout could then extend it and provide customized functionality.</p>

    1. Jan 26, 2007

      Mike Willbanks

      <p>A bigger class is definitely going to be needed than what was here.  However, if you take a look at the PEAR Payment_Process they have a fairly good start.  I think that the approach would be to attempt to modularize them like Zend_Db.  I think that pattern takes a great approach.  Essentially they all have the same functionality just need data passed to them in different ways.  A field map can be created to map all of the items together so there is a unified API.</p>

  3. Feb 23, 2011

    Brandon Kozak

    <p>We would like to pick-up where this left off. Is there something like this going on to-date?</p>

    <p>Thanks,</p>

    <p>W3Evolutions</p>