QuickBooks Merchant Service

[cptok]

I have installed this mod and all is working correctly, with one problem which I suspect has a simple solution, I just can't find it.

QBMS charges transactions as "Sales". I would like for them to be charged as "Authorize" so I can capture the authorization as needed once the items are shipped.

Any suggestions on where to look to make this change?

Thanks very much.

What you describing can be done - but it is not a "simple solution". The XML submission in Zen specifically crafts it as a sale (authorize and charge). One could re-write the XML message to be an authorize only - but that would then burden the merchant with going back to each of those and capturing the charge. There is no admin screen to do that - nor a database to keep track of outstanding "auth" transactions. If this is the objective - I would want to do that directly in QB, as it has the API to submit and track and capture those outstanding auth transactions.

[M B Walker]

What you describing can be done - but it is not a "simple solution". The XML submission in Zen specifically crafts it as a sale (authorize and charge). One could re-write the XML message to be an authorize only - but that would then burden the merchant with going back to each of those and capturing the charge. There is no admin screen to do that - nor a database to keep track of outstanding "auth" transactions. If this is the objective - I would want to do that directly in QB, as it has the API to submit and track and capture those outstanding auth transactions.

Thanks for the quick reply.

I want to be burdened. In fact, because of the potential for delay or changes from order to shipment it's essential for me to authorize first, then capture once the item is shipped. (It's easy to capture the authorization via QBMS, so the "burden" is actually pretty light.)

How would I go about changing ZenCart so that it tells QBMS to authorize only?

[cptok]

Thanks for the quick reply.

I want to be burdened. In fact, because of the potential for delay or changes from order to shipment it's essential for me to authorize first, then capture once the item is shipped. (It's easy to capture the authorization via QBMS, so the "burden" is actually pretty light.)

How would I go about changing ZenCart so that it tells QBMS to authorize only?

Well - I don't think this is a broad need, so it does not make sense to build it into the module as an "option". Also, you do realize that ALL transactions would be auth only? If that is the case, and that is what you want, then the module could be customized to do exactly that.

To accomplish that - you will need to either read up on the XML spec's for transaction submission to QBMS and edit the module to provide that new data stream - or have someone do that for you. Feel free to PM me if you'd like to explore this more offline.

[M B Walker]

Well - I don't think this is a broad need, so it does not make sense to build it into the module as an "option". Also, you do realize that ALL transactions would be auth only? If that is the case, and that is what you want, then the module could be customized to do exactly that.

Strange to hear that this wouldn't be a common request, especially given all the advantages of "Authorize" over "Sale." If you process credit cards as "Authorize" transactions, you have the ability to use QBMS to change the amount of the transaction (to reflect changes in shipping charges, etc.), to accept orders for later shipment, to add in additional items in the time between order and shipment (in case the customer contacts you to make changes), etc. It's far more flexible that a "Sale" transaction.

In addition, it's very easy to Capture Authorizations via QBMS, just a matter of a few clicks from Quickbooks.

I'll PM you to explore further, but would like to hear from anyone else reading this who has any suggestions or thoughts on this topic.

[cptok]

QBMS module has been updated to 1.9 and just going through double checking and final testing with the gracious help from Mydanilo.

This update resolves a legacy issue which could allow two distinct transactions submitted very close together to be erroneously considered a duplicate at merchant service - and therefore the second charge not recorded. This has been resolved such that if the SAME customer submits an order for the SAME amount within 5 min - then QBMS will consider it duplicate and not process the second charge. Any other orders, so long as they are differing amounts, or different customers, will process successfully as they should. Zen will show these "real" duplicate transactions as identical orders with identical transaction and auth ID's so please be aware of that. I may work on creating a check against prior transaction ID's for that customer and generating an immediate error on checkout - but for users with very large order databases, this could be "heavy" - so thinking about whether that is worth undertaking. In any event, the new 1.9 will be posted shortly, and is probably a good upgrade to use.

[cptok]

Thanks for the quick reply.

I want to be burdened. In fact, because of the potential for delay or changes from order to shipment it's essential for me to authorize first, then capture once the item is shipped. (It's easy to capture the authorization via QBMS, so the "burden" is actually pretty light.)

How would I go about changing ZenCart so that it tells QBMS to authorize only?

This is done - please see your PM for details. Cheers!

[cptok]

This is the time for QBMS users to weigh in. There are two approaches to how QBMS handles "duplicate transactions", and I would like feedback - if any - on what users here think. The next release, which is imminent, relies on this.

