Jump to content
Sign in to follow this  
jcall

[Support] TrustCommerce payment module

Recommended Posts

TrustCommerce Payment Module v2.0

Dec 24, 2005

Contributor: Jared Call

 

This release adds:

- postauth transaction in osC Admin

- credit transaction in osC Admin

- view TC transaction status in osC Admin

- link to TC Vault in osC Admin

- TC transaction history in osC Admin

 

Download this contribution at: http://www.oscommerce.com/community/contributions,127

 

This is the support thread.

Edited by jcall

Share this post


Link to post
Share on other sites

Durring testing with a customer I found that when a purchase amount ends with 0 or multiple 0's they are dropped off. So if a purchase is made for $411.00 the value being sent to TrustCommerce would be 'amount=411'. Since the amount field is in cents this would charge the card for $4.11. The correct value for $411.00 should be 'amount=41100'.

 

Brett Pippert

TrustCommerce

Share this post


Link to post
Share on other sites

Brett,

 

Thank you for the feedback!

 

Were you doing a sale, a preauth, or a postauth?

 

-jared

Edited by jcall

Share this post


Link to post
Share on other sites

Jared,

I think it is partly related to the rounding function you added around line 443 in trustcommerce.php module file. I replaced that line with the old line from version 1.1.5 and it may have cleared up that issue. But would leave the problem it was meant to solve still present.

 

Jim

Share this post


Link to post
Share on other sites

I'll look into it - - round shouldn't remove decimal places unless it's told to. If that's what's happening, then I can probably figure out some parsing mumbo jumbo to take care of it.

 

-jared

Share this post


Link to post
Share on other sites

Jared,

 

round is where the issue is coming from. I have tested it with using number_format instead of round and the zeros get sent to our servers properly. They do not get sent properly with round as it is being used.

 

Another issue that I have found is that the cvv is not being sent through to our servers. I believe this is also an issue with older payment modules as well. This is resolved by adding the line 'global $HTTP_POST_VARS;' inside 'function process_button()'. When you make your release please include this change as well.

 

Brett

Share this post


Link to post
Share on other sites

So what's the story on this?

 

This thread ends on Jan23, and it's March 13 now... The download is still the

december 25 version.

 

This is a really big deal, according to this thread this code is broken, but the release is still up.

If the release is no good, why is it still up?

 

This isn't just some minor annoiance, it's a major glaring "cancel the release" bug.

Why hasn't this been fixed, or the release pulled down?

 

I'm already finished installing 2.0 and I'm supposed to launch yesterday.

Tomorrow I have other things to do. Now I don't get to sleep tonight.

You should state on the release that there are serious bugs that you have

known about for a month and a half...

 

This is unacceptable for financial processing software... Have you no pride at all?

Share this post


Link to post
Share on other sites

George,

 

It is apparent that yours is an emotional response. I regret your frustration.

 

It is true that the code contains the bug to which you are referring with your post. It is also true that many other contributions, including other payment gateway code, contain bugs. I can refer you to some Authorize.net or PayPal module threads that will erase any doubt to the contrary. This module does not purport to be bug-free, only to be free of charge. Please don't complain that your free lunch isn't tasty enough.

 

The bug will be fixed. You can even fix it, if you like, or pay to have someone else fix it for you. Why isn't it fixed already?

1) There is an easy workaround.

2) Nobody seemed to be worried about it.

3) This module is not the only item that requires my time.

4) Nobody else has fixed it.

 

Until the bug is fixed, there is an easy workaround to the bug in question. Set the module to pre-auth. If the order ends in a zero, the bug will occur, and the card will be pre-authed improperly, as the posts above indicate. Since the card has been pre-authed, you use the Vault to post-auth for the proper amount.

 

-jared

Share this post


Link to post
Share on other sites

All,

 

I have made the appropriate bug fixes to resolve the two issues that have been pointed out so far. I replaced the two occurances of round with number_format as it had been in previous versions of the payment module. The problem with round is that it drops trailing zeros after the decimal point. Those trailing zeros matter in this module. The CVV issue was resolved as stated previously by adding the line 'global $HTTP_POST_VARS;' inside 'function process_button()'. I have posted the updated payment module on the Contributions page.

 

Brett

Share this post


Link to post
Share on other sites

Thank you, Brett.

 

