[ic] Writing a new payment module - please help!

[Interchange user]

Thanks for your help. It seems that UK banks follow no such standard, because 
those five uppercase messages that I mentioned below are the *actual* strings 
returned from the bank.

So let me get this straight; AVS is only useful if you settle at a later 
date, and Interchange doesn't actually do anything with the values by default 
other than store them for human checking?

Just looked at the CyberCash module, and there is just one (commented out) 
avs return value - 'pop.avs_code', which makes much more sense to me. What is 
the purpose of having three avs return values in the Signio module, for 
example, if only one value gets returned from the bank?

I took a look inside Payment.pm at the source of the '&charge()' routine and 
saw that the (address of the) result hash returned from payment modules is 
placed in $Vend::Session->{payment_result}, and also returned to whatever 
called the routine, but then what happens with these values? Obviously, some 
keys and values from the result hash must be fixed (such as MStatus => 
'success'), but I'm wondering - are the rest just arbitrary? I ask this 
because I notice there are no columns in the (foundation) transactions table 
corresponding to 'pop.auth-code' and so on.

Your help is greatly appreciated.





On Thursday 13 February 2003 07:52 am, you wrote:
> code match only IS zip match only. zip code = code.  Avs return values are
> standard in the industry and have not changed in years.  Here is a list of
> what the banks actually return.  You should be able to at least use it as a
> reference so you know what variations are possible.
>
> There are also a few new avs codes out for non US transactions, but they
> are not widely used yet.  Most countries do not support avs and you will
> usually get a return of G or U for card numbers issued outside the US.
>
>
> A - Address Matches, Zip code does not
> E - Error
> N - Address and Zip code do not match
> R - Retry, system not available
> S - System not supported by Issuer
> U - Address information not available
> W - 9 digit zip matches, address does not
> X - Exact match address and zip
> Y - Exact match address and 5 digit zip
> Z - 5 digit zip matches, address does not
> G - Non avs participant outside US; not verified
>
> > > > >What do pop.avs_code, pop.avs_zip, and pop.avs_addr expect to
> > > > > receive from the response? The payment gateway I'm using can return
> > > > > several responses including: matched, code match only, address
> > > > > match only, and no match, but there is no 'zip match only'.
> > >
> > > 99.9%, the relation must be:
> > >
> > > pop.avs_code    - > matched     (both zip code and address are matched)
> > > pop.avs_zip    ->  code match only    ( zip code matched only)
> > > pop.avs_addr  ->  address match only   ( as says)
> > >
> > > If you are not sure, it may be a good idea to ask the bank "Does 'code
> > > match only' mean only the zip code is verified"?
> > >
> > >
> > > David
> > > dzhang@msihosting.com
> > > http://www.msihosting.com
> > > Expert -- ecommerce solutions, interchange hosting
> >
> > David,
> >
> > Thank you for your reply, but I don't quite get you on this.
> >
> > According to my documentation, one of the following messages is returned
> > (only) for authorized transactions in response to the card security code
> > and address provided:
> >
> > DATA MATCHED - passed all checks
> > SEC CODE MATCH - security code valid, but address invalid
> > ADDRESS MATCH ONLY - address valid, but security code invalid
> > DATA NOT MATCHED - both security code and address invalid
> > DATA NOT CHECKED
> >
> > What is the point in checking this response *after* a transaction has
> > been authorized? Settlements occur automatically on the same day. I would
> > have thought the messages above would only be returned upon a failed
> > transaction.
>
> > What does Interchange do with the three avs values, and why should they
> > be returned upon a *successful* transaction?
> >
> > I'm very confused!