Authorize.net API with Card on File transactions support thread...

[carlwhat]

Query I used for tracking down anomalies:

select c.orders_id, c.payment_name, o.customers_name, o.payment_module_code from authorize_cim_payments c, orders o where o.orders_id = c.orders_id;

be suspicious of entries where payment_module_code is not authorize_cim *or* the two name fields don't match - they could be problems.

@swguy, you have a lot of things going on here; most of which look to be of your own doing.

looking at your sql statement above, is rather curious. you are telling me that you have records in the authorize_cim_payments table where the order has a different payment module? how could that be?

those are both rhetorical questions, of which i am not looking for an answer.

years ago, i started a discussion about creating a payments table/abstract payment class that other payment modules could use to store payment records. but alas, that never resulted in any new code in the repo...

the fact that you are writing payment records to that table has nothing to do with this payment module.

with regards to the allow money and all of the observer information you are talking about, i would suggest you look for this notifier:

$zco_notifier->notify('NOTIFY_AUTHNET_PAYMENTS', '', $this); 

which can be found here.

i believe you can do everything you want using that notifier.

that is what i do with my clients.

best.

[swguy]

These issues occurred prior to making any changes.

> looking at your sql statement above, is rather curious. you are telling me that you have records in the authorize_cim_payments table where the order has a different payment module? how could that be?

Easy. The original code shows those buttons on orders which were not paid by authorize. Someone accidentally clicks them, and you get bad records.
The ./includes/classes/authnet_order.php start() function should not return data if the original $oID is not an authorize_* order.

[swguy]

If the shop *only* accepts cim/cof, you wouldn't see this issue. But if it accepts other payment methods, and you look at an order paid by some other payment method in admin, you still see the CIM table.

[carlwhat]

@swguy, you have a lot of things going on here; most of which look to be of your own doing.

with regards to the allow money and all of the observer information you are talking about, i would suggest you look for this notifier:

$zco_notifier->notify('NOTIFY_AUTHNET_PAYMENTS', '', $this); 

which can be found here.

i believe you can do everything you want using that notifier.

that is what i do with my clients.

best.

my previous post, referenced here, has all of the information to solve your problem.

my client(s) have multiple payment modules enabled.

if you do not want the more money button to appear on non authorize orders i would suggest using that notifier and adding:

$p2->amount_applied = $p2->order_total; 

problem solved.

TIS.

[swguy]

Thank you for this suggestion. The correct notifier name is NOTIFY_ADMIN_AUTHNET_PAYMENTS; once I changed this, your recommendation worked.

The next issue is stranger still. When you call nextOrderNumber, you pass in $order->info. But in the body of nextOrderNumber, you look for $order['orders_id'], which doesn't exist in the info array. Shouldn't this be $order['order_id'] (singular)?

[carlwhat]

Thank you for this suggestion. The correct notifier name is NOTIFY_ADMIN_AUTHNET_PAYMENTS; once I changed this, your recommendation worked.

The next issue is stranger still. When you call nextOrderNumber, you pass in $order->info. But in the body of nextOrderNumber, you look for $order['orders_id'], which doesn't exist in the info array. Shouldn't this be $order['order_id'] (singular)?

yes. that looks correct.

although in looking at the code, the method nextOrderNumber will never get called when there is an order_id.

change forthcoming.

thanks for pointing that out.

[swguy]

The context here might be admin?

Next issue - really crazy-making, not sure how this can happen. COF transactions failing. Possibly related: The enabled field gets flipped to N when this happens.

[26-Jun-2024 09:36:49 America/New_York] PHP Fatal error: Uncaught Error: Typed property authorizenet_cim::$transID must not be accessed before initialization in /home/thatsoftwareguy4/client/includes/modules/payment/authorizenet_cim.php:382
Stack trace:
#0 /home/thatsoftwareguy4/client/includes/classes/payment.php(297): authorizenet_cim->after_process()
#1 /home/thatsoftwareguy4/client/includes/modules/pages/checkout_process/header_php.php(16): payment->after_process()
#2 /home/thatsoftwareguy4/client/index.php(82): require('/home/thatsoftw...')
#3 {main}
thrown in /home/thatsoftwareguy4/client/includes/modules/payment/authorizenet_cim.php on line 382

[26-Jun-2024 09:36:49 America/New_York] Request URI: /index.php?main_page=checkout_process, IP address: 68.73.117.78
--> PHP Fatal error: Uncaught Error: Typed property authorizenet_cim::$transID must not be accessed before initialization in /home/thatsoftwareguy4/client/includes/modules/payment/authorizenet_cim.php:382
Stack trace:
#0 /home/thatsoftwareguy4/client/includes/classes/payment.php(297): authorizenet_cim->after_process()
#1 /home/thatsoftwareguy4/client/includes/modules/pages/checkout_process/header_php.php(16): payment->after_process()
#2 /home/thatsoftwareguy4/client/index.php(82): require('/home/thatsoftw...')
#3 {main}
thrown in /home/thatsoftwareguy4/client/includes/modules/payment/authorizenet_cim.php on line 382.

[carlwhat]

The context here might be admin?

Next issue - really crazy-making, not sure how this can happen. COF transactions failing. Possibly related: The enabled field gets flipped to N when this happens.

[26-Jun-2024 09:36:49 America/New_York] PHP Fatal error: Uncaught Error: Typed property authorizenet_cim::$transID must not be accessed before initialization in /home/thatsoftwareguy4/client/includes/modules/payment/authorizenet_cim.php:382
Stack trace:
#0 /home/thatsoftwareguy4/client/includes/classes/payment.php(297): authorizenet_cim->after_process()
#1 /home/thatsoftwareguy4/client/includes/modules/pages/checkout_process/header_php.php(16): payment->after_process()
#2 /home/thatsoftwareguy4/client/index.php(82): require('/home/thatsoftw...')
#3 {main}
thrown in /home/thatsoftwareguy4/client/includes/modules/payment/authorizenet_cim.php on line 382

[26-Jun-2024 09:36:49 America/New_York] Request URI: /index.php?main_page=checkout_process, IP address: 68.73.117.78
--> PHP Fatal error: Uncaught Error: Typed property authorizenet_cim::$transID must not be accessed before initialization in /home/thatsoftwareguy4/client/includes/modules/payment/authorizenet_cim.php:382
Stack trace:
#0 /home/thatsoftwareguy4/client/includes/classes/payment.php(297): authorizenet_cim->after_process()
#1 /home/thatsoftwareguy4/client/includes/modules/pages/checkout_process/header_php.php(16): payment->after_process()
#2 /home/thatsoftwareguy4/client/index.php(82): require('/home/thatsoftw...')
#3 {main}
thrown in /home/thatsoftwareguy4/client/includes/modules/payment/authorizenet_cim.php on line 382.

i am not sure how this module is getting disabled in your setup.

line 382 does NOT correspond to the after_process method in my code.

in this situation, you have clearly modified my code.

i can debug problems that i can replicate from a vanilla install.

the information provided here seems to suggest putting me on some sort of wild goose chase:

• not sure how this can happen.
• maybe the admin?
• maybe disabled?
• incorrect line numbers from my own code?

my time for free support is limited; and the error that you are now presenting here is out of that limitation.

[swguy]

In case you see this again, my context is PHP 8.1/ZC 1.5.8.
It's not the module that gets disabled, it's the card in the customers_cc table. Sorry, should have clarified.