[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date
][Minivend by thread
]
Re: [mv] Using external online payment systems with minivend?
>Short and quick (i want to see the TV in ca. 15 min.:-) ):
>MD5: What is this?
MD5 is hash algorithm used in verifying that the data signed by the
algortihm is unchanged.
In this case the bank combines all the fields it's going to send and
calculates the MD5
hash checksum for them. So when I receive the in my ok/checkout page I can
check that
the hash code is correct, and thus know that no third party has modified
the payment
information or tries to forge one.
>Internal server error:
>In most common case, you get this from a webserver by any error in any
>script (CGI e.g.).
>Have you looked into the minivend error.log?
The minivend log contains no information about this, so the error is so
fatal that
the minivend doesn't even log it?
>[SNIP]
>> Heres an example what i get from the bank
>>
http://jarnomn-linux/cgi-bin/triosoft/ord/checkout?PTA8XtsJ&KNRO=00000000000
>>
0&VALUUTTA=FIM&VIITE=13&SUMMA=10,00&VERSIO=2&STATUS=2&TARKISTE=CCF3D89D463EA
>> ADCFC58782B6253429F
>
>It this "...checkout..." right? I have believed, you use a special entry
>page!
No the verification has to be done on the same page where the order is sent
for processing. Otherwise user might try to bypass the payment by calling
the checkout page directly, just using URL like.
...cgi-bin/triosoft/ord/checkout?PTA8XtsJ
Which would work if the checkout doesn't verify that the payment data is along
in the URL and that it is correct.
>> The structure you can see from above elements, and the fields are
>> KNRO (customer number)
>
>Is this always "000000000000" ?
Whoops, translation bug. The KNRO means that bank customer number (the web
shop),
and it's 00000000000 in testing phase, because I haven't opened online account
for the shop yet.
>> VALUUTTA (currency)
>> VIITE (bank reference)
>> VERSIO (system version)
>> STATUS
>
>What ist this? Has this a value or information about the success/not
>success process or not?
All those fields are used in verifying the data, the STATUS is used only in
testing page.
It signifies is it a test payment or actual transaction..
>> TARKISTE (checksum formed with MD5 algorithm from the above)
>>
>> The problem however is that the minivend gives an internal server error
>> when the bank
>> tries to send the user back with this URL.
>
>Has your checkout page the codes to get the informations from the bank?
>Sorry! I see nothing!
The information is included in the URL.
So when I call the bank give it the information in URL (using form),
and the bank calls me back using URL containing the transaction data in
GET format)
So this is the data that I get form the bank
....KNRO=000000000000&VALUUTTA=FIM&VIITE=13&SUMMA=10,00&VERSIO=2&STATUS=2&TA
RKISTE=CCF3D89D463EA
>Once more! I donīt know about your checkout page. I have believed, your
>bank call another page e.g. back-to-the-root.html, ok-or-not.html or
>whatelse.html, but not the checkout page.
>Can you post a part of the codes, which get the information from the
>bank?
The codes I use are the ones you showed me when I asked how to read POST/GET
data from URL.
[perl arg="cgi scratch"]
$Safe{'scratch'}->{"KNRO"} =
$Safe{'cgi'}->{"KNRO"};
$Safe{'scratch'}->{"VALUUTTA"} =
$Safe{'cgi'}->{"VALUUTTA"};
$Safe{'scratch'}->{"VIITE"} =
$Safe{'cgi'}->{"VIITE"};
$Safe{'scratch'}->{"VERSIO"} =
$Safe{'cgi'}->{"VERSIO"};
$Safe{'scratch'}->{"STATUS"} =
$Safe{'cgi'}->{"STATUS"};
$Safe{'scratch'}->{"TARKISTE"} =
$Safe{'cgi'}->{"TARKISTE"};
[/perl]
I haven't yet had time to work the MD5 checksum verification routine,
but the basic structure is simpe.
1.Verify that the sum is the same as in the shopping cart
2.Verify that the mv_order_number matches the one used in forming the field
VIITE
3.Verify the MD5 checksum.
>BTW:
>I am not sure! All chars after "?" can be ingnored by any script or the
>script works well with empty values and has failure with non empty
>values.
>
>[SNIP]
>> >[perl arg="cgi scratch"]
>> > $Safe{'scratch'}->{"uid"} = $Safe{'cgi'}->{"uid"};
>> > $Safe{'scratch'}->{"time"} = $Safe{'cgi'}->{"time"};
>> > $Safe{'scratch'}->{"date"} = $Safe{'cgi'}->{"date"};
>> > $Safe{'scratch'}->{"status"} = $Safe{'cgi'}->{"status"};
>> >"";
>> >[/perl]
>> >
>> Hey, thats easy :)
>>
>> So what I do is to is to read the values in a perl block,
>> calculate the MD5 checksum and set the status to OK/FAIL
>> by whether the the checksum is correct or not.
>
>Hmmm....what is your result or problem now? It works well and you get no
>internal server error?
>Did you used codes like above? If yes, can you post this to the list
>with a short descriptions (e.g. from which page is this codes comming
>from....)?
>Sorry! It seems me, i am in a questions-and-answer-game!
Heh, sorry I'm still trying to figure this out myself. But the internal
sever error
seems the be caused by how the minivend handles the customer id on it's links.
The problem is caused by that the URLs used by minivend are in form
....checkout?PTA8XtsJ as they should be in form checkout?custid=PTA8XtsJ to be
correct by the URL standards.
One way to work around is to use cookies in the shop, and give a plain URL
to the bank,
one without minivend customer id number...
>This can be done later! Or not?
>First, the script has to work well and can work with all values from
>your bank!
>After this, we make a brainstorming to find a right solution to solve
>the next problem.
It would be better that way, but the problem is that the payment must be
secure,
and that cannot be added later on, it must be thought in in the first place.
>> Because otherwise some clever user might reload the checkout page several
>> times after
>> it has processed the order, to make several orders, but paying just once.
>> I think that the value mv_order_number could be used in this (I use it in
>> VIITE field)
>>
>> [if scracth viite !eq mv_order_number)
>> [tag op=header interpolate=1]
>> Status: 302 moved
>> Location: [area href="nicetry.html"]
>> [/tag]
>> [/if]
>
>This is not good! The mv_order_number is increased after the order
>process! Hmmm...search the mailarchiv and look for "mv_order_number".
>You will find more information!
>
>BTW: What will be happen with this number, if two or more visitors make
>an order process in the same time?
So the order number should be used only in the order processing itself?
Hmm, I think that you are right.
Hmm, I have think about this later.
I'll start doing some implementation of the system and testing what works and
what dosn't before worrying about this any more.
Thanks for all your help, I'll get back in touch when I've done the basic
implementation.
With sum and MD5 checksum checking.
Jarno.