The reason that I switched it from round() to number_format() in the first place was that occasionally, the total recorded in the trustcommerce table and the total recorded in the orders_total table would differ by $0.01, causing other problems.

 

I'll see if I can figure out a better way to get this to work.

 

-jared

Share this post


Link to post
Share on other sites

Jared,

 

Changing catalog/includes/modules/payment/trustcommerce.php line 233

from $order_total = $order->info['total'];

to $order_total = number_format($order->info['total'],2,'.','');

Should solve this issue. This way you make sure that the value going into the mysql table is exactly the same as what was sent to TrustCommerce.

 

Brett

Share this post


Link to post
Share on other sites

Brett,

 

I'm using an older version, and testing the latest TC payment module everything seems to work up to checkout_confirmation.php, then when you click "Confirm Order" I get this error:

 

1146 - Table 'mydomain_com_checkout.trustcommerce' doesn't exist

 

insert into trustcommerce set transid='013-##########', avs='N', action='preauth', amount='420.00', status='approved', trans_date=NOW()

 

[TEP STOP]

 

Do you know what would cause this error?

 

Thanks,

EricK

Share this post


Link to post
Share on other sites

The trustcommerce table is supposed to be created when the module is initialized in Admin. It will not be successful, though, if the user you have in admin/includes/configure.php does not have CREATE TABLE rights.

 

-jared

Share this post


Link to post
Share on other sites

When I click install from the Payment Modules I get this:

 

1067 - Invalid default value for 'trans_date'

 

CREATE TABLE trustcommerce (trustcommerce_id int(11) NOT NULL auto_increment, transid varchar(24) NOT NULL default '001-0000000001', child_transid varchar(24) NOT NULL default '0', status varchar(40) NOT NULL default 'error', avs char(1) NOT NULL default '1', action enum('preauth','postauth','sale','credit','chargeback') NOT NULL default 'sale', amount decimal(14,2) NOT NULL default '0.00', trans_date datetime default 'NOW()' NOT NULL, PRIMARY KEY (trustcommerce_id), UNIQUE KEY unique_action (transid,action), KEY transid (transid), KEY child_transid (child_transid), KEY status (status), KEY avs (avs), KEY action (action), KEY amount (amount), KEY trans_date (trans_date)) COMMENT='TrustCommerce Payment Gateway Response Table'

 

[TEP STOP]

 

Any thoughts?

 

TIA

Share this post


Link to post
Share on other sites

I get the same error, then tried to insert the sql statement using phpmyadmin, and get this error.

 

Error

INSERT INTO configuration( configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, set_function, date_added )

VALUES (

'Enable TrustCommerce Module', 'MODULE_PAYMENT_TRUSTCOMMERCE_STATUS', 'True', 'Do you want to accept TrustCommerce payments?', '6', '0', 'tep_cfg_select_option(array(\'True\', \'False\'), ', now( )

) "); insert into configuration(configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, date_added) values ('Customer ID', 'MODULE_PAYMENT_TRUSTCOMMERCE_CUSTID', '', 'Customer ID used for TrustCommerce payments', '6', '0', now())"

 

MySQL said: Documentation

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '");

