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>
|
2015-01-02 18:16:01 +00:00
|
|
|
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
|
2015-01-02 18:16:01 +00:00
|
|
|
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
|
2015-01-02 17:28:21 +00:00
|
|
|
|
|
|
|
# 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:
|