gmane.comp.lang.perl.modules.bop.devel

Net::HTTPS::Any test bug / install failure, was: Business::OnlinePayment

Ivan Kohler — 2013-02-07T21:28:20

I certainly wouldn't refuse a patch, also happy to add you as a co-maint 
for Net::HTTPS::Any


For historical perspective, the whole B:OP:HTTPS / Net::HTTPS::Any thing 
was mostly inspiried by Interchange's historical support for either 
module and Mike Heins's reply about it being nice to have
http://www.icdevgroup.org/pipermail/interchange-users/2002-September/026005.html

Re: Business::OnlinePayment

Stefan Hornburg (Racke — 2013-02-07T12:44:00

Ivan, can you please fix the Net::HTTPS::Any bug
https://rt.cpan.org/Public/Bug/Display.html?id=73363?

This causes install failure of Business::OnlinePayment unless you have both
SSLeay modules present.

Please let me know if you need assistance.

Regards
Racke

Re: Proposed - Barclaycard EPDQextra Plus API Direct Link Integration

Simon Waters — 2013-02-05T12:17:38

Thanks,

error reporting will likely get some attention, Currently if it Carps it 
doesn't store the reason in the error_message. I think it should.

Amount currently has to have 2 decimal places. Some of my test cases are 
failing because they were passed as whole pounds, which the 
documentation says is allowed for Business::OnlinePayment

So will sort those items later today. Otherwise it seems to be passing 
tests I need (and Barclays allow me to perform - why are foreign 
currencies so hard for credit card processors to provision?) before we 
put it live for our own limited use.

I asked in PAUSE for the name "Business::OnlinePayment::EPDQPLUS" I hope 
that was the right thing to do.

Do/Should we have some standard tests for all modules? e.g. To ensure 
compliance with assumptions across modules like "Expiry date".

The parameter "eci" doesn't seem to fit nicely in the current scheme. 
Basically it is 7 for SSL transaction with card holder present, 9 for a 
recurring transaction. In our case we insist on a CVV2 when cardholder 
present, so we can set it to 9 when the CVC is not present safely as 
they are recurring transactions. Barclaycard allow you to set a default 
for this value if not present so it doesn't need to be mandatory. Don't 
think it is appropriate to encode logic concerning this as our logic is 
not general enough and requiring an ECI of 9 if CVV2 is missing might 
fail for those for whom this is the default.

  Simon



http://cpan.perl.org/authors/id/S/SR/SRW/EPDQPLUS.pm

Currently the raw "pm" file is there.

Changes in version 0.02 over original are:

Switch to SHA512 from SHA1 since it is probably stronger.
Remove blank parameters from hash
Make the hash optional as this eases testing hugely
Add test_transaction support
Added failure_status method as advised by Ivan
Add "_info" introspection
Added expiration handling of MM/YY as Ivan suggested.
Removed routines already in OnlinePayment.pm
Updated documentation

I'll do something prettier (More CPANesque anyway) shortly, although 
"Module::Starter" reports syntax errors in its tests when I asked cpan 
for it. Going to be one of those days I can tell.

SHA1 is the default at Barclaycard, users just have to pick SHA512 in 
the global security settings. I understand for this sort of purpose SHA1 
is considered acceptable still according to NIST but we have a choice of 
3 types of strong box for the armoured car from cardboard box to park 
bench, I see no advantage in using the two weaker ones.

Noted Barclaycard accepted sha1_base64 output but their own code does 
the equivalent of sha1_hex (or sha256_hex, or sha512_hex) in uppercase, 
so I made it do the same so the hash produced in DEBUG look exactly like 
the one's on their test page.

Main pain is the optional hash which if you get the string built wrongly 
will fail, with no way you can figure it out. Guess that is why any 
working implementation is always useful to work from.

Re: Proposed - Barclaycard EPDQextra Plus API Direct Link Integration

Simon Waters — 2013-01-24T14:48:33

Added. Although Barclaycard return only 7 options broadly categorised as:

SUCCESS
  Authorised
  Payment requested

FAILURE
  Invalid or incomplete
  Authorisation refused

WAITING
  Authorisation waiting

UNCERTAIN
  Authorisation not known
  Payment uncertain

So I think it only makes sense to return "declined" when invalid or refused.

We use to get more information, but I think it is considered bad form 
for them to provide more details (NSF) than success, or failure in 
Europe these days.

The others "uncertain" results don't fit into the predefined categories, 
and "waiting" isn't applicable the way we use the API.


Added.

Re: Proposed - Barclaycard EPDQextra Plus API Direct Link Integration

Simon Waters — 2013-01-24T14:28:14

Okay so not a new sort of dependency, and not crazy bad. Wasn't sure 
with HTTPS if I should be testing the https_post return. I will feed it 
more nonsense in testing which will reveal any failings in error handling.


Well I'm using it.


Maybe because the other Perl SSL modules didn't verify the certificates 
correctly. I'll assume you knew what you were doing back then ;)


Okay - useful to know.


Sorted.

Re: Proposed - Barclaycard EPDQextra Plus API Direct Link Integration

Ivan Kohler — 2013-01-24T09:37:43

Unfortunately this is one place which is probably not as standardized as 
it could be.

In my code which uses B:OP I pass all three, to work with as many 
gateways as possible.

It probably wouldn't be a bad idea to have the B:OP base class help 
gateway classes provide name from first_name and last_name or 
vice-versa.



The most important thing is the first section of "Handling failures" in 
notes_for_module_writers_v3:

    - If your processor module encounters a setup problem, communication        
      error or other problem that's prevents the card from even being           
      run, you should die (or croak) with a useful error message.  Setting      
      is_success to 0 and returning normally should only be done when the       
      transaction *processing* was sucessful (or at least elicited some sort    
      of result from the gateway), but the transaction itself returned a        
      "normal" decline status of some sort.

The subsequent part about the new "failure_status" support would be nice 
to have, but is less important.



Well, since you asked and all, an _info subroutine providing 
introspection data would be nice.

Re: Proposed - Barclaycard EPDQextra Plus API Direct Link Integration

Ivan Kohler — 2013-01-24T09:13:18

https://metacpan.org/requires/distribution/XML-Simple lists PaymenTech, 
IPPay and Litle also using XML::Simple.



I would call it a "nice to have", but probably the least important thing 
in notes_for_module_writers_v3.  Problems with one or other of the SSL 
modules are less common than they used to be.

I'd like to ask Ivan from 7 years ago why he thought it should be at the 
top with exclamation marks.



http://search.cpan.org/dist/Business-OnlinePayment/OnlinePayment.pm#content%28%content%29

AuthorizeNet was the first module and in the past was probably the 
canonical source of standard keys and value formatting.  The code itself 
has grown too much to recommend as a starting point for new modules.

Taking a quick look the docs, WorldPay does appear to have a few 
inconsistancies wrt standard fields: "exp_date" instead of the standard 
"expiration", "cvc" instead of the standard "cvv2".



"MM/YY".  I have now documented this in the base B:OP documentation and 
corrected the example.



Right.  



I would be happy to upload if otherwise it would not be available, but I 
would certainly certainly encourage you to go ahead get a CPAN ID and 
upload it yourself.  There is a minimum of bureaucracy involved, and you 
get a nifty gravitar and your own bug reports.  
http://pause.perl.org/pause/query?ACTION=request_id

Re: Proposed - Barclaycard EPDQextra Plus API DirectLink Integration

Simon Waters — 2013-01-23T15:15:24

Okay, my first stab - which works with my test scripts for "Normal 
Authorization" only.

Basically:

1) It multiplies "amount" by 100 (or sets to invalid)
2) Remaps fields
3) Ensure the SHA hash parameter is created correctly
4) Parses the response codes

