Skip Menu |

This queue is for tickets about the Business-OnlinePayment-PayflowPro CPAN distribution.

Report information
The Basics
Id: 125658
Status: open
Priority: 0/
Queue: Business-OnlinePayment-PayflowPro

People
Owner: Nobody in particular
Requestors: PHILLUP [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: (no value)
Fixed in: (no value)



Subject: Missing Fields
There are many fields that may be required that are not accounted for during the call to _revmap_fields. For example, see the 'Processors Requiring Additional Transaction Parameters' section at https://developer.paypal.com/docs/classic/payflow/integration-guide/ Closer to heart, I am trying to implement multiple currency support which requires adding the CURRENCY field to the api request. (I also used ECHODATA to get feedback on paypal's interpretation of the submitted data) Please consider the following patch which should allow for a flexible mapping depending on the processor's requirements. Thanks, --Phillip
Subject: patch.diff
diff --git a/lib/Business/OnlinePayment/PayflowPro.pm b/lib/Business/OnlinePayment/PayflowPro.pm index d95affc..5b25163 100644 --- a/lib/Business/OnlinePayment/PayflowPro.pm +++ b/lib/Business/OnlinePayment/PayflowPro.pm @@ -155,7 +155,12 @@ sub expdate_mmyy { } sub submit { - my ($self) = @_; + my ($self, $extra_fields) = @_; + + $extra_fields ||= {}; + if (ref $extra_fields ne 'HASH') { + croak("extra_fields must be a hash reference"); + } $self->_map_fields(); @@ -216,6 +221,7 @@ sub submit { SHIPTOSTATE => 'ship_state', SHIPTOZIP => 'ship_zip', SHIPTOCOUNTRY => 'ship_country', + %$extra_fields, ); # Reload %content as _revmap_fields makes our copy old/invalid! @@ -244,7 +250,8 @@ sub submit { SHIPTOFIRSTNAME SHIPTOLASTNAME SHIPTOSTREET SHIPTOCITY SHIPTOSTATE SHIPTOZIP SHIPTOCOUNTRY CUSTCODE - ) + ), + keys %$extra_fields ); # get header data @@ -280,7 +287,7 @@ sub submit { # - Enclose the PARMLIST in quotation marks ("") # - Do not place quotation marks ("") within the body of the PARMLIST # - Separate all PARMLIST name-value pairs using an ampersand (&) - # + # # Because '&' and '=' have special meanings/uses values containing # these special characters must be encoded using a special "length # tag". The "length tag" is simply the length of the "value" @@ -394,14 +401,14 @@ Business::OnlinePayment::PayflowPro - Payflow Pro backend for Business::OnlinePa =head1 SYNOPSIS use Business::OnlinePayment; - + my $tx = new Business::OnlinePayment( 'PayflowPro', 'vendor' => 'your_vendor', 'partner' => 'your_partner', 'client_certification_id' => 'GuidUpTo32Chars', ); - + # See the module documentation for details of content() $tx->content( type => 'VISA', @@ -422,9 +429,9 @@ Business::OnlinePayment::PayflowPro - Payflow Pro backend for Business::OnlinePa order_number => 'string', request_id => 'unique_identifier_for_transaction', ); - + $tx->submit(); - + if ( $tx->is_success() ) { print( "Card processed successfully: ", $tx->authorization, "\n", @@ -436,7 +443,7 @@ Business::OnlinePayment::PayflowPro - Payflow Pro backend for Business::OnlinePa else { my $info = ""; $info = " (CVV2 mismatch)" if ( $tx->result_code == 114 ); - + print( "Card was rejected: ", $tx->error_message, $info, "\n", "order number: ", $tx->order_number, "\n", @@ -651,6 +658,39 @@ The required Payflow Pro parameters for credit card transactions are: TRXTYPE TENDER PARTNER VENDOR USER PWD ORIGID +=head1 Extra Fields + +You can pass extra fields to the 'submit' method using a hash ref in the same format as the mappings in the previous section. + +These extra fields will be mapped to the request using the same rules as the default mapping above. + +For example, to add the currency to the request: + + $tx->content( + type => 'VISA', + action => 'Normal Authorization', + description => 'Business::OnlinePayment::PayflowPro test', + amount => '49.95', + invoice_number => '100100', + customer_id => 'jsk', + name => 'Jason Kohles', + address => '123 Anystreet', + city => 'Anywhere', + state => 'GA', + zip => '30004', + email => 'ivan-payflowpro@420.am', + card_number => '4111111111111111', + expiration => '12/09', + cvv2 => '123', + order_number => 'string', + request_id => 'unique_identifier_for_transaction', + event_currency => 'CAD', + ); + + $tx->submit({CURRENCY => event_currency}); + +This maps the 'event_currency' field value from the content to the 'CURRENCY' field during the api request. + =head1 Mapping Payflow Pro transaction responses to object methods The following methods provides access to the transaction response data
On Fri Jun 22 17:56:18 2018, PHILLUP wrote: Show quoted text
> There are many fields that may be required that are not accounted for > during the call to _revmap_fields. > > For example, see the 'Processors Requiring Additional Transaction > Parameters' section at > https://developer.paypal.com/docs/classic/payflow/integration-guide/ > > Closer to heart, I am trying to implement multiple currency support > which requires adding the CURRENCY field to the api request. (I also > used ECHODATA to get feedback on paypal's interpretation of the > submitted data) > > Please consider the following patch which should allow for a flexible > mapping depending on the processor's requirements.
Sorry, no. This would be a reasonable "future proofing" patch if we were Business::PayflowPro, just implementing an interface to Payflow Pro, but that is not the case. This is a Business::OnlinePayment module. The point is to provide a common interface to different processors without requiring code changes per processor. So: If you want to support new fields like currency, they should be mapped from the B:OP standard fields, or defined and added to the B:OP docs/specification if necessary. There's already a B:OP currency field. If there are "additional transaction parameters" required that are atypical and beyond that required for other gateways then we should define and add additional introspection information, in the same way as CC_void_requires_card and ECHECK_void_requires_account are set for some processors and indicate the additional parameters necessary for those kinds of transactions. (Check out the B:OP documentation, specifically the B:OP manpage and notes_for_module_writers_v3) Thanks a bunch for your efforts and hope to see a refactored patch taking the above into consideration! Ivan
On Fri Jun 22 18:29:48 2018, IVAN wrote: Thanks for the feedback, it all makes perfect sense... except: Show quoted text
> So: If you want to support new fields like currency, they should be > mapped from the B:OP standard fields, or defined and added to the B:OP > docs/specification if necessary. There's already a B:OP currency > field.
I see where these fields are mentioned in the POD, but can not see where they are actually defined in the code. So, I am not quite sure how to go about doing the mapping there. Also, I can not get the payflow module to send currency as a value even tho it is described in the base class. And, looking at the code for the payflow modue does not provide any hint where the optional fields in the description of the base module would be included in the request sent to paypal. (I am using the debug option to see what is sent) Any help here would be greatly appreciated. Thanks, --Phillip
On Mon Jun 25 13:17:02 2018, PHILLUP wrote: Show quoted text
> On Fri Jun 22 18:29:48 2018, IVAN wrote: > > Thanks for the feedback, it all makes perfect sense... except: >
> > So: If you want to support new fields like currency, they should be > > mapped from the B:OP standard fields, or defined and added to the > > B:OP > > docs/specification if necessary. There's already a B:OP currency > > field.
> > I see where these fields are mentioned in the POD, but can not see > where they > are actually defined in the code. So, I am not quite sure how to go > about doing > the mapping there. > > Also, I can not get the payflow module to send currency as a value > even tho > it is described in the base class. > > And, looking at the code for the payflow modue does not provide any > hint where > the optional fields in the description of the base module would be > included in the > request sent to paypal. (I am using the debug option to see what is > sent) > > Any help here would be greatly appreciated.
I haven't looked at the code for this module in a decade and have no idea how to help you with these questions. Sorry.