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

swguy:

I have a customer whose customers.customers_default_address_id values are getting scrambled - sometimes 0, sometimes another customer's address_book entry. Have you ever heard of this? Running authorizenet_cim version 2.3.2.

i have not had problems with customers_default_address_id getting scrambled as part of this module. my customers who use this module also use FEC.

i have one customer who uses OPC along with this module, and that customer would occasionally have problems associated with their address book entries being screwed up. i think the latest version of OPC addressed those problems.

on sites where you are seeing that problem, i would look to see if admins had placed an order for a different customer just prior to the customer getting screwed up. a difficult bug to track down, but that has been my only experience where address_book_id entries getting out of sync.

if you think it is related to this module, there is only 1 spot where this module updates the default address book entry and i would think that could be commented out with no ill effect.

best.

if you think it is related to this module, there is only 1 spot where this module updates the default address book entry and i would think that could be commented out with no ill effect.

Agreed, I might do that.

The trouble is, this customer has a template from the vendor which must not be named, so that could be the root cause and auth.cim could be a victim. Still digging.

I put a log create in updateDefaultCustomerBillto() just before the update when the value of $id (cast as an int).
The original value was 'new'. Hope this casts some light.

swguy:

I put a log create in updateDefaultCustomerBillto() just before the update when the value of $id (cast as an int).
The original value was 'new'. Hope this casts some light.

it does.

there are a few changes to 2 files that you can see in this commit.

in addition, can test this whole branch. that branch should work with php 8.2; although the sdk was updated by some users and not authorize.net.

you can see the discussion over here.

at some point, i will create a new release for this most awesome payment module.

best.

carlwhat:

i am working on a new release of this most excellent, IMO (inherently biased), payment module. it should address all bugs documented by you and verified by me. including the verified bugs associated with guest checkout.

thanks for pointing them out.

best.

We've run into this problem again except this time deleting the cards from the guest account is not working. We did move the client to a new server, so maybe the cards are not actually deleting? I'm not sure what table they are in. I see 1275 entries in authorize_cim_payments

This client does tend to place a lot of orders for her clients and uses the guest checkout.

jeking:

We've run into this problem again except this time deleting the cards from the guest account is not working. We did move the client to a new server, so maybe the cards are not actually deleting? I'm not sure what table they are in. I see 1275 entries in authorize_cim_payments

This client does tend to place a lot of orders for her clients and uses the guest checkout.

jim,
i do not have a lot of time to devote to this situation right now. i have paying customers that require my attention.

and i have no idea exactly what problem to which you refer. you are quoting something from over 3 years ago?

no one else seems to be having problems deleting customer credit cards. in fact, i happened to do it today on one of my paying customers sites.

perhaps you can do some more digging and be SPECIFIC about what problem your client is currently experiencing.

getting back to basics, the authorize_cim_payments stores payments. i would NOT suggest deleting any records in there.

the customers_cc table is where card tokens are kept. if you were to delete the records in there, the tokens still exist at auth.net; and if you are having a problem with too many credit cards being stored at auth.net, they really need to be deleted up there. which i know my module does. as again, i did it today.

best.

carlwhat:

jim,
i do not have a lot of time to devote to this situation right now. i have paying customers that require my attention.

and i have no idea exactly what problem to which you refer. you are quoting something from over 3 years ago?

no one else seems to be having problems deleting customer credit cards. in fact, i happened to do it today on one of my paying customers sites.

perhaps you can do some more digging and be SPECIFIC about what problem your client is currently experiencing.

getting back to basics, the authorize_cim_payments stores payments. i would NOT suggest deleting any records in there.

the customers_cc table is where card tokens are kept. if you were to delete the records in there, the tokens still exist at auth.net; and if you are having a problem with too many credit cards being stored at auth.net, they really need to be deleted up there. which i know my module does. as again, i did it today.

best.

Paul,

I appreciate the quick reply and completely respect paying clients come first.

The short answer, although still puzzling, is the new server was the issue. Reverting the account back to the old server fixed the problem. Now why that is the case, I don't know. I'll have to spend some time trouble shooting. I will post back any information I find.

Thanks!

@carlwhat I thought there was more documentation than there is on the use cases for this module. Would you please either create a PR for

https://docs.zen-cart.com/user/payment/authorizenet_cim/

or just add notes in this thread about the problems this module solves for storeowners? I think it would grow the adoption of this module if people understood its advantages more fully.

if you are running v1.5.8 or greater, there is a new version of this payment module available.

support is only for php 8.0 or greater.

the few of you who use it know what a most excellent payment module it is. but then again i am biased.

carlwhat:

if you are running v1.5.8 or greater, there is a new version of this payment module available.

