PEAR Bug Search Results

Payment_Process: Bug 18006 [Open] Installation layout

Fedora at FamilleCollet dot com — 2010-10-29T11:57:14+00:00

Payment_Process Bug
Reported by remicollet
2010-10-29T11:57:14+00:00
PHP: 5.3.3 OS: GNU/Linux (Fedora 14) Package Version: 0.6.8

Description:
------------
I think some files have not the right role of installtion dir

TODO should be "doc" instead of "data"

package_Litle.xml is probably not needed (is "data")

Offline.php, PayPal.php and Paycom.php are installed in docs/Payment_Process ? Are this files "doc" (role should be change) or "php" (baseinstalldir should be change to "Payment")

Payment_Process: Feature/Change Request 14368 [Open] Missing Functions for transactionId and messageCode

malber at interactdigitalmedia dot com — 2008-07-19T00:49:43+00:00

Payment_Process Feature/Change Request
Reported by malber69
2008-07-19T00:49:43+00:00
PHP: 5.2.6 OS: Linux Package Version: 0.6.6

Description:
------------
To allow easy access to these other two values:

function getTranactionId()
    {
        return $this->transactionId;
    }

    function getMessageCode()
    {
        return $this->messageCode;
    }

Payment_Process: Bug 14257 [Open] eCheckType is not defined and firstName/lastName not defined for AVS

mailinglabel at gmail dot com — 2008-06-28T23:01:30+00:00

Payment_Process Bug
Reported by bigbluevan
2008-06-28T22:57:39+00:00
PHP: 5.2.5 OS:  Package Version: 0.6.6

Description:
------------
For AuthorizeNet...
The x_echeck_type is not allowed to be set. Refer to page 7 of eCheck.pdf (http://developer.authorize.net/guides/eCheck.pdf).

And, for echeck's, the firstName/lastName can be become required fields when the Address Verification Service is enabled.

Payment_Process: Bug 14255 [Open] No echeck support for business checking accounts with authorizenet driver

ces dot fci at gmail dot com — 2008-06-28T20:12:58+00:00

Payment_Process Bug
Reported by bigbluevan2
2008-06-28T20:12:58+00:00
PHP: 5.2.5 OS:  Package Version: 0.6.6

Description:
------------
According to page 7 of eCheck.pdf (http://developer.authorize.net/guides/eCheck.pdf), an echeck of type BUSINESSCHECKING should be allowed to be specified.

Refer to patch

diff -ru Payment.orig/Process/AuthorizeNet.php Payment/Process/AuthorizeNet.php
--- Payment.orig/Process/AuthorizeNet.php       2008-06-28 14:57:44.000000000 -0500
+++ Payment/Process/AuthorizeNet.php    2008-06-28 14:59:19.000000000 -0500
@@ -332,6 +332,9 @@
                 case PAYMENT_PROCESS_CK_SAVINGS:
                     $data['x_bank_acct_type'] = 'SAVINGS';
                     break;
+                case PAYMENT_PROCESS_CK_BUSINESSCHECKING:
+                    $data['x_bank_acct_type'] = 'BUSINESSCHECKING';
+                    break;
             }
         }
 
diff -ru Payment.orig/Process/Type.php Payment/Process/Type.php
--- Payment.orig/Process/Type.php       2008-06-28 14:57:44.000000000 -0500
+++ Payment/Process/Type.php    2008-06-28 15:02:28.000000000 -0500
@@ -52,6 +52,7 @@
 
 define('PAYMENT_PROCESS_CK_SAVINGS',  1000);
 define('PAYMENT_PROCESS_CK_CHECKING', 1001);
