I am integrating payflow link in a website.
I have a complex return URL to which the payflow link has to redirect after the user has a successful payment. the url is of kind
www.example.com/index.php?controller=main&data=no&detail=on
the problem is that when payflow redirects the user it replaces & with & amp; and the url becomes some thing like this
www.example.com/index.php?controller=main&data=no&detail=on
which crashes the framework because it arranges $_REQUEST parameters as follows
$_REQUEST['amp;data'] = no AND $_REQUEST['amp;detail'] = on
what should be done to avoid this?
This will only happen if you are trying to set RETURNURL programatically. If you set this value inside of the manager account's hosted checkout pages settings it will not.
This is because the variables you pass to the payflow server are going to get urlencoded. To get around this include a length on your variable:
RETURNURL[66]=http://www.example.com/index.php?controller=main&data=no&detail=on
Related
For my users to be able to send money to each other on my website I figured the following flow:
User is authenticated with paypal connect
"Clicks on a pay button" calling my api
In the api
Create an order calling /v2/checkout/orders
what returns HATEOAS links, order id. And, I need the user to follow the authorize order
link from the HATEOAS links to authorize the order.
User follows the link.
I capture the order calling /v2/checkout/orders/{id}/capture
And, here is a question: how do I know when users follow the authorize order link to call the capture api? If that is not possible, is there a way to authorize orders calling the paypal api directly without making users following some links?
First of all, what you are actually talking about is user "approval", not authorizing.
The best approval flow to use is this one: https://developer.paypal.com/demo/checkout/#/pattern/server
This way, they don't follow a link and are not redirected away from your site. Your site stays loaded, but is just greyed out while they are presented with an in-context approval flow, and return to your site's JS, which will do a fetch call to your server, which can then do the capture.
An alternative legacy flow is to provide a return_url in your initial create call, where the payer will be redirected back to after approval. This is not recommended, the above solution (that uses no redirects at all) is much more modern and preferred.
I'm using the examples in the paypal-php-sdk and setting up payments. It works fine and I'm getting the redirect URL and I'm able to make the payment.
In the example the PaymentId is stored in the session, and later in the executePayment.php retrieved. In the comments it says to store this, off course in a database.
But how can I link this PaymentId to the return values givin by the paypal api?
When the payment is approved I'm sent back to my webstore with this parameters:
ExecutePayment.php?success=true&token=EC-xxxxxx&PayerID=AXxxxxx
How can I link the token-payerID to my PaymentID? So I don't have to store it in a Session? For instance is it possible to get the ec-token during the build of the payment?
It turns out to be very simple!
In the return url parameter you just give the url an query string. Pretty simple:
$returnUrl = 'executePayment.php?orderId=234'
Paypal then automagically adds the token and payer-id to the return URL.
I'm using PayPal PayFlow Pro to process transactions. We've opted to use the secure token with transparent redirects to try and address PCI-Compliance issues.
In my token request, I am specifying the CUSTREF parameter like so:
&CUSTREF=461
I have also created a hidden field for this in the transaction form. I have the HTTPS proxy enabled for Fiddler and I can see these values coming through in both the secure token and transaction requests. The transactions complete successfully on the live PayFlow gateway.
However, when I view the transactions under https://manager.paypal.com/ > Reports > Daily Activity, the Cust Ref #: field on the detail page is empty.
The parameter is discussed for use in inquiry transactions on page 71 of this document:
https://www.paypalobjects.com/webstatic/en_US/developer/docs/pdf/payflowgateway_guide.pdf
I couldn't find much documentation on this field other than this. I had a look at some code samples, and it looks like the CUSTREF parameter should be passed in the transaction request (which was the first thing I tried), e.g.
https://github.com/angelleye/paypal/blob/master/PayFlowTransaction.php
Has anyone encountered this before? I have a ticket open with PayPal.
I received confirmation from PayPal that this is a bug.
This appears to work with the regular Payflow Pro API calls, but fails when passing the CUSTREF using a Secure Token API call or hosted pages (using Secure Token).
The recommended work-around was to pass the field through in the comments.
I have an application that uses Express Checkout to process payments.
I need some way to cancel a transaction after calling SetExpressCheckout (and having the user fill out his details on paypal's page) and before i actually complete it with DoExpressCheckoutPayment.
I can't find the right way to do it in paypal documentation, do i just let it time out or do i need to do some API call?
You just let it time out. If you haven't called DoExpressCheckoutPayment yet, no action has yet taken place.
The token automatically expires after three hours.
Technically you could just empty the token REQUEST, and unset the reshash SESSION and let it expire without risk (assuming you are using the same named variables the api samples came with. What language are you using? I can further provide examples.
In PHP I would simply do:
// empty token
$_REQUEST['token'] = NULL;
//unset reshash session
$_SESSION['reshash'] = NULL;
unset($_SESSION['reshash']);
Now you would ideally want to redirect the user to a cancellation page, something like
header( 'Location: http://www.example.com/transactionCancelled.html' )
Otherwise depending if the user is in the 'ReviewOrder' phase, they will just automatically get redirected back to paypal to start a new transaction.
Would implementing openssl prevent users from changing the button values?
I've researched into encrypting buttons, from hosted to using openssl.
Using hosted buttons would provide security at the cost of flexibility although there are variables that you can override, but still you cant override the important ones.
would using and implementing openssl on my webserver prevent users from changing a non-hosted paypal button ?
or would it just be better to fall back to a hosted button and use/validate using IPN?
My answer is non–PayPal specific (applies to any kind of HTTP form input), but the short answer is no. Even SSL cannot prevent the browser from modifying the form values that it receives.
A user could use a bookmarklet to execute a JavaScript program of her choice on your page after it has loaded, which has the ability to change form values. Because SSL only protects the transport between the browser and the server, not after the page has been processed by the browser, it makes no difference at all whether you use it.
This could be automated with Greasemonkey, which is the same idea, except makes it even easier for users to install other people’s JavaScript programs to run on your web page. As above, using SSL does not affect this at all, because it is all execute client side, which you, as the server, have no control over.
As you alluded to, using encrypted PayPal buttons would solve the problem, as any modification of the button parameters would invalidate the checksum, and PayPal would not accept the item.
The best solution would be using Express Checkout. This allows you a great deal more flexibility than standard buttons can ever offer you.
If you're thinking if doing IPN, you're probably capable enough to integrate Express Checkout. All it really is, is 1 API call, followed by a redirect to PayPal, and a minimum of 1 more API call to finalize the payment.
A typical flow would look as follows:
Call the SetExpressCheckout API. If you're new to this, it's made dead-easy with PayPal's NVP API interface. You can just send the data as a GET NVP string to https://api-3t.paypal.com/nvp and get a response back in the same format.
Take the token from the response, and redirect to https://www.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=XXXXXXX (https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=XXXXXXX for Sandbox testing)
As soon as the buyer is returned, PayPal will append a PAYERID to your RETURNURL. If you can't find it, call the GetExpressCheckoutDetails API and supply your token to retrieve it.
With the PAYERID and TOKEN, call DoExpressCheckoutPayment to finalize the payment.
To get started with this, I'd suggest taking a looking at the PHP NVP SDK they offer at https://www.x.com/community/ppx/sdks#NVP