I have a test set up running from a local machine before deployment. I turned on and did some simple live authorize.net testing last night and I noticed some odd information in the authorize.net transactions.
1. The invoice number does not relate at all to the nop invoice number.
2. The IP address was not recorded.
Should both of these work?
authorize.net testing
- 1
- 2
- 43
- 235
- 12/05/2010
- United States
I did some side by side comparison with the database. The authorize.net invoice number comes from the orderGUID, not the invoice number.
nopDevelopers: Please use the invoice number or give the admin the choice. That is why it is called the invoice/order number every place. Using the orderGUID is not only confusing, your are not even using the whole thing. It truncates in authorize.net.
nopDevelopers: Please use the invoice number or give the admin the choice. That is why it is called the invoice/order number every place. Using the orderGUID is not only confusing, your are not even using the whole thing. It truncates in authorize.net.
- 43
- 235
- 12/05/2010
- United States
OK. Then that is another issue I am going to ask to be changed.
Someone can place and order and have a failed payment. This is not uncommon in other shopping carts. The order has been placed once a person has decided what they wanted and all of the amounts verified. They are then working on the payment side which needs to reference that order. What if a customers order fails payment but they want to call and ask a question about the order.
By creating an order GUID and giving it something unique you really have created the order. But you have given it a number that nobody can use. Not us, not the customer and not merchant account company.
There is also no consistency in the chain of data. If there needs to be trace back of data and the customer has to call the CC company which then has to call the merchant account company the authorization, the customer is going to reference order X. The CC company and merchant account company will not have any record of order X, just some bizarre long numbers which is the partial GUID. If the CC company/merchant account company calls me with questions about order avcd-212-3232 I have nothing exactly that I can reference. Since it is partial their number will not match mine. Now could we trace it all down with little effort ? Sure thing and it would take very little time. But I'd like for there to be consistency from what the customer sees, to what I see, to what authorize.net & the CC company sees. Storing of the GUID is OK but it has no use outside of the DB.
Please consider changing this. I'd like to hear from anybody on this issue.
Someone can place and order and have a failed payment. This is not uncommon in other shopping carts. The order has been placed once a person has decided what they wanted and all of the amounts verified. They are then working on the payment side which needs to reference that order. What if a customers order fails payment but they want to call and ask a question about the order.
By creating an order GUID and giving it something unique you really have created the order. But you have given it a number that nobody can use. Not us, not the customer and not merchant account company.
There is also no consistency in the chain of data. If there needs to be trace back of data and the customer has to call the CC company which then has to call the merchant account company the authorization, the customer is going to reference order X. The CC company and merchant account company will not have any record of order X, just some bizarre long numbers which is the partial GUID. If the CC company/merchant account company calls me with questions about order avcd-212-3232 I have nothing exactly that I can reference. Since it is partial their number will not match mine. Now could we trace it all down with little effort ? Sure thing and it would take very little time. But I'd like for there to be consistency from what the customer sees, to what I see, to what authorize.net & the CC company sees. Storing of the GUID is OK but it has no use outside of the DB.
Please consider changing this. I'd like to hear from anybody on this issue.
- 1
- 2