+define('PAYMENT_PROCESS_CK_BUSINESSCHECKING', 1002);
 
 /**
  * Payment_Process_Type

Payment_Process: Feature/Change Request 6982 [Open] AuthNet & _defaultOptions?

awbacker at gmail dot com — 2006-03-01T19:05:29+00:00

Payment_Process Feature/Change Request
Reported by awbacker@...
2006-03-01T19:05:29+00:00
PHP: 5.1.2 OS: linux Package Version: 0.6.5

Description:
------------
This may not be a bug, but there is no forum where I can post this kind of question to.

AuthorizeNet has a _defaultOptions field that does not appear to be being used.  It has all the fields that I didn't know existed (x_encap_char, etc) that the process() method complaining about.  Should this array be being used to initialize Common in __construct, maybe in addition to $options? 

I am curious what the expected way to handle options is?  The one example has someone creating an options array.  I would like to initialize the object and call $obj->options['value'] = 'myval', or better yet, setOption('key', 'val')

Thanks,
Andrew

Payment_Process: Bug 5140 [Open] Abstract isLegitimate returns wrong message

scott at crisscott dot com — 2005-08-18T15:12:28+00:00

Payment_Process Bug
Reported by scott@...
2005-08-18T15:12:28+00:00
PHP: 5.0.3 OS: N/A Package Version: 

Description:
------------
Payment_Process_Result::isLegitimate() returns an error that says "parse() not implemented". This is a minor issue but rather confusing when trying to write and test new drivers.

Actually, parseCallback() has the same problem.

Test script:
---------------
// Should be...
function isLegitimate()
{
    return PEAR::raiseError('isLegitimate() not implemented', PAYMENT_PROCESS_ERROR_NOTIMPLEMENTED);
}

Expected result:
----------------
isLegitimate() not implemented

Actual result:
--------------
parse() not implemented

Payment_Process: Feature/Change Request 5125 [Open] Credit request and x_trans_key change

josx at interorganic dot com dot ar — 2005-08-22T22:10:12+00:00

Payment_Process Feature/Change Request
Reported by josx@...
2005-08-17T12:58:01+00:00
PHP: 4.3.0 OS: Gnu/linux Package Version: 

Description:
------------
I have added to my version Refund Support as on Authorize.net's issuing credits guide.
I have added also a little change to support x_trans_key as password.
Just added a few lines. This a diff with the 1.31 revision.


39c39,40
<     PAYMENT_PROCESS_ACTION_VOID     => 'VOID'
---
>     PAYMENT_PROCESS_ACTION_VOID     => 'VOID',
>     PAYMENT_PROCESS_ACTION_CREDIT   => 'CREDIT'
71c72
<         'password'      => 'x_password',
---
>         'password'      => 'x_tran_key',
90a92,93
>         'transactionId' => 'x_trans_id',
>         'cardNumber'  => 'x_card_num',
309c317,318
<         if ($this->_payment->getType() == 'eCheck') {
---
>         if(method_exists($this->_payment,'getType')) {
>       if ($this->_payment->getType() == 'eCheck') {
319a329
>       }
343,345c353,358
<         if ($this->_payment->getType() == 'eCheck') {
<              $this->_data['x_bank_acct_name'] = $this->_payment->firstName.' '.$this->_payment->lastName;
<         }
---
>       if (method_exists($this->_payment,'getType'))  {
>             if ($this->_payment->getType() == 'eCheck') {
>                $this->_data['x_bank_acct_name'] = $this->_payment->firstName.' '.$this->_payment->lastName;
>           }
>       }
>

I hope that it contributes to the development.

Payment_Process: Feature/Change Request 3875 [Open] Misnomer: Payment_Process_Result::validate()

2005-07-28T03:08:50+00:00

Payment_Process Feature/Change Request
Reported by jausions
2005-03-18T19:29:32+00:00
PHP: Irrelevant OS: Irrelevant Package Version: 

Description:
------------
At best the Payment_Process_Result::validate() method is misnamed.

The validate() method should tell is the result is valid, not if the transaction was approved. This is a totally different thing. A declined transaction is a valid result. Garbage received from the payment gateway is not.

Furthermore, someone may want to accept a payment even if AVS didn't pass. A mismatch in AVS (or CVV) doesn't mean the transaction was declined. Depending on your settings in accepting transactions vis-a-vis AVS and CVV, a mismatched AVS and/or CVV could be discarded.

So testing for AVS and or CVV mismatch before the overall transaction result, could result in accepted orders to retur a PEAR_Error instance.

 -Philippe

Payment_Process: Bug 3848 [Assigned] AuthorizeNet doesn't map all possible values

2005-07-28T03:03:47+00:00

Payment_Process Bug
Reported by jausions
2005-03-16T19:24:18+00:00
PHP: Irrelevant OS: Irrelevant Package Version: 

Description:
------------
The AuthorizeNet processor doesn't set the address and other transaction information.

Without address information sent to the payment gateway, AVS cannot be completed.

The problem arises from the lack of class members to be set by Payment_Process::getFields(), setFrom(), fieldExists() and set()

Reproduce code:
---------------
Solution:

Add members to Payment_Process_AuthorizeNet



This is not a definitive list though...

 -Philippe

Payment_Process: Feature/Change Request 3835 [Open] Test mode should be ON by default

2005-03-16T00:45:56+00:00

Payment_Process Feature/Change Request
Reported by jausions
2005-03-16T00:45:56+00:00
PHP: Irrelevant OS: Irrelevant Package Version: 

Description:
------------
To ease deployment of such a package, I suggest to have the test mode turned on by default (if available.) This package deals mostly with billing information, and its status is beta code, so I think it would be wise to force its users to turn OFF the test mode to prevent errors and costly mistakes.

This is related to bug #3793 which suggests a processor-independent way to handle test mode (submitted by myself as well.)

 -Philippe

Payment_Process: Bug 3818 [Open] AuthorizeNet::process() method accessing private member of "Result" object

2007-09-19T18:09:32+00:00

Payment_Process Bug
Reported by jausions
2005-03-15T05:45:53+00:00
PHP: Irrelevant OS: Irrelevant Package Version: 

Description:
------------
The Payment_Process_AuthorizeNet::process() method calls  Payment_Process_Result::factory() method, but then access the private member _request to set itself as the caller. Even though it works under PHP4, this is not good practice.

Either pass the processor as a parameter to the factory method, or use a separate method to set it (setProcessor()) or change the private member to a public one.

I would think modifying the factory method is the best way to go...

 -Philippe

Payment_Process: Feature/Change Request 3793 [Open] Need of a processor-independent way to enable test mode

2005-03-12T16:25:33+00:00

Payment_Process Feature/Change Request
Reported by jausions
2005-03-12T16:25:33+00:00
PHP: Irrelevant OS: Irrelevant Package Version: 

Description:
------------
We need to have a way to turn on test mode independently of the processor used. Of course, the test mode implementation itself is left to the processor driver.

Test mode could be of several types: using live payment service but flagging the transaction as a test one, or using a sandbox if the payment service has one...

I'll send a patch for review when I have one.

 -Philippe