Option 1 - ignore the entire duplicate handling that QBMS does - and treat every single submission by a cart user as "valid" and will be processed. Downside to this, and the reason QBMS created the duplicate algorithm, is to handle the possibility of a double click on submit, or if the response does not come back at all (network issue for example), and the user re-submits. Then you end up with two charges for the same order. So Intuit created the "duplicate submission" algorithm on the server side, but it relies heavily on good coding and transaction ID checking on our side (something which has not been taking place).

Option 2 - use the duplicate handling (as we have) which says that if the SAME customer submits an order for the EXACT SAME amount within 5 minutes - it will be considered a duplicate on QBMS end. Reasonable - but up until now, the order would still be a new order in Zen, but not a charge at QBMS. The new 2.0 code handles this by checking if the transaction ID has been issued before - and if it has, it generates an error at the user end that the transaction appears to be a duplicate (same customer, same amount) and does not process or create the new order. If it's in fact a valid second order, they have to wait 4 more minutes to resubmit.

So... what do you think? Go with the enhanced duplicate handling code for 2.0, or eliminate all duplicate handling at all as part of a 1.9 release? Either way - both versions are written and tested - but I need to get one of them up there promptly as 1.8 has a bug in that code and we need to publish that fix.

[M B Walker]

This is the time for QBMS users to weigh in. There are two approaches to how QBMS handles "duplicate transactions", and I would like feedback - if any - on what users here think. The next release, which is imminent, relies on this.

Option 1 - ignore the entire duplicate handling that QBMS does - and treat every single submission by a cart user as "valid" and will be processed. Downside to this, and the reason QBMS created the duplicate algorithm, is to handle the possibility of a double click on submit, or if the response does not come back at all (network issue for example), and the user re-submits. Then you end up with two charges for the same order. So Intuit created the "duplicate submission" algorithm on the server side, but it relies heavily on good coding and transaction ID checking on our side (something which has not been taking place).

Option 2 - use the duplicate handling (as we have) which says that if the SAME customer submits an order for the EXACT SAME amount within 5 minutes - it will be considered a duplicate on QBMS end. Reasonable - but up until now, the order would still be a new order in Zen, but not a charge at QBMS. The new 2.0 code handles this by checking if the transaction ID has been issued before - and if it has, it generates an error at the user end that the transaction appears to be a duplicate (same customer, same amount) and does not process or create the new order. If it's in fact a valid second order, they have to wait 4 more minutes to resubmit.

So... what do you think? Go with the enhanced duplicate handling code for 2.0, or eliminate all duplicate handling at all as part of a 1.9 release? Either way - both versions are written and tested - but I need to get one of them up there promptly as 1.8 has a bug in that code and we need to publish that fix.

My vote is for option 2. It's simpler and I suspect that accidental double clicks are more likely than two identical orders within five minutes.

[mydanilo]

cptok was kind enough to let me test the v 2.0RC and it seems to work as it should.

This is from his change log:

v 2.0 -- 09/05/01
New code to check for and handle duplicate transactions from QBMS. If same customer with same sales amount submits within 5 minutes, QBMS treats as "duplicate" and does not post the charge. BUT Zen was receiving the "OK" status and creating the order. New Code checks the returned transaction ID, and if it exists - it creates an error without posting the transaction.



Cptok asked if this is the way people would like it to function. Yes for me.

Once concern is only the possible slow down when checking ALL orders for duplicates on large db's.

[kwes00]

It is not a error in the Module,

As I stated before this error means

1> Curl was unable to connect to the QBMS Server
2> QMBS Refused to authenticate you,
a> you entered the wrong Ticket Number or the Wrong App Id, or the wrong app user, or the app was not mapped to themerchant account

Are you using the hosted or Desktop security model?
Are you tring a Live or Demo Account. and did you select the proper setting in the module for live or demo...

Hello - I read through this thread twice & followed all of the QBMS advice & tips but I'm still getting "An error has occurred within our system while trying to process your credit card" after submitting the final credit card info in Zen Cart

QBMS rep verified:
- we're able to accept webstore payments
- Visa flags are checked
- the connection ticket (desktop-production) is active on the account

The payment module (v1.3.8) was installed & reinstalled and is configured with the correct AppID, App login, & connection ticket.

I reset the QBMS setting "process with web store" off & then back on & waited a full 24 hours, plus confirmed it was enabled with QBMS.

Our site is hosted through Godaddy & they confirmed a proxy for the cURL is not required, so our proxy status is set to false & the cURL proxy address is null.

Any other ideas or suggestions would be greatly appreciated

Thanks!