Otherwise it is fairly vanilla HTTPS

Heavily based on TCLink.pm

Currently the test server is "hardwired", and I haven't tried 
implementing any of the authentication only responses.

I've mostly answered my own questions.

Things I know now.....

Yes I should use Business::OnlinePayment::HTTPS

get_fields and remap_fields methods are in OnlinePayment.pm now - it was 
in the copy of TCLink.pm I worked from, but that one needs bringing up 
to speed as well. So I should just be able to delete these.

I still don't know the preferred format for expiration date in the caller.

This provider wants a "customer name" but BOP seems to offer both "name" 
and "first_name" "last_name. I suspect it can be safely left to 
implementers.

Wouldn't recommend anyone else uses the code yet, on the other hand it 
may save someone a little time if they are using BOP already.

I've no idea how to do the error handling. Fortunately most things that 
don't make sense already fail in "required fields" or fail at 
Barclaycard end and thus get a suitable error back.

EPDQ also has optional ECI field for whether card is present etc. I've 
ignored it for the moment, although some transactions failed with "CVC 
is required" which makes me think that I may need to set it to 9 for 
some types of request we do.

Any constructive criticism or advice welcome.

  Simon



Business::OnlinePayment::EPDQPLUS.pm

package Business::OnlinePayment::EPDQPLUS;