support is only for php 8.0 or greater.

the few of you who use it know what a most excellent payment module it is. but then again i am biased.

I can attest, the plugin is great and carlwhat does a great job of supporting it too.

users of this module, please take note:

there have been some administrative challenges on my part of getting version 3.0.x ready for use.

if you are running any version of 3.0.x; update to v3.0.3

this should available in the downloads hopefully soon. if not one can get it directly from the github repo.

if using this module, please consider a donation. and after considering it, then proceed to do it! you will feel better and so will i.

best.

carlwhat:

users of this module, please take note:

there have been some administrative challenges on my part of getting version 3.0.x ready for use.

if you are running any version of 3.0.x; update to v3.0.3

this should available in the downloads hopefully soon. if not one can get it directly from the github repo.

if using this module, please consider a donation. and after considering it, then proceed to do it! you will feel better and so will i.

best.

Hello,

I am running ZenCart 1.5.7d and tried installing 2.3.3 version of this plugin. After installation, the only payment modules that are appearing are Aunthorize.net (SIM) and (AIM) that we previously present. I am getting an error " PHP Parse error: syntax error, unexpected 'define' (T_STRING) in /includes/languages/english/modules/payment/authorizenet_cim.php on line 48."

allmart:

Hello,

I am running ZenCart 1.5.7d and tried installing 2.3.3 version of this plugin. After installation, the only payment modules that are appearing are Aunthorize.net (SIM) and (AIM) that we previously present. I am getting an error " PHP Parse error: syntax error, unexpected 'define' (T_STRING) in /includes/languages/english/modules/payment/authorizenet_cim.php on line 48."

look at line 46 here:

https://github.com/proseLA/authorizenet_cim/blob/2b45d8d26c38333e9d48a3e5f94633a737574ae4/includes/languages/english/modules/payment/authorizenet_cim.php#L46-L49

it is missing a semi-colon at the end of the line.

it should look like:

define('MODULE_PAYMENT_AUTHORIZENET_CIM_FRAUD_WARNING', 'Sorry, due to the increasing amount of fraud we are forced to limit credit card usage.');

best.

Many thanks ... worked like a charm, Cheers!

Went live on my test site and tested a small transaction which worked like a charm but when a pushed the red button in order details to void the transaction, I got this error "PHP Warning: Illegal string offset 'id' in /includes/modules/payment/authorizenet_cim.php on line 107."
Thanks again for you help and an awesome plugin.

allmart:

Went live on my test site and tested a small transaction which worked like a charm but when a pushed the red button in order details to void the transaction, I got this error "PHP Warning: Illegal string offset 'id' in /includes/modules/payment/authorizenet_cim.php on line 107."
Thanks again for you help and an awesome plugin.

i am not sure why your order does not have a country id there. it could be indicative of other problems.

between lines 104 and 105 you can add the following code (i have included both lines below for clarity):

    global $order, $db;
    if (empty($order->billing['country']['id'])) {
                return;
        }
    if (($this->enabled == true) && ((int)MODULE_PAYMENT_AUTHORIZENET_CIM_ZONE > 0)) {

best.

carlwhat:

i am not sure why your order does not have a country id there. it could be indicative of other problems.

between lines 104 and 105 you can add the following code (i have included both lines below for clarity):

global $order, $db;
if (empty($order->billing['country']['id'])) {
            return;
    }
if (($this->enabled == true) && ((int)MODULE_PAYMENT_AUTHORIZENET_CIM_ZONE > 0)) {

> 
> best.

This worked, thanks again. I'm sorry to keep bothering you but I am having another issue. I am using One Page Checkout with Guest Checkout. When trying to process the order as a guest after a long delay, I get the following error "PHP Notice: 10437 was logged off and should be looked at! in /includes/modules/payment/authorizenet_cim.php on line 918". I tried increasing the time from 45 to 60 but no luck, which is already a long wait.

Regards,

i would review this thread.

and potentially turn guest checkout off.

i’ll be without development resources for a bit.

perhaps some one else can help out.

best.

Thanks Carl, unfortunately since implementing Guest Checkout I have seen a noticeable increase in orders. Don't understand why, even many customers that have accounts are using it.

In the constructor, after setting sort_order and enabled, you should do a check:

        if (null === $this->sort_order) return;

otherwise you get a bunch of logs for undefined constants.

[21-May-2024 11:42:03 America/Anchorage] PHP Fatal error: Uncaught Error: Undefined constant "MODULE_PAYMENT_AUTHORIZENET_CIM_TESTMODE" in /home/thatsoftwareguy4/client/includes/modules/payment/authorizenet_cim.php:104