[ic] Protx Payment Module Authentication

Lyn St George lyn at zolotek.net
Fri Jan 9 11:37:55 EST 2004

On Fri, 09 Jan 2004 15:09:05 +0000, Sandy Thomson wrote:

>Lyn St George wrote:
>>On Wed, 07 Jan 2004 18:01:44 +0000, Sandy Thomson wrote:


>>Hmm.. Try this: in transactions.pgsql, define the field next as
>>'vachar(3) default 0' (or just update this field to be 0 in the table)
>A bit of an update. When i get the internal server error, the 
>transaction gets through to protx ok, and that is fine, i think the 
>problem is definately with my transactions table. I have tried the 
>varchar field thing you suggested, and i still get the same problem.
>Changes to the transactions table from default:
>1. New protx fields were put in as 'text' fields.
>2. I removed the fields 'avs', 'update_date', 'auth_code' and 'parent' 
>as they never seemed to get used.
>3. I changed the next field to as you suggested above.
>4. All other fields are either timestamp fields (with timezone) or text. 
>There are no 'not null' modifiers anywhere in the transactions table.

I recall a problem with the timestamp and Postgres - can't think of the
details off hand but I have a strong suspicion that it resulted in the
kind of error you're getting. Try inserting these values into Postgres
from the pg monitor for confirmation. Hmm .. looking through an old 
transactions.pgsql used at one time for Protx, I see that there is no 
timestamp there - it's a fair guess that I removed it for a good reason ...

>I notice that when you do a refund, on the protx site they give you a 
>related transaction id code (which points to the original transaction), 
>however there seems to be no place in the database for this, is this 

There certainly should be - you need those 'related' fields in order to
do any further operations on a transaction (repeat, refund, ..)


>For our use i dont think the orderline table needs to be entirely 
>consistent, as long as it works when a new order is placed (which it does).
>We have a filemaker database which pulls things from the sql tables on 
>our webserver.
>I am thinking i could maybe take your code and rewrite it somewhat, so 
>for instance  filemaker can invoke a perl script, which sends a refund 
>message (for instance) to the server (which has the ssl certificate) 
>over something like ssh, and then forwards the request over ssl to 
>protx. If i get anywhere i will publish the code.

??? Why not do the refund from the terminal and let filemaker update
itself from the pg table.

Lyn St George
+ http://www.zolotek.net .. eCommerce hosting, consulting

More information about the interchange-users mailing list