Express Checkout for Paypal, why three methods to complete a payment? - php

I dont get it.
As of my knowledge currently, there is three must-have methods in order to complete a complete transaction.
SetExpressCheckout
Makes sense, I create a payment with the items in it and all, then redirect the user to the redirecturi i receive in the response.
GetExpressCheckoutDetails
This method should be on the url that is specified on the returnurl from the SetExpressCheckout. By getting the TOKEN that comes from paypal and use it for calling this method, we can get Payer ID, that we will use to call the final method DoExpressCheckoutPayment
DoExpressCheckoutPayment
This method requires a TOKEN and PAYER ID that we now both have. It also requires the Payment and the payment items, to really complete the transaction.
Now my questions are:
On my returnurl, I am calling both GetExpressCheckoutDetails and then DoExpressCheckoutPayment. Now - can I always go out from that everything is correct and the transaction WILL go through when calling these two? I am thinking, maybe Paypal doesnt continue to the returnurl if the user has insufficient funds ?
Why do we need to specify the payment items all again in DoExpressCheckoutPayment ? When we already did it in SetExpressCheckout?
I am so used to other payment gateways that simply have an initiation of the payment -> redirect to payment gateway -> complete. Where they then make an callback when the transaction is really completed and then I can set the order to completed and deliver items to the user.
I hope someone can clarify things up for me, once and for all (there's so many similiar questions regarding this)
Update
$DECPFields = array(
'token' => $_GET['token'], // Required. A timestamped token, the value of which was returned by a previous SetExpressCheckout call.
'payerid' => $_GET['PayerID'], // Required. Unique PayPal customer id of the payer. Returned by GetExpressCheckoutDetails, or if you used SKIPDETAILS it's returned in the URL back to your RETURNURL.
'returnfmfdetails' => '1', // Flag to indiciate whether you want the results returned by Fraud Management Filters or not. 1 or 0. 'allowedpaymentmethod' => 'InstantPaymentOnly', // The payment method type. Specify the value InstantPaymentOnly.
'buttonsource' => '', // ID code for use by third-party apps to identify transactions in PayPal.
'USESESSIONPAYMENTDETAILS' => '1'
);
$PayPalRequest = array(
'DECPFields' => $DECPFields
);
$decp = $PayPal -> DoExpressCheckoutPayment($PayPalRequest);
This is the request/response
Array
(
[TIMESTAMP] => 2014-04-13T00:14:26Z
[CORRELATIONID] => 7f6dd4f8798aa
[ACK] => Failure
[VERSION] => 112.0
[BUILD] => 10567876
[L_ERRORCODE0] => 10400
[L_SHORTMESSAGE0] => Transaction refused because of an invalid argument. See additional error messages for details.
[L_LONGMESSAGE0] => Order total is missing.
[L_SEVERITYCODE0] => Error
[ERRORS] => Array
(
[0] => Array
(
[L_ERRORCODE] => 10400
[L_SHORTMESSAGE] => Transaction refused because of an invalid argument. See additional error messages for details.
[L_LONGMESSAGE] => Order total is missing.
[L_SEVERITYCODE] => Error
)
)
[PAYMENTS] => Array
(
)

What you explained about other payment gateways is essentially what PayPal Payments Standard is. A very basic HTML form that sends the user over to the gateway where they sign in or enter cc details to complete the payment and it's done. Then you could setup IPN to receive data about that transaction and automate post-processing tasks like you mentioned.
Express Checkout is more advanced. It uses the actual API's and provides a lot more freedom to integrate things exactly how you want to suit your needs.
First, GetExpressCheckoutDetails is optional. When you call SetExpressCheckout and then redirect to PayPal you can use the "useraction" parameter on that redirect URL to change the experience. If you use useraction=commit then two things will happen.
The button on the PayPal review page will change from "Continue" to "Pay"
The PayerID will be returned as a URL parameter when PayPal sends the user back to your site. This allows you to skip straight to DoExpressCheckoutPayment if you want to.
As part of that feature, you can also setup a callback that communicates with PayPal's review page. Their review page will POST the buyer's shipping address and item details back to your script. Your script can take that data, calculate shipping options with it, and return the shipping and tax details back to the PayPal review page. The PayPal page updates a drop down list that gets populated with the results your script returns so the user can complete the entire order using the PayPal review and you don't need to build another review on your own site.
As for DoExpressCheckoutPayment, if you include the USESESSIONPAYMENTDETAILS parameter in that request it will use the details you sent with SetExpressCheckout so you don't have to include it all again.
Something could indeed go wrong with GECD and DECP, so you always want to run through error handling and log accordingly. There are instances where the funding that was chosen on the PayPal page doesn't work, and PayPal actually builds in a way to circle back around and handle that based on a particular error code you'd get back.
Hope that helps!

Related

PayPal Recurring Payments Error - Recurring payments profile description must be provided if the billing agreement type is recurring payments

I am having hard times implementing PayPal Recurring Payments with ExpressCheckout. Curl request is passing through just fine, however I keep getting the following error Recurring payments profile description must be provided if the billing agreement type is recurring payments'. I followed PayPal guide on setting curl options for that at https://developer.paypal.com/docs/classic/api/merchant/CreateRecurringPaymentsProfile_API_Operation_NVP/ and https://developer.paypal.com/docs/classic/express-checkout/integration-guide/ECRecurringPayments
My curl options are set as follows (I will post only options referring the payment profile itself, as the curl request itself is fine):
'L_BILLINGTYPE0' => 'RecurringPayments',
'L_BILLINGAGREEMENTDESCRIPTION0' => 'Installment plan',
'PAYMENTREQUEST_0_AMT' => 0,
'PROFILESTARTDATE0' => date("Y-m-d\TH:i:s\Z")// UTC/GMT format
'DESC0' => 'Installment plan',
'BILLINGPERIOD0' => 'Month',
'BILLINGFREQUENCY0' => 1,
'AMT0' => 250.00,
'CURRENCYCODE0' => 'CAD',
'TOTALBILLINGCYCLES0' => 4
According to documentation when you just set the API Call (doing API operation SetExpressCheckout) you don't need to provide all the details, just L_BILLINGTYPE0 and L_BILLINGAGREEMENTDESCRIPTION0, but the result was the same - Recurring payments profile description must be provided if the billing agreement type is recurring payments'
So, I tried setting all possible options and again failed. I hope someone has already had experience with PayPal recurring payments and can help me out, seriously, PayPal documentation is just horrible! What I am missing?
EDIT: FIXED
Oops, that was my bad (typo in variable).
Correct procedure:
Make SetExpressCheckout API call with required options: L_BILLINGTYPE0 and L_BILLINGAGREEMENTDESCRIPTION0
Grab PayPal token.
Do GetExpressCheckoutDetails API call (optional) if you want to grab details of a payment and payer.
Do DoExpressCheckout API call (required) to complete the transaction where you will need to specify other recurring payments profile details.

PayPal Adaptive Payments - User is not allowed to perform this action

I am using paypal adaptive payments and i had sandbox account for this to be test for last 2 months it was working very much fine and all the transactions were successfully made by using sandbox.
Now what i'm trying to do is want to go live with adaptive payments get all the necessary information api id,password,signature, ap id etc. the problem is i'm facing right now is getting this error
Array
(
[responseEnvelope.timestamp] => 2014-12-08T21:53:30.943-08:00
[responseEnvelope.ack] => Failure
[responseEnvelope.correlationId] => f8bdc47c42067
[responseEnvelope.build] => 13414382
[error(0).errorId] => 550001
[error(0).domain] => PLATFORM
[error(0).subdomain] => Application
[error(0).severity] => Error
[error(0).category] => Application
[error(0).message] => User is not allowed to perform this action
[error(0).parameter(0)] => Chained Payment
)
and i dont know where is the problem can you please help me out
The error is because you Adaptive Payment application is not approved for Chain Payments and you are trying to execute Chain Payments API.
Go to apps.paypal.com and check(I can see that you are not enabled for chain Payments). In order to resolve the error, create a new application at apps.paypal.com and check "Chain Payments" and then use the new APP-ID to initiate this API call. It is also possible when your business/premier account is not Verified
P.S Btw, it is not possible to update the current application as it is already approved.So create new one.

Sagepay Related Security Key Missing

I have found issues similar to this. But I wanted to explain my case as I haven't found a suitable answer.
I have my Ticketing System in which I have implemented Sage Pay. When I make a transaction it will get redirected to SagePay and the Transaction will be completed. Now If I want to refund the Payment I need to go to SagePay, login there, select the Order which has to refunded and then refund it. So instead I thought of implementing it in my Ticketing System. When the transaction is completed through SagePay a response code is generated which looks similar to this .
Array ( [VendorTxCode] => 14-11-04-16-19-30-8989049 [VPSTxId] => {8D7FC333-9979-DA1C-32E0-AAA2CC1A31FB} [Status] => OK [StatusDetail] => 0000 : The Authorisation was Successful. [TxAuthNo] => 164996 [AVSCV2] => SECURITY CODE MATCH ONLY [AddressResult] => NOTMATCHED [PostCodeResult] => NOTMATCHED [CV2Result] => MATCHED [GiftAid] => 0 [3DSecureStatus] => NOTCHECKED [CardType] => VISA [Last4Digits] => 0006 [DeclineCode] => 00 [Amount] => 10.00 [BankAuthCode] => 999777 )
Now in order to refund the transaction I need to have RelatedSecurityKey which is not being sent by SagePay. When I go to Sage Pay, get the Security Key and Hard code the value in my Refund API I am able to refund the Transaction. Is there any way to get the Security Key in my Ticketing System. If so how?
If you are using Server, you will get a security key as part of the response to the initial transaction registration post. You can then pass this back with the Refund posts as RelatedSecurityKey.
If you are using Form, you won't get this value sent back. In this instance, you could use the Reporting API to get the Security key (getTransactionDetail command) instead of logging into My Sage Pay.

Embedded Adaptive Payments for digital goods between 2 users - confused about the need for an IPN

I'm building a site for a client that wants to enable users on the site to put ebooks for sale, which can be bought by both site members and non-members. The site itself is not involved in the transaction at all.
I've gone with adaptive payments as that seems to facilitate "peer to peer" transactions between two users where the site is not involved and does not take a cut or any payment. I'm using the guide found at https://developer.paypal.com/webapps/developer/docs/classic/adaptive-payments/integration-guide/APIntro/
Unfortunately the hosting uses php 5.2.17, which means I cant use the PHP API code on github, so i've had to roll my own using PHP. This isnt a problem, i've done similar many times before. I've managed to get the sandbox working the following way
user initiates purchase
my site makes a call to https://svcs.sandbox.paypal.com/AdaptivePayments/Pay
with the following json encoded array :
$payload = array(
'actionType' => 'PAY',
'currencyCode' => $currencyCode,
'receiverList' => array(
'receiver' => array(
array(
'amount' => $amount,
'email' => $receiverEmail,
'paymentType' => "DIGITALGOODS"
)
)
),
'returnUrl' =>$successUrl,
'cancelUrl' => $cancelUrl,
'requestEnvelope' => array(
'errorLanguage' => 'en_US',
'detailLevel' => 'ReturnAll'
)
);
This gives me a pay ID
i then put into the form which submits to https://www.sandbox.paypal.com/webapps/adaptivepayment/flow/pay
when the user clicks "Pay Now" the paypal light box pops up
if the payment is completed paypal returns me to my return url
i then display the download link
However when I look in the sandbox I see that The latest payments are under review ( apparently making my sandbox balance 10,000 has flagged me as a potential terrorist under australian law. go figure ) so this makes me think that perhaps I need to make an IPN, even though the developer documentation listed above makes no mention of it. The last thing i want to do is enable a download whos payment gets rejected.
So i guess my question is:
Is the fact that paypal called my return URL enough to allow the download of a digital good or should I setup an IPN and wait for paypal to hit it before authorising the download ?
PayPal is a PITA! And there's no argument about it.
Back to your question. You should verify if the payment when through when it calls your return URL. It should send you a token/transaction which you can query and check its payment status. Haven't used Adaptive Payments that much but you should always make sure a payment is completed before granting access.

Paypal Adaptive Pay

When I run a PayPal Adaptive Pay call, and I set about 3 receivers, how to I get the status of each of the receivers?
Because I get something back like this:
Array
(
[responseEnvelope.timestamp] => 2012-11-05T13:17:48.598-08:00
[responseEnvelope.ack] => Success
[responseEnvelope.correlationId] => 8e31ecdad58ca
[responseEnvelope.build] => 4110101
[payKey] => AP-6TJ00518SC231111B
[paymentExecStatus] => COMPLETED
)
Does this go through the IPN or can I view it in a sandbox area? I keep re-reading PayPal docs and Im so confused :)
just use PaymentDetails api to obtain an array of PaymentInfo elements with status for each receiver. If you have permissions from each recipients to make GetTransactionDetails API calls on-behalf of them (which you can obtain using Permissions API) you can use the TransactionID from the PaymentDetails API response to obtain further more transactional data for each one of the sub-transactions.

Categories