QuickBooks Merchant Service

M B Walker:

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.

cptok:

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?

M B Walker:

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.

cptok:

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.

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.

M B Walker:

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!

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.

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.

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.

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.

:clap:

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.

the_ancient:

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!

kwes00:

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!

Here's the fix for anyone else using Godaddy to host Zen Cart, connecting to QBMS

Within the file includes>modules>payment>qbms.php

1. Remove the line:
   curl_setopt($clientURL, CURLOPT_SSL_VERIFYPEER, 1);

2. Add these two lines in its place:
   curl_setopt($clientURL, CURLOPT_SSL_VERIFYPEER, false);
   curl_setopt($clientURL, CURLOPT_SSL_VERIFYHOST, 0);

kwes00 - In my opinion, that is a big (very big) mistake. Do you understand what changing those settings does? Remember - you are sending customer credit card information. I would be very careful of making changes such as this without VERY clearly understanding what you've changed, and what exposure that might create for you.

This is open-source code, so of course you can change it as you like. So take the above advice... or not. But I can tell you I wouldn't make that code change (both you list) and take customer cc data.

My 2 cents...

PS - It might be alright to turn off "verifypeer" (if GoDaddy really does have broken libcurl). But turning both off... ??

Quick reality check for all credit card module users. PLEASE be very careful "hacking" these modules (QBMS or any other). It's one thing to hack and play with a skin, or display modules etc., and quite another to make code changes to credit card processing modules.

Think about it - at least just for a brief moment. If you have a code error, and a bunch of charges (possibly a great many?) get disputed by the cc holders... who do you think gets hit with the losses? The merchant service company will reverse those amounts from the vendor. If there are additional exposures say for example you send the credit card data to an unverified destination, and there end up being large additional liabilitites... who do you think will get that call? The vendor in this chain of events has a great deal of exposure - especially since these are online transactions (no signature, no swipe, no physical card).

Enough said. Message is - please be responsible when handling financial transactions. This is open source, and "distributed without warranty", so anyone is clearly free to make changes and hack away. But IMHO, Mydanilo has it right, tighten up security on these transactions (such are requiring correct CVV and AVS) rather than loosening it up.

Definitely not trying to offend anyone. Just think it's an important awareness to have in working with these transactions.

Here is another solution, don't host with Godaddy for Zen Cart. Too many issues.

NEW VERSION QBMS 1.9

(Includes important bug fix. All users encouraged to update to latest version.)

v 1.9 -- 09/05/09

• Optimized duplicate search so that large db's do not get impacted by duplicate handling.

• New feature to provide better error reporting to customers. Denials vs. validation now recognized and handled separately.

• 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 creating an order.

• Fix legacy bug in XML transaction request ID. This could cause transactions which submit very close together to be treated as duplicates at QBMS.

Odd problem I have. I can make purchases with 2 of my credit cards and get them to go through. The third one spits back an error " An error has occurred within our system while trying to process your credit card. Please try this transaction again"

If I change the address, this card will work. In my web store security settings I have accept transaction for all of the billing and zip code matches. Why would this work if I only put in a wrong billing address?

It seems a lot of cards are not working if you put in the correct billing address. Why would this be?

First, and most important, what version of QBMS module are you running? The AVS/CVV checking and return code handling has been modified a lot in recent versions.

Most recent version of both qbms and zen-cart.

OK - if by "most recent version" you mean 1.9 then the following information would be needed:

What are the 3 credit cards? (Visa, MC Amex etc.)
What specifically is the 3rd card that fails?
What does the QBMS merchant center (online) report about the third attempt?
What is an example of "a lot of cards are not working if you put in the correct billing address"?

Unless there is some trail to follow which gives some clue as to what you're experiencing - there is no way to identify (and therefore fix) what might be a problem. Problem could be on your end, or could be in the code... although I've not seen other similar failures (yet anyway).

Yes, I am using 1.9 Here's how it went.

1st, Visa Credit using correct address goes through.
2nd. Visa Debit correct address goes through.
3rd. MC Debit Correct address comes back with error "An error has occurred within our system while trying to process your credit card. Please try this transaction again"

4th: Same MC Debit, wrong address, works.

This one is wierd..

5th: Visa debit, Correct billing address with apt on address line 2, works.

6th: Same visa Debit, correct billing address with apt on 1st line, error "An error has occurred within our system while trying to process your credit card. Please try this transaction again"

7th: Same visa debit, wrong billing address, works.