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

[carlwhat]

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.

[swguy]

> 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.

[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.

[carlwhat]

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.

[jeking]

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.

[carlwhat]

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.

[jeking]

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!

[swguy]

@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/payme...horizenet_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.

[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.

[jeking]

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.