Following the instructions in their documentation, I've successfully implemented a PayPal Advanced solution within an iFrame. The process works fine using a credit card. However, there are also two buttons that show up in the form for "Checkout with PayPal" and "Checkout with BillMeLater..."
When the user clicks either of these buttons, the window breaks out of the iframe and the session has expired.
Can this top of the form be hidden, or at the very least, be made to open within the iframe and keep the session, as it should?
Thanks for any help and suggestions.
Which layout option are you using? A, B, or C? It sounds like maybe you have a conflict there..??
Chapter 3 of the PayFlow documentation covers this in depth.
Related
I am trying for the first time to implement a PayPal Checkout solution (aka PayPal Commerce Platform for Business) in an ASP.NET Web Application, using Web Forms. I've set up a new REST API for the Sandbox and followed PayPal's Set up server-side SDK guidance to install the SDK in my .NET project. PayPal's button demo now lets me log into the Sandbox with a newly created Sandbox user name and make a test payment, which is confirmed as being successful. So far, so good.
My next step was to create a PayPalButton.aspx page containing exactly the same code as used on Paypal's button demo page. All my updated code was then uploaded to my live site. That's when I hit a problem, as the PayPal buttons don't work on my live site (the PayPal log in window just briefly flashes and then disappears). Being a total newbie to the Paypal Checkout process, it's highly likely that I have made some very basic error.
The only thing I can think of is that my problem might have something to do with the section in Set up server-side SDK that refers to modifying HTTP request headers? I didn't understand what that section was asking me to do.
What routes/paths did you implement the create order and capture order functions at? What data do they return? Update your question with this information. For the create order route, is the data a valid JSON object with a PayPal order ID in the id key?
Have you set the paths in your "PayPalButton.aspx" HTML/JS code to call the aforementioned routes? Your question does not include any specific information about what is going on, i.e. your button code and the result (Response body) of the fetch calls from the browser's developer tools 'Network' tab.
This morning, I managed to resolve the problem with my PayPalButton.aspx page just briefly flashing the PayPal login page. As previously mentioned, it contains a script copied from PayPal's button demo. I then realised that it was different from the sample script provided on the Integrate Checkout page.
I created a new PayPalButton2.aspx page containing this alternative script and, unlike PayPalButton.aspx, it worked fine. In both cases, I had substituted my own Sandbox ClientID.
I am adding a PayPal "Buy Now" button to a web site using code supplied by the PayPal developer site. It's possible to have options, for example garment sizes, XL,L,M,S... I see how to set up the button so the user can make a choice, but how do I access the choice so that I can take action? Is this supposed to be done in HTML, or should I write a CGI program to take my action - this is my preferred option - but either way, how can I access the option values? I am new to all this, but I can't find anything in the PayPal Developer documentation.
This can be easily done. Please look at the follow sample implementation and the source code for setting a Multi option based button.
https://www.paypal.com/us/cgi-bin/webscr?cmd=_pdn_xclick_options_help_outside
In my wordpress site, I need a paypal donation feature to work so, if, for example, they donate $5+, they are taken to one page(redirect). If they donate $7+, they are taken to another, and so on. I've tried multiple donation plugins, but all of them only have one URL you can use after a donation.
Any plugin you know of or other way this can be done would be appreciated.
You'll need to either write your own plugin or an extension of one of the ones you've already tried.
Basically, you'll set the redirect URL in your payment code (whether API or standard HTML checkout) to a page that will use PHP or whatever you're comfortable with to check the amount and then do another redirect based on that. Nobody would ever seen that page, of course. They would just see their final page based on their donation amount.
Again, though, if you can't find an existing plugin that gives you that option you can easily customize it. That's the beauty of WordPress and (properly developed) plugins!
Paypal has recently changed integration method. Now instead of providing public/private key option paypal has selected javascript button. My question is how much secure is this? Say for example i have used following code to create button.
<script src="js_path/paypal-button.min.js?merchant=XXXXXXXXXX"
data-button="buynow"
data-name="SiteName"
data-amount="10"
data-env="sandbox"
data-callback="payment_success.php"
data-cancel_return="payment_cancel.php"
data-currency="EUR"
></script>
Now if you are familier with firefox addon of firebug then you can see all this values and easily edit them and pass them to paypal page. It will easily change amount of 10 to 1 and customer can pay 1 and leave site. This is loss to merchant.
Previusly i was using method of http://www.stellarwebsolutions.com/en/articles/paypal_button_encryption_php.php to create encrypted buttons. It was working properly and no customer had complaint any problem like i had mentioned before.
My question is that can this new system paypal has created has this facility of encryption? If not then what is solution?
Thank you
Tejas Mehta
If you are wanting to use encrypted buttons so they can't be modified, you would want to use PayPal's BMCreateButton API so that you can dynamically create buttons on the fly. You could create hosted buttons, or encrypted buttons. Both buttons would prevent someone from modifying the amounts and etc.
I'm working on a custom e-commerce system for a client and ran into a fork in the road. The checkout system I'm using is very flexible and is meant to be integrated into an existing Web site. So essentially, I have all my products on a page. Each product has a "Buy Now" button associated with it. When clicking on that button, a modal window opens, showing a cart-like screen with the item they chose being added. From here, they can either close the modal window and "buy" another product or checkout. Here is where the fork comes in:
Option A: They are now redirected to the merchants site for the actual checkout. I can make that page look anyway I want, but it's independent from the client's real site. So if something on the real site changes, I have to update my files on the merchants site manually so there won't be any confusions e.a. a new menu item is added in the header.
Pro: They checkout on a page that's branded as the client and it takes up the full page. It might provide a better sense of security as apposed to option B.
Con: May involve some manual maintenance to keep the appearance of the site consistent.
Option B: When the modal window displays and they click on checkout, a new window/pop-up opens up. It shows them everything they need to checkout... name, address, billing info, etc. It would still be branded as the client's checkout system, but you wouldn't see the entire site (header/footer) in that pop-up window.
Pro: No maintenance involved and they'll always see the site in the background and know where they are at. On completion of checkout, they can close the window and are right back where they left of.
Con: It might defer some people from checking out, because you can't really tell where you're entering your credit card info... although it would be branded accordingly. They may also have a pop-up blocker that could prevent the window from opening in the first place.
Does anyone have any experience with this? Are people less likely to checkout from a pop-up window vs. a full page checkout system?
Any feedback much appreciated.
-Ryan
The answer is to brand the Web site and not use a pop-up, even if it requires some manual updating of the headers and footers. The reason being, that from the user's perspective, it can be hard to tell whether this is a pop-up from that site you just clicked "Buy" on or whether this is an ad from that site or another open tab. Furthermore, if you look at what everyone else is doing, you don't ever check out in a pop-up window. Lastly, the moment something pop-up asking for my credit card, I tend to close it, so knowing how I react to those, I answered my own question.
Case closed.
-Ryan