Business-OCV

 view release on metacpan or  search on metacpan

OCV.pm  view on Meta::CPAN

#    the settlement date, card info, merchant + terminal IDs)
#
# OCV LIVE SERVER BUGS
#
#  Unfortunately the Ingenico 'live' server (v2.08) has also shown problems,
# with one issue of a complete lockup after a totals requests (the NT registry
# had to be edited to restore service). Additionally, the server is found to
# issue unsolicted 'logon responses' around once per week. Ingenico have 
# advised this is an "undocumented feature". 
#  To work around this, LOGON responses to non-LOGON requests are 
# transparently discarded (the event is logged).
#
#
# MISCELLANEOUS NOTES ON THE CODE
#
#  As is discussed below in "Message Format Specifications", each OCV 
# message is described via a table of field name => data type pairs.
# Internally these are manipulated via hashes (see notes in the code 
# for the details). The use of hashes has required a bit of mucking
# about due to a hash's unpredictable ordering, though at the time
# of writing there was mention of "pseduo-hashes", i.e. arrays which

OCV.pm  view on Meta::CPAN

# Get the status of a given transaction, specified by its Transaction 
# reference number (string), TxnRef. If TxnRef is not provided, 
# _transaction will default to the last one.
{
	shift->_transaction(TT_TRANS_STATUS, 
		CardData => '', CardExpiry => '', Amount => '', AuthNum => '', 
		@_,
		PolledMode => POLL_BLOCK);
}

# the following set of subroutines will transparently retry the transaction
# in the face of SERVER BUSY responses (up to a limit)
sub _busy
{
	my ($s, $self, @a) = @_;
	my $m;
	my $n = $self->{'busyattempts'};	# maximum no. of attempts
	$m = $s->($self, @a);
	while ($m and $m->ResponseCode eq TRANS_BUSY and $n-- > 0)
	{
		select(undef, undef, undef, $self->{'busywait'} * (0.5 + rand));

utilities/OCVtotals  view on Meta::CPAN

#    not provided by the bank.
# **
# NOTE: this procedure (using the OCV server) is unreliable, the OPS
# maintains it's own totals logging and this should be used instead.
# **
#
# Note on Settlement Dates:
#  The desired day is specified as an offset from the "current" settlement
# day. The OCV's notion of the current settlement day is generally that for
# the last transaction - which may not have been for some time. i.e. the
# current day may not be "today"! The OCV transparently skips idle days,
# so requesting an offset of say 0 and then 1 on the 1/3/00 could conceivably 
# return settlement dates of 25/2/00 and 7/2/00 if there were no transactions
# on any days between.
#  Furthermore, it is unspecified whether settlement days are independant of 
# Accounts - that is, whether the loop below could return different settlement
# days for the same day offset but different account numbers. To avoid any 
# ambiguity the settlement date is printed with each listing.

use strict;

utilities/totals  view on Meta::CPAN

#   - note: you generally shouldn't use an active log (one which is still
#     having entries appended). Buffering will very likely bite you.
#
# - the transaction log may contain entries for a number of different 
#   transaction types: (requests) PURCHASE, REFUND, STATUS, PREAUTH, 
#   COMPLETION; and RESPONSE. To extract the totals information, only
#   the PURCHASE/REFUND and RESPONSE records are required and used by this
#   program.
#
# - the OCV server's totals request 'offset' parameter is an integer number
#   of days from the current period - however 'null' days are transparently
#   skipped. Basically, this makes it difficult to be certain which offset
#   you need to use to get a particular day. This program can use a date
#   offset, but the offset is from today and does not skip 'null' days.
#
# - whilst this program uses the OCV module, it does not actually contact 
#   the server so can be run "off-line"
# - the OCV, and logs thereof, give monetary amounts as integer cents. To 
#   avoid introducing any rounding errors, this is carried through here,
#   the final division to dollars is done at output.
#