use base qw( Business::OnlinePayment::HTTPS );

use strict;
use warnings;

use Business::OnlinePayment::HTTPS;
use URI::Escape qw/uri_escape/;
use Digest::SHA qw/sha1_base64/;
use XML::Simple;

use vars qw($VERSION $DEBUG);

$VERSION = '0.01';
$DEBUG=1;

sub set_defaults {
     my $self = shift;

     $self->server('mdepayments.epdq.co.uk') unless $self->server; # 
Test server - live is "payments.epdq.co.uk"
     $self->port('443') unless $self->port;
     $self->path('/ncol/test/orderdirect.asp') unless $self->path; # 
Test server - live is "/ncol/prod/orderdirect.asp

}

sub map_fields {
     my($self) = < at >_;

     my %content = $self->content();

     my %actions = ('normal authorization' => 'SAL', # Only one implemented
                    'authorization only'   => 'RES', # from Barclays 
docs 4.3.3
                    'credit'               => 'RFD', # from Barclays 
docs 4.3.3
                   );

     $content{'action'} = $actions{lc($content{'action'} || '')} || 
$content{'action'};

     my $amount = $content{'amount'};

     if ( $amount =~ /-?\d*\.\d\d/ ) { # Match a number with two decimal 
places
       $content{'amount'} = int(100*$amount);
     } else {
       $content{'amount'}='invalid amount';
     }


     $self->content(%content);
}

sub remap_fields {
     my($self,%map) = < at >_;

     my %content = $self->content();
     foreach(keys %map) {
         $content{$map{$_}} = $content{$_};
     }
     $self->content(%content);
}

sub get_fields {
     my($self,< at >fields) = < at >_;

     my %content = $self->content();
     my %new = ();
     foreach( grep defined $content{$_}, < at >fields) { $new{$_} = 
$content{$_}; }
     return %new;
}