insert into configuration(configuration_title, configuration_key, configura' at line 1

The server is running MySQL 5.0.27 ... I did get it to work on a server running MySQL 4.0.26, so the sql statement format appears to be a problem.

 

Regards,

EricK

Share this post


Link to post
Share on other sites
When I click install from the Payment Modules I get this:

 

1067 - Invalid default value for 'trans_date'

 

CREATE TABLE trustcommerce (trustcommerce_id int(11) NOT NULL auto_increment, transid varchar(24) NOT NULL default '001-0000000001', child_transid varchar(24) NOT NULL default '0', status varchar(40) NOT NULL default 'error', avs char(1) NOT NULL default '1', action enum('preauth','postauth','sale','credit','chargeback') NOT NULL default 'sale', amount decimal(14,2) NOT NULL default '0.00', trans_date datetime default 'NOW()' NOT NULL, PRIMARY KEY (trustcommerce_id), UNIQUE KEY unique_action (transid,action), KEY transid (transid), KEY child_transid (child_transid), KEY status (status), KEY avs (avs), KEY action (action), KEY amount (amount), KEY trans_date (trans_date)) COMMENT='TrustCommerce Payment Gateway Response Table'

 

[TEP STOP]

 

Any thoughts?

 

TIA

 

Had this same problem and had to contact the TrustCommerce Technical support to get a fix. It has to do with using MySQL version 5. Here's the solution that worked for me:

 

"You will need to modify the file catalog/includes/modules/trustcommerce.php

 

On the line for "CREATE TABLE "

.MODULE_PAYMENT_TRUSTCOMMERCE_TABLE_TRUSTCOMMERCE change "trans_date

datetime default 'NOW()'" to "trans_date datetime"

 

It is okay to remove the default for this field because everywhere that data is inserted into the table the trans_date field is set to NOW() anyways."

 

After making this change the install worked fine and the tables were created. Hope it helps.

Share this post


Link to post
Share on other sites
Had this same problem and had to contact the TrustCommerce Technical support to get a fix. It has to do with using MySQL version 5. Here's the solution that worked for me:

"You will need to modify the file catalog/includes/modules/trustcommerce.php

On the line for "CREATE TABLE "

.MODULE_PAYMENT_TRUSTCOMMERCE_TABLE_TRUSTCOMMERCE change "trans_date

datetime default 'NOW()'" to "trans_date datetime"

I had some trouble doing this because without the actual code, I wondered if I was doing the right thing. I did and it worked for me. I changed (line 392):

tep_db_query("CREATE TABLE " . MODULE_PAYMENT_TRUSTCOMMERCE_TABLE_TRUSTCOMMERCE . " (trustcommerce_id int(11) NOT NULL auto_increment,  transid varchar(24) NOT NULL default '001-0000000001', child_transid varchar(24) NOT NULL default '0', status varchar(40) NOT NULL default 'error',  avs char(1) NOT NULL default '1',  action enum('preauth','postauth','sale','credit','chargeback') NOT NULL default 'sale',  amount decimal(14,2) NOT NULL default '0.00', trans_date datetime default 'NOW()' NOT NULL,  PRIMARY KEY  (trustcommerce_id),  UNIQUE KEY unique_action (transid,action),  KEY transid (transid), KEY child_transid (child_transid), KEY status (status),  KEY avs (avs),  KEY action (action),  KEY amount (amount), KEY trans_date (trans_date)) COMMENT='TrustCommerce Payment Gateway Response Table'");

 

to:

 

 tep_db_query("CREATE TABLE " . MODULE_PAYMENT_TRUSTCOMMERCE_TABLE_TRUSTCOMMERCE . " (trustcommerce_id int(11) NOT NULL auto_increment,  transid varchar(24) NOT NULL default '001-0000000001', child_transid varchar(24) NOT NULL default '0', status varchar(40) NOT NULL default 'error',  avs char(1) NOT NULL default '1',  action enum('preauth','postauth','sale','credit','chargeback') NOT NULL default 'sale',  amount decimal(14,2) NOT NULL default '0.00', trans_date datetime NOT NULL,  PRIMARY KEY  (trustcommerce_id),  UNIQUE KEY unique_action (transid,action),  KEY transid (transid), KEY child_transid (child_transid), KEY status (status),  KEY avs (avs),  KEY action (action),  KEY amount (amount), KEY trans_date (trans_date)) COMMENT='TrustCommerce Payment Gateway Response Table'");

Share this post


Link to post
Share on other sites
TrustCommerce Payment Module v2.0

Dec 24, 2005

Contributor: Jared Call

 

This release adds:

- postauth transaction in osC Admin

- credit transaction in osC Admin

- view TC transaction status in osC Admin

- link to TC Vault in osC Admin

- TC transaction history in osC Admin

 

Download this contribution at: http://www.oscommerce.com/community/contributions,127

 

This is the support thread.

Thank you for doing all of this. This module has not been updated for quite awhile.

 

I installed it and everything I've checked so far seems to work ok but the orders are not showing up in the backend of my store. Any ideas?

Share this post


Link to post
Share on other sites

Me gain, I just wanted to add some more info. I did add the bit of code to orders.php [clip]

 <tr>
		<td class="main"><b><?php echo ENTRY_PAYMENT_METHOD; ?></b></td>
		<td class="main"><?php echo $order->info['payment_method']; ?></td>
	  </tr>
  <!-- Start of TrustCommerce Payment Changes -->
	  <tr>
		<td colspan="2">
		  <?php include(DIR_FS_CATALOG_LANGUAGES . $language . '/modules/payment/trustcommerce.php');
			  if ( (isset($HTTP_GET_VARS['oID'])) && (!(strnatcmp($order->info['payment_method'], MODULE_PAYMENT_TRUSTCOMMERCE_TEXT_TITLE))) )  { 
							  include('orders_trustcommerce.php'); 
				 } 
		  ?>			  
		</td>
	  </tr>
  <!-- End of TrustCommerce Payment Changes -->
<?php

..and the orders ARE in the database, but not in the backend. Mail is being sent out and everything but I can't pull up the orders in the backend. They are not there.

Share this post


Link to post
Share on other sites

Me gain, I just wanted to add some more info. I did add the bit of code to orders.php [clip]

 <tr>
		<td class="main"><b><?php echo ENTRY_PAYMENT_METHOD; ?></b></td>
		<td class="main"><?php echo $order->info['payment_method']; ?></td>
	  </tr>
  <!-- Start of TrustCommerce Payment Changes -->
	  <tr>
		<td colspan="2">
		  <?php include(DIR_FS_CATALOG_LANGUAGES . $language . '/modules/payment/trustcommerce.php');
			  if ( (isset($HTTP_GET_VARS['oID'])) && (!(strnatcmp($order->info['payment_method'], MODULE_PAYMENT_TRUSTCOMMERCE_TEXT_TITLE))) )  { 
							  include('orders_trustcommerce.php'); 
				 } 
		  ?>			  
		</td>
	  </tr>
  <!-- End of TrustCommerce Payment Changes -->
<?php

..and the orders ARE in the database, but not in the backend. Mail is being sent out and everything but I can't pull up the orders in the backend. They are not there.

When you placed the orders, did you select the TrustCommerce Payment Gateway option? The other payment

modules should be disabled I think if you are using us solely as your payment option.

Share this post


Link to post
Share on other sites

Yes, I did select the trustcommerce payment option. They even show up in the vault. I don't think the problem is in the contrib but I don't know where to look. I'm pretty sure admin/orders.php serves up the orders to the backend, which is a file the contrib had me edit, but this file is identical to the one on the working site.

 

If it doesn't get listed in the backend, I can't capture the funds.

 

I have two payment options, paypal standard and trustcommerce. I changed the word trustcommerce to Credit Card so people won't assume it's an exclusive kind of thing like they tend to think paypal is but that did not effect the install that is working.

 

I appreciate your reply and interest.

 

I have been copying files over one by one from the working site to the broken one after I inspect them for differences but have not been able to effect the problem.

 

I cleared the error log and started over. I get this:

 

[09-Jul-2009 13:13:35] PHP Parse error: syntax error, unexpected $end in /home/yada/public_html/checkout_process.php on line 18

 

Here is line 18 from checkout_process.php

 

tep_redirect(tep_href_link(FILENAME_LOGIN, '', 'SSL'));

 

??? grrr. No $end in sight

Edited by crxvfr

Share this post


Link to post
Share on other sites
Yes, I did select the trustcommerce payment option. They even show up in the vault. I don't think the problem is in the contrib but I don't know where to look. I'm pretty sure admin/orders.php serves up the orders to the backend, which is a file the contrib had me edit, but this file is identical to the one on the working site.

 

If it doesn't get listed in the backend, I can't capture the funds.

 

I have two payment options, paypal standard and trustcommerce. I changed the word trustcommerce to Credit Card so people won't assume it's an exclusive kind of thing like they tend to think paypal is but that did not effect the install that is working.

 

I appreciate your reply and interest.

 

I have been copying files over one by one from the working site to the broken one after I inspect them for differences but have not been able to effect the problem.

 

I cleared the error log and started over. I get this:

 

[09-Jul-2009 13:13:35] PHP Parse error: syntax error, unexpected $end in /home/yada/public_html/checkout_process.php on line 18

 

Here is line 18 from checkout_process.php

 

tep_redirect(tep_href_link(FILENAME_LOGIN, '', 'SSL'));

 

??? grrr. No $end in sight

 

To be honest, this sounds like some sort of configuration or modification or data change within the stock OsCommerce setup.

Have you tried posting this particular issue in the main general support for osCommerce? Would it be possible for you to setup a dummy Oscommerce shopping

cart and install the module based on the instructions provided in an attempt to narrow down whether its this contribution, the cart, or some third party change?

I know that sounds like a lot of work... (I've done the load and install of the cart multiple times as I was reorganizing the contribution)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×