perl-business-paypal-api/lib/Business/PayPal/API/GetTransactionDetails.pm

351 lines
11 KiB
Perl
Raw Permalink Normal View History

2009-12-02 16:44:18 +00:00
package Business::PayPal::API::GetTransactionDetails;
use 5.008001;
use strict;
use warnings;
use SOAP::Lite 0.67;
use Business::PayPal::API ();
2014-03-23 02:31:50 +00:00
our @ISA = qw(Business::PayPal::API);
our @EXPORT_OK = qw(GetTransactionDetails); ## fake exporter
2009-12-02 16:44:18 +00:00
sub GetTransactionDetails {
my $self = shift;
my %args = @_;
2014-03-23 02:31:50 +00:00
my @trans = (
$self->version_req,
SOAP::Data->name( TransactionID => $args{TransactionID} )
->type( 'xs:string' ),
);
2009-12-02 16:44:18 +00:00
2014-03-23 02:31:50 +00:00
my $request
= SOAP::Data->name(
GetTransactionDetailsRequest => \SOAP::Data->value( @trans ) )
->type( "ns:GetTransactionDetailsRequestType" );
2009-12-02 16:44:18 +00:00
my $som = $self->doCall( GetTransactionDetailsReq => $request )
2014-03-23 02:31:50 +00:00
or return;
2009-12-02 16:44:18 +00:00
my $path = '/Envelope/Body/GetTransactionDetailsResponse';
my %response = ();
2014-03-23 02:31:50 +00:00
unless ( $self->getBasic( $som, $path, \%response ) ) {
$self->getErrors( $som, $path, \%response );
2009-12-02 16:44:18 +00:00
return %response;
}
$path .= '/PaymentTransactionDetails';
2014-03-23 02:31:50 +00:00
$self->getFields(
$som, $path,
\%response,
{ Business => '/ReceiverInfo/Business',
Receiver => '/ReceiverInfo/Receiver',
ReceiverID => '/ReceiverInfo/ReceiverID',
Payer => '/PayerInfo/Payer',
PayerID => '/PayerInfo/PayerID',
PayerStatus => '/PayerInfo/PayerStatus',
Salutation => '/PayerInfo/PayerName/Salutation',
FirstName => '/PayerInfo/PayerName/FirstName',
MiddleName => '/PayerInfo/PayerName/MiddleName',
LastName => '/PayerInfo/PayerName/LastName',
PayerCountry => '/PayerInfo/PayerCountry',
PayerBusiness => '/PayerInfo/PayerBusiness',
AddressOwner => '/PayerInfo/Address/AddressOwner',
AddressStatus => '/PayerInfo/Address/AddressStatus',
ADD_Name => '/PayerInfo/Address/Name',
Street1 => '/PayerInfo/Address/Street1',
Street2 => '/PayerInfo/Address/Street2',
CityName => '/PayerInfo/Address/CityName',
StateOrProvince => '/PayerInfo/Address/StateOrProvince',
Country => '/PayerInfo/Address/Country',
CountryName => '/PayerInfo/Address/CountryName',
Phone => '/PayerInfo/Address/Phone',
PostalCode => '/PayerInfo/Address/PostalCode',
TransactionID => '/PaymentInfo/TransactionID',
ParentTransactionID => '/PaymentInfo/ParentTransactionID',
ReceiptID => '/PaymentInfo/ReceiptID',
TransactionType => '/PaymentInfo/TransactionType',
PaymentType => '/PaymentInfo/PaymentType',
PaymentDate => '/PaymentInfo/PaymentDate',
GrossAmount => '/PaymentInfo/GrossAmount',
FeeAmount => '/PaymentInfo/FeeAmount',
SettleAmount => '/PaymentInfo/SettleAmount',
TaxAmount => '/PaymentInfo/TaxAmount',
ExchangeRate => '/PaymentInfo/ExchangeRate',
PaymentStatus => '/PaymentInfo/PaymentStatus',
PendingReason => '/PaymentInfo/PendingReason',
ReasonCode => '/PaymentInfo/ReasonCode',
ProtectionEligibility => '/PaymentInfo/ProtectionEligibility',
InvoiceID => '/PaymentItemInfo/InvoiceID',
Custom => '/PaymentItemInfo/Custom',
Memo => '/PaymentItemInfo/Memo',
SalesTax => '/PaymentItemInfo/SalesTax',
PII_SalesTax => '/PaymentItemInfo/PaymentItem/SalesTax',
PII_Name => '/PaymentItemInfo/PaymentItem/Name',
PII_Number => '/PaymentItemInfo/PaymentItem/Number',
PII_Quantity => '/PaymentItemInfo/PaymentItem/Quantity',
PII_Amount => '/PaymentItemInfo/PaymentItem/Amount',
PII_Options => '/PaymentItemInfo/PaymentItem/Options',
PII_SubscriptionID =>
'/PaymentItemInfo/Subscription/SubscriptionID',
PII_SubscriptionDate =>
'/PaymentItemInfo/Subscription/SubscriptionDate',
PII_EffectiveDate =>
'/PaymentItemInfo/Subscription/EffectiveDate',
PII_RetryTime => '/PaymentItemInfo/Subscription/RetryTime',
PII_Username => '/PaymentItemInfo/Subscription/Username',
PII_Password => '/PaymentItemInfo/Subscription/Password',
PII_Recurrences => '/PaymentItemInfo/Subscription/Recurrences',
PII_reattempt => '/PaymentItemInfo/Subscription/reattempt',
PII_recurring => '/PaymentItemInfo/Subscription/recurring',
PII_Amount => '/PaymentItemInfo/Subscription/Amount',
PII_period => '/PaymentItemInfo/Subscription/period',
PII_BuyerID => '/PaymentItemInfo/Auction/BuyerID',
PII_ClosingDate => '/PaymentItemInfo/Auction/ClosingDate',
PII_multiItem => '/PaymentItemInfo/Auction/multiItem',
}
);
2009-12-02 16:44:18 +00:00
## multiple payment items
2014-03-23 02:31:50 +00:00
my $paymentitems = $self->getFieldsList(
$som,
$path . '/PaymentItemInfo/PaymentItem',
{ SalesTax => 'SalesTax',
Name => 'Name',
Number => 'Number',
Quantity => 'Quantity',
Amount => 'Amount',
}
);
if ( scalar( @$paymentitems ) > 0 ) {
Properly extract Options from PaymentItemInfo The Options fields found in /PaymentTransactionDetails/PaymentItemInfo/PaymentItem/Options have never been extracted in the proper way. In fact, I'd be surprised if anyone found the previous method of extraction useful at all. I discovered this bug when I needed to lookup the Options selected during payment, and found they weren't returned by the API. Specifically, the value inside the SOAP tags, which is what the API previously returned, are simply not useful: they are typically empty. The interesting data is stored in the attributes of 'name' and 'value'. Note, BTW, that each PaymentItem can have its own set of Options. This code added herein properly extracts the Options data for each PaymentItem, and places it both in the Options field for that PaymentItem, and in the array in the PII_Options "convenience" field. As can be seen in the accompanying changes to t/OptionsFields.t, the return values of the Options data is now a hash rather than a list. I believe this API-user-visible change is appropriate since a hash is ultimately the natural representation of this data, and since having the Options as an array of empty strings wasn't useful, anyway. Nevertheless, if existing user code of this API relies on Options being an array of empty strings (which I suppose could have been usefully used in scalar context to get the count of options in the record), this change theoretically creates a user-visible change in the API. I can't imagine anyone found the previous return value useful in the past anyway, so I'd be surprised if anyone relies on this mis-feature. If they did, they can simply change their code to: scalar keys ...{Options} instead of: scalar @...{Options} However, since this is technically an API change, I've updated the Changes file and the module documentation to mention it.
2015-01-02 18:09:50 +00:00
# Options data must be extracted differently. Specifically, the
# "interesting" parts of the Options data is not in the values inside
# the $som structure (which means $som->valueof(), which
# $self->getFieldsList() above calls underneath, won't extract the
# useful data, because the values are empty.
# The convoluted loop below finds any Options values and matches them
# up properly with the correct PaymentItem. Note that the loop is
# written this way to account for the fact that there may be multiple
# PaymentItems.
# Finally, I contemplated placing this loop below in getFieldsList()
# with a special-case for Options, but I am not sure it belongs
# there. Ultimately, I think this is unique to the
# GetTransactionsDetails call in the API, and thus it's more
# appropriately placed here.
my $ii = 0;
my @fulloptions;
foreach my $rec ( $som->dataof($path . '/PaymentItemInfo/PaymentItem' ) ) {
my %options;
foreach my $subrec ($rec->value()) {
foreach my $fieldrec ($$subrec->value()) {
$options{$fieldrec->attr()->{name}} = $fieldrec->attr()->{value}
if ($fieldrec->name() eq "Options");
}
}
$paymentitems->[$ii]{Options} = \%options;
push(@fulloptions, \%options);
}
# Now, we can save the payment items properly
2009-12-02 16:44:18 +00:00
$response{PaymentItems} = $paymentitems;
Properly extract Options from PaymentItemInfo The Options fields found in /PaymentTransactionDetails/PaymentItemInfo/PaymentItem/Options have never been extracted in the proper way. In fact, I'd be surprised if anyone found the previous method of extraction useful at all. I discovered this bug when I needed to lookup the Options selected during payment, and found they weren't returned by the API. Specifically, the value inside the SOAP tags, which is what the API previously returned, are simply not useful: they are typically empty. The interesting data is stored in the attributes of 'name' and 'value'. Note, BTW, that each PaymentItem can have its own set of Options. This code added herein properly extracts the Options data for each PaymentItem, and places it both in the Options field for that PaymentItem, and in the array in the PII_Options "convenience" field. As can be seen in the accompanying changes to t/OptionsFields.t, the return values of the Options data is now a hash rather than a list. I believe this API-user-visible change is appropriate since a hash is ultimately the natural representation of this data, and since having the Options as an array of empty strings wasn't useful, anyway. Nevertheless, if existing user code of this API relies on Options being an array of empty strings (which I suppose could have been usefully used in scalar context to get the count of options in the record), this change theoretically creates a user-visible change in the API. I can't imagine anyone found the previous return value useful in the past anyway, so I'd be surprised if anyone relies on this mis-feature. If they did, they can simply change their code to: scalar keys ...{Options} instead of: scalar @...{Options} However, since this is technically an API change, I've updated the Changes file and the module documentation to mention it.
2015-01-02 18:09:50 +00:00
# And set the PII_Options properly too.
$response{PII_Options} = \@fulloptions;
2009-12-02 16:44:18 +00:00
}
return %response;
}
1;
__END__
=head1 NAME
Business::PayPal::API::GetTransactionDetails - PayPal GetTransactionDetails API
=head1 SYNOPSIS
use Business::PayPal::API::GetTransactionDetails;
my $pp = new Business::PayPal::API::GetTransactionDetails ( ... );
or
## see Business::PayPal::API documentation for parameters
use Business::PayPal::API qw(GetTransactionDetails);
my $pp = new Business::PayPal::API( ... );
my %response = $pp->GetTransactionDetails( TransactionID => $transid, );
=head1 DESCRIPTION
B<Business::PayPal::API::GetTransactionDetails> implements PayPal's
B<GetTransactionDetails> API using SOAP::Lite to make direct API calls to
PayPal's SOAP API server. It also implements support for testing via
PayPal's I<sandbox>. Please see L<Business::PayPal::API> for details
on using the PayPal sandbox.
=head2 GetTransactionDetails
Implements PayPal's B<GetTransactionDetails> API call. Supported
parameters include:
TransactionID
as described in the PayPal "Web Services API Reference" document.
Returns a hash containing the transaction details, including these fields:
Business
Receiver
ReceiverID
Payer
PayerID
PayerStatus
Salutation
FirstName
MiddleName
LastName
PayerCountry
PayerBusiness
AddressOwner
AddressStatus
ADD_Name
Street1
Street2
CityName
StateOrProvince
Country
CountryName
Phone
PostalCode
TransactionID
ParentTransactionID
ReceiptID
TransactionType
PaymentType
PaymentDate
GrossAmount
FeeAmount
SettleAmount
TaxAmount
ExchangeRate
PaymentStatus
PendingReason
ReasonCode
InvoiceID
Custom
Memo
SalesTax
PII_SaleTax
PII_Name
PII_Number
PII_Quantity
PII_Amount
PII_Options
PII_SubscriptionID
PII_SubscriptionDate
PII_EffectiveDate
PII_RetryTime
PII_Username
PII_Password
PII_Recurrences
PII_reattempt
PII_recurring
PII_Amount
PII_period
PII_BuyerID
PII_ClosingDate
PII_multiItem
As described in the API document. Note: some fields have prefixes to
remove ambiguity for like-named fields (e.g., "PII_").
If there are multiple PaymentItems, then an additional field
'PaymentItems' will be available with an arrayref of PaymentItem
records:
PaymentItems => [ { SalesTax => ...,
Name => '...',
Number => '...',
Quantity => '...',
Amount => '...',
Properly extract Options from PaymentItemInfo The Options fields found in /PaymentTransactionDetails/PaymentItemInfo/PaymentItem/Options have never been extracted in the proper way. In fact, I'd be surprised if anyone found the previous method of extraction useful at all. I discovered this bug when I needed to lookup the Options selected during payment, and found they weren't returned by the API. Specifically, the value inside the SOAP tags, which is what the API previously returned, are simply not useful: they are typically empty. The interesting data is stored in the attributes of 'name' and 'value'. Note, BTW, that each PaymentItem can have its own set of Options. This code added herein properly extracts the Options data for each PaymentItem, and places it both in the Options field for that PaymentItem, and in the array in the PII_Options "convenience" field. As can be seen in the accompanying changes to t/OptionsFields.t, the return values of the Options data is now a hash rather than a list. I believe this API-user-visible change is appropriate since a hash is ultimately the natural representation of this data, and since having the Options as an array of empty strings wasn't useful, anyway. Nevertheless, if existing user code of this API relies on Options being an array of empty strings (which I suppose could have been usefully used in scalar context to get the count of options in the record), this change theoretically creates a user-visible change in the API. I can't imagine anyone found the previous return value useful in the past anyway, so I'd be surprised if anyone relies on this mis-feature. If they did, they can simply change their code to: scalar keys ...{Options} instead of: scalar @...{Options} However, since this is technically an API change, I've updated the Changes file and the module documentation to mention it.
2015-01-02 18:09:50 +00:00
Options => { 'key' => 'value', ... },
2009-12-02 16:44:18 +00:00
},
{ SalesTax => ..., etc.
} ]
Example:
my %resp = $pp->GetTransactionDetails( TransactionID => $trans_id );
print "Payer: $resp{Payer}\n";
for my $item ( @{ $resp{PaymentItems} } ) {
print "Name: " . $item->{Name} . "\n";
print "Amt: " . $item->{Amount} . "\n";
Properly extract Options from PaymentItemInfo The Options fields found in /PaymentTransactionDetails/PaymentItemInfo/PaymentItem/Options have never been extracted in the proper way. In fact, I'd be surprised if anyone found the previous method of extraction useful at all. I discovered this bug when I needed to lookup the Options selected during payment, and found they weren't returned by the API. Specifically, the value inside the SOAP tags, which is what the API previously returned, are simply not useful: they are typically empty. The interesting data is stored in the attributes of 'name' and 'value'. Note, BTW, that each PaymentItem can have its own set of Options. This code added herein properly extracts the Options data for each PaymentItem, and places it both in the Options field for that PaymentItem, and in the array in the PII_Options "convenience" field. As can be seen in the accompanying changes to t/OptionsFields.t, the return values of the Options data is now a hash rather than a list. I believe this API-user-visible change is appropriate since a hash is ultimately the natural representation of this data, and since having the Options as an array of empty strings wasn't useful, anyway. Nevertheless, if existing user code of this API relies on Options being an array of empty strings (which I suppose could have been usefully used in scalar context to get the count of options in the record), this change theoretically creates a user-visible change in the API. I can't imagine anyone found the previous return value useful in the past anyway, so I'd be surprised if anyone relies on this mis-feature. If they did, they can simply change their code to: scalar keys ...{Options} instead of: scalar @...{Options} However, since this is technically an API change, I've updated the Changes file and the module documentation to mention it.
2015-01-02 18:09:50 +00:00
for my $optionname (keys %$item->{Options}) {
print "Option: $optionname is " . $item->{Options}{$optionname} . "\n";
}
2009-12-02 16:44:18 +00:00
}
=head2 ERROR HANDLING
See the B<ERROR HANDLING> section of B<Business::PayPal::API> for
information on handling errors.
=head2 EXPORT
None by default.
=head1 SEE ALSO
L<https://developer.paypal.com/en_US/pdf/PP_APIReference.pdf>
=head1 AUTHOR
Scot Wiersdorf E<lt>scott@perlcode.orgE<gt>
Bradley M. Kuhn E<lt>bkuhn@ebb.orgE<gt>
2009-12-02 16:44:18 +00:00
=head1 COPYRIGHT AND LICENSE
Copyright (C) 2006 by Scott Wiersdorf
Copyright (C) 2014, 2015 by Bradley M. Kuhn
2009-12-02 16:44:18 +00:00
This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself, either Perl version 5.8.5 or,
at your option, any later version of Perl 5 you may have available.
=cut
# Local Variables:
# Mode: CPerl
# indent-tabs-mode: nil
# cperl-indent-level: 4
# cperl-brace-offset: 0
# cperl-continued-brace-offset: 0
# cperl-label-offset: -4
# cperl-continued-statement-offset: 4
# End: