[ic] Protx Payment Module Authentication

[Sandy Thomson]

Lyn St George wrote:

>On Wed, 07 Jan 2004 18:01:44 +0000, Sandy Thomson wrote:
>  
>
>>
>>I have been trying to get the webpages protx and protxr working for 
>>refunds etc.
>>Initially i had a 'not null' modifier in the postgres table i was using, 
>>but after removing that things started to happen.
>>
>>Basically, when i input a valid transaction into the webpage it gives 
>>the web browser an internal error.  An error is generated in the error 
>>log saying DBD::Pg::st fetchall_arrayref: there is no such statement 
>>executing at lib/Vend/Table/DBI.pm line 1840
>>    
>>
>
>It's quite a while since I tested things with Postgres, but it worked then.
>I don't recognise that error message at all, but it seems to imply that
>Postgres can't find input values it needs. I don't have Postgres set up
>here at the moment to test with, but I suspect that you haven't logged
>the  values it is expecting to find. Try exporting the transactions table
>after logging a purchase to see what is really there. 
>
>
>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 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 
correct?

>>Possibly some routine is exiting prematurely. I have the protx profile 
>>in etc/profiles.order and the route in catalog.cfg. I also added the 
>>extra lines to etc/log_transaction.
>>
>>Sometimes i get a 'This Transaction Type is not valid' error from 
>>StatusDetail in the payment_results hash. I assume this is a reply from 
>>protx and i dont think you can do certain TxTypes on the testvps server.
>>    
>>
>
>You can do everything on the test server that can be done on the live
>server. Probably, you are trying to do an operation on a transaction
>which is not allowed, eg, a 'refund' on a 'preauth'.
>  
>

Yeah, i realised this after i sent the email ... doh :)

>>Any hints? I have lots of not null modifiers in orderline, and was 
>>wondering if this would affect it? I have the correct permissions on the 
>>tables.  I am also using these pages directly (without the admin UI).
>>    
>>
>
>The orderline table is not used at all (though it should be, for doing 
>refunds/returns - this creates a problem with negative amounts in the
>system which is why I haven't got around to this part ..). I've never
>tried to use this terminal separately to the Admin UI, as it was designed
>to be part of it - though I suppose it should work more or less ...
>

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.