sub submit {
     my($self) = < at >_;

     $self->map_fields();
     $self->remap_fields(
#        type              => '',
pspid  => 'PSPID',
         login             => 'USERID',
         password          => 'PSWD',
shasign  => 'SHASIGN',
         action            => 'OPERATION',
         description       => 'COM',
         name  => 'CN',
         amount            => 'AMOUNT', # Note Barclays expect this in 
cents or pence thus $13.23 is transformed to 1323 and £142.00 is 14200
         currency          => 'CURRENCY', # USD GBP EUR other - must 
have Multi-currency store with Barclays
order_number      => 'ORDERID',
         customer_ip       => 'REMOTE_ADDR',
         address           => 'OWNERADDRESS',
         city              => 'OWNERTOWN',
         zip               => 'OWNERZIP',
         country           => 'OWNERCTY', # As ISO country code GB, US, etc
         ship_last_name    => 'ECOM_SHIPTO_POSTAL_NAME_LAST', # SHIPTO 
fields not yet tested
         ship_first_name   => 'ECOM_SHIPTO_POSTAL_NAME_FIRST',
         ship_company      => 'ECOM_SHIPTO_COMPANY',
         ship_address      => 'ECOM_SHIPTO_POSTAL_STREET_LINE1',
         ship_city         => 'ECOM_SHIPTO_POSTAL_CITY',
         ship_zip          => 'ECOM_SHIPTO_POSTAL_POSTCODE',
         ship_country      => 'ECOM_SHIPTO_POSTAL_COUNTRYCODE', # ISO 
country code GB, US, etc
         phone             => 'OWNERTELNO',
         email_customer    => 'EMAIL',
         card_number       => 'CARDNO',
         expiration        => 'ED',
         cvv2              => 'CVC',
     );

     my < at >required_fields = ( qw(pspid login password shasign action 
amount currency card_number expiration) );

     $self->required_fields(< at >required_fields);

     my %post_data = $self->get_fields(qw/
       PSPID USERID PSWD
       OPERATION COM CN AMOUNT CURRENCY ORDERID CARDNO ED CVC
       REMOTE_ADDR
       OWNERADDRESS OWNERTOWN OWNERZIP OWNERCTY OWNERTELNO EMAIL
       ECOM_SHIPTO_POSTAL_NAME_LAST ECOM_SHIPTO_POSTAL_NAME_FIRST 
ECOM_SHIPTO_COMPANYi
       ECOM_SHIPTO_POSTAL_STREET_LINE1 ECOM_SHIPTO_POSTAL_CITY 
ECOM_SHIPTO_POSTAL_POSTCODE ECOM_SHIPTO_POSTAL_COUNTRYCODE
         /);

      # Compute a suitable SHA1 sum for the transaction.

      my $SHATEXT;
      my %content = $self->content();
      foreach my $key (sort keys %post_data) {

     $SHATEXT.=$key."=".$post_data{$key}.$content{'SHASIGN'};
      }


      my $SHAHASH= sha1_base64($SHATEXT);

      print "SHA TEXT IS $SHATEXT\n" if $DEBUG;
      print "Hash is $SHAHASH\n" if $DEBUG;

      $post_data{'SHASIGN'}=$SHAHASH;


     my $opt = {};

     my($page, $server_response, %headers) =
       $self->https_post( $opt, \%post_data );

     $self->server_response($page);
     $self->response_headers(%headers);

#??? IF SUCCEEDED

     my $result = XMLin($page);

#print Dumper($result);

#print "Result is: ",$result->{STATUS},"\n";
#print "Error is: ",$result->{NCERROR},"\n";
#print "Error message is: ",$result->{NCERRORPLUS},"\n";

     my $status=$result->{STATUS};
     my $ncerror=$result->{NCERROR};

     if ( $status eq 9 and $ncerror eq 0 ){

       $self->is_success(1);
       $self->result_code($result->{ACCEPTANCE});
       $self->authorization($result->{PAYID});

     } else {

       $self->is_success(0);
       $self->result_code($result->{ACCEPTANCE});
       $self->error_message("Failed: Status: $status, Error: $ncerror, 
Message:".$result->{NCERRORPLUS});
     }

}

1;
__END__

=head1 NAME

Business::OnlinePayment::EPDQPLUS - Barclaycard EPDQplus API Direct Link

Dev version - not released

=head1 DESCRIPTION

This module provides access to the Barclaycard EPDQplus Direct Link API 
and documented in v4.3.3 of the
Barclay Integration guide.

It is currently a work in progress.

To use/test this module you will need:
  PSPID - Barclaycard supplied credential
  "admin" user for the api with password (login and password) in the 
Barclaycard backend as per the online help.
  SHA signing secret defined for API access (strictly this is optional 
the Barclaycard interface by the module assumed you will use it)

Currently implemented - "Normal Authorization" (Operation "SAL").

=head USAGE

use Business::OnlinePayment;

   my $tx = Business::OnlinePayment->new("EPDQPLUS");

   $tx->content(
       pspid          => 'see above',
       login          => 'added via Barclaycard Backoffice',
       password       => 'set via Barclaycard Backoffice'
       shasign     => 'set via Barclaycard Backoffice',

       action         => 'Normal Authorization',
       description    => '20 English Roses',
       amount         => '49.95',
       currency       => 'USD',
       order_number   => 'ORDER0001',

       name           => 'B Obama',
       address        => 'Whitehouse, 1600 Pennsylvannia Road',

       city           => 'Washington DC',
       zip            => 'DC 20500',
       country        => 'US',
       phone          => '',

       card_number    => '5569510117486571',
       expiration     => '0515', # MMYY is a Barclay card format -- what 
does BOP expect
       cvv2            => '377',
   );

   $tx->submit();

   print "server_response = ", $tx->server_response, "\n";
   print "is_success      = ", $tx->is_success,      "\n";
   print "authorization   = ", $tx->authorization,   "\n";
   print "error_message   = ", $tx->error_message,   "\n\n";
   print "result_code     = ", $tx->result_code,     "\n";

=head1 AUTHOR

Simon Waters <simonw-7nTjbf+i2KBeoWH0uzbU5w< at >public.gmane.org>

Derived from code by Jason Kohles and Ivan Kohler and Dan Helfman

=head1 SEE ALSO

perl(1). L<Business::OnlinePayment>

=cut

Proposed - Barclaycard EPDQextra Plus API Direct LinkIntegration

Simon Waters — 2013-01-22T16:26:14

Okay, I am in similar situation to Ted Byers.

In that I have a working prototype for submitting a hash, and get a 
status code and error messages back (if appropriate).

I've emailed Ted directly to check it isn't the same processor.

At this point my employers only need to implement the purchase operation 
(SAL), but we will need additional features shortly (notably 3DSecure).

In prototype I've used:

use URI::Escape qw/uri_escape/;
use Digest::SHA qw/sha1_base64/;
use LWP::UserAgent;
use XML::Simple;

I now need to remap a whole load of names from existing hash sent to 
Business::OnlinePayments to whatever module I write, so it seems to me I 
may as well write it as a BOP module since you guys have some bits to 
make that easier.

The system POSTs URLs with parameters to SSL protected locations, 
retrieves a short XML response, which includes status code and error 
messages and some other bits.

Seems straightforward.

I could do with some pointers (mentor?).

Do any of the existing modules do anything along these lines already?

I see TCLink shows me remapping fields nicely.

All the modules seem to split protocol, server, path for the connection. 
Is that an SSLeay thing, as the LWP::UserAgent approach can be just 
strings. Do BOP authors care? I know LWP::UserAgent didn't verify 
certificates correctly previously, I believe this is fixed now (on the 
upside Barclay card offer a message hash so intercepted messages can't 
be modified without the hash key as well as the contents of the message).

Should I be using Business::OnlinePayments::HTTPS

I'm not 100% clear only having used AuthorizeNet and WorldPay modules 
precisely what the "standard" HASH input we should be aiming at is for BOP.

I appreciate we can't guarantee to preserve every details since 
different processors require different information, but those two 
modules has some minor differences which seemed unnecessary to me. For 
example "expiry date" should it be "YYMM" or doesn't it matter as long 
as I give good error messages? I presume the goal is to make it an 
interchangeable as possible or what's the point...

If I produce something that is useful to other folks can I get it 
uploaded by someone, or do I go down becoming a CPAN author (I know 
Barbie - so I'm sure he'll provide even more frank advice than usual if 
I go that route...).

Anyone prepared to critique my Perl? It might need quite a lot of 
critiquing, but at least I know that so the ego is mostly dead.

Testing: Barclays provide separate URLs, and separate account, but it is 
all tied to our company, so I can't provide any public test credentials 
for the system.

Re: plugin for iTransact?

Stefan Hornburg (Racke — 2013-01-22T09:25:39

Yes, it makes sense to wrap this module into a BOP module.

Regards
Racke

Re: plugin for iTransact?

Joel Roth — 2013-01-22T09:18:24


Hi Racke,

Thanks for the suggestion.  Looks like it might be useful.
Perhaps I can learn enough to make it into a plugin.  I
think I would rather code once to BOP, with the possibility
to change gateways in future. 

Cheers,

Joel

Re: plugin for iTransact?

Stefan Hornburg (Racke — 2013-01-22T08:33:40

Did you try the following one?

https://metacpan.org/module/iTransact::Lite

Never used that, but this comes up on the search.

Regards
Racke

plugin for iTransact?

Joel Roth — 2013-01-21T22:41:55

Hi Ivan and list dwellers,

I'm new to payment processing and BOP,
found an inexpensive gateway service, NiftyPay.[1]

Their developer guide[2] is from iTransact, 
mentions authenticating for multiple gateways.

Is there an easy way to inspect if it is an exact
or close match for an existing plugin?

Greetings,

Joel


1. http://niftypay.com

2. http://www.itransact.com/support/downloads/PCDeveloperGuide.pdf

Re: Business::OnlinePayment

Ivan Kohler — 2013-01-03T17:16:14

Yes.



More frequent updates are not needed.



No.

Some processors support global test accounts, if so, the credentials are 
typically available in the source distribution and used in the test 
suite.

Most processors require you to use a real account in test mode, or a 
private test account.



Not yet well supported by B:OP.  Assistance is welcome.



Not specifically.  Pick ones that are relatively simple (i.e. 
AuthorizeNet is way to complex at this point), have had a release in the 
last couple years and that implement an interface similar to your 
gateway (i.e. XML, regular POST parameters, etc.).

Also you want to refer to notes_for_module_authors and 
notes_for_module_authors_v3



I know several of the processors require SOAP interfaces.  I don't 
recall specifically which ones.



We use B:OP with mod_perl all the time.



It typically works fine.  None of our B:OP code uses global variables, 
so the "bleeding" you refer to from sloppy-written scripts is not 
relevant to us personally.



No.



For further discussion of Business::OnlinePayment, please subscribe to 
the bop-devel-iVwBjzKCYA0< at >public.gmane.org and post your message there, rather than email me 
personally.

Re: Need help implementing Authorize.net's DirectPostMethod

danny hembree — 2011-12-14T00:30:18

Business::PayPal::API at CPAN implements the PayPal API and may have
enough functionality to help you out. It's SOAP based and handles
straight up credit card processing as well as the PayPal interface.


On Tue, 2011-12-13 at 18:11 -0600, Bob McClure Jr wrote:

Need help implementing Authorize.net's Direct PostMethod

Bob McClure Jr — 2011-12-14T00:11:00

My client has been using Business::OnlinePayment::AuthorizeNet for
some time to handle Auth.net's AIM process.  Now they want to change
to their Direct Post Method to get out from under some PCI
requirements.

In this process, the form, including a callback URL on your server, is
sent directly to Auth.net.  They process the CC info and return a
response to your server.  Your server then, depending on approval,
returns a redirect URL, e.g. to the thank you page on your server, to
Auth.net, which they send to the user.

Auth.net has no Perl support, AFAIK.  Has anyone invented this wheel
or can give me some tips for using/hacking an existing module to
handle this?

For another client, I've built a plain Perl handler for PayPal's
Instant Payment Notification, but it's an asynchronous process, while
Auth.net is synchronous.  That is to say, the transaction is "thrown
over the wall" and the response is handled independent of the user's
activity.

Hints and clues are welcome.

Cheers,

Re: Authorize.net Direct Post Method

Ivan Kohler — 2011-12-13T23:11:03


I'm not aware of anyone currently working on this with Authorize.net.

Third-party "browser redirect" systems like direct post are outside the 
scope of the framework that Business::OnlinePayment provides, so I don't 
think "hacking ::AIM into ::DPM" is any sort of reasonable way forward.

We've been working on a prototype framework for third-party services 
like PayPal and Google Checkout, called 
Business::OnlineThirdPartyPayment.  Personally I think we should rename 
before uploading to CPAN.  :)

The base module, a dummy processor module and two real processor modules 
are available from http://freeside.biz/cgi-bin/viewvc.cgi/


Subscribe to bop-devel and ask if anyone's interested in working with 
you on Business::OnlineThirdPartyPayment::AuthorizeNet ?  And be 
prepared to take it on yourself if not.
:)

Re: (no subject)

Ivan Kohler — 2011-09-27T02:57:08

There was some discussion about a year ago 
(http://420.am/pipermail/bop-devel/2010-October/thread.html and 
http://420.am/pipermail/bop-devel/2010-November/thread.html) but I don't think 
anything concrete ever came of it.


The goal as far as B:OP is concerned would be to expose the functionality in a 
fashion that is as identical across different processors as possible.

In the case where that's impossible and usage must be different (like your 
example above where some processors auto-settle the transactions and others 
don't), we should provide intorspection data (like CC_void_requires_card / 
ECHECK_void_requires_account) to inform the application using B:OP that it 
needs to behave differently.

Re: (no subject)

Jason Hall — 2011-09-26T01:14:00

I created a basic way to handle partial auths in the Litle interface,
however it looks like they are handled slightly differently than in
Auth.net.

https://github.com/Jayceh/Business--OnlinePayment--Litle


On Sat, Sep 24, 2011 at 10:26 AM, Kristen Eisenberg
<kristen.eisenberg< at >yahoo.com> wrote:

(no subject)

Kristen Eisenberg — 2011-09-24T16:26:34

[bop-devel] MasterCard/Discover Partial Authorization


Has any one given any thought to implementing the new Partial
Authorization/Balance Response requirements. We currently use an
in-house solution for communicating with AuthorizeNet, but are looking
at adopting BOP if it will support partial authorizations.

I am willing to work on adding support to BOP and the AuthorizeNet
back-end, but I wanted to see if anyone else is working on it already.
If not I want to start the discussion on the best way to do this.

I'm not sure how other processors will handle this, but from what I have
read so far, AuthorizeNet and PayPal will handle this completely
differently.

It appears that for PayPal there is no further actions required for a
partial auth. However the AuthorizeNet AIM docs state that "All
transactions are put in a hold state until the final transaction is
received. This is the transaction with a splitTenderId where the
remaining amount is approved."

Kristen Eisenberg
Billige Flüge
Marketing GmbH
Emanuelstr. 3,
10317 Berlin
Deutschland
Telefon: +49 (33)
5310967
Email:
utebachmeier at
gmail.com
Site:
http://flug.airego.de-
Billige Flüge vergleichen_______________________________________________
bop-devel mailing list
bop-devel-iVwBjzKCYA0< at >public.gmane.org
http://420.am/cgi-bin/mailman/listinfo/bop-devel

FW: Future Interchange plans + Business::OnlinePaymentfrom Sabrina

Freeh Sophia — 2011-08-25T09:51:13

Hi, everyone.

Some of you may be familiar with Interchange, most likely the
longest-standing open source Perl ecommerce application. It's mentioned a
few times in the BOP development status notes:

http://420.am/business-onlinepayment/ng.html

The Interchange development group is starting work on a major overhaul. Up
to the current version 5, Interchange has been a fairly monolithic
application that includes all its own payment modules, templating,
database interaction, URL routing, etc.

Since it was created in 1995, a lot has changed in the Perl space :) and
we're finding it would be better for us to build on others' work in the
Perl community. We plan to build Interchange 6 on top of Plack, Dancer,
and templating, payment modules, etc. from CPAN, with Interchange focusing
on unmet ecommerce needs.

Interchange has long had a module to interface with BOP, though it's been
only spottily used due to most users already having set up shop with the
native Interchange payment modules.

Now we're looking at starting to use BOP directly, and I wanted to ask if
anyone can tell us whether the notes about wanting to borrow code from
Interchange in the BOP development notes are still current, or if BOP has
got everything you'd expect would be useful from Interchange's
Vend::Payment::* modules.

Anyway, if plans for Interchange 6 work out you may see more Interchange
people showing up here as users and hopefully contributors. :)

Finally, what's the procedure for contributing patches to BOP modules?
Does anyone perhaps have Git mirrors of the CVS repositories set up?

Thanks,
Jon