We plan on supporting Layouts A/B as soon as practical, but that's going to be a major can of worms to sort out. The main problem is that those layouts allow the buyer to change their shipping address during checkout, but there doesn't appear to be any way to lock in the destination country and postal code specified in the cart, nor any way for that checkout flow to callback to our system to recalculate shipping, so it would be possible for buyers to pay inaccurate shipping charges for their actual shipping destination or even deliberately defraud you of proper shipping charges.



We had originally implemented Layout C by embedding that payment screen in an iframe on a checkout page we managed with a nice order summary, but early adopters started getting frequent problem reports from buyers who were unable to proceed with payment. Eventually, we deduced the problem was due to browser settings blocking third-party cookies:

1http://www.e-junkie.com/bb/topic/6028#post216221



Since Apple Safari has long blocked third-party cookies by default, and Firefox soon will as well (as of v22), not to mention the many users who enable that setting deliberately for privacy reasons, we had little choice but to bypass the iframe embedding and simply redirect to the Layout C payment screen itself. If PayPal ever figures out a way to use the iframe embedding method without needing to set a cookie, we'll gladly reimplement that.

gorillaAs I've been told Layout C was specifically created to be embedded or customized in a hosted page but since E-junkie is just redirecting on submit button straight to Layout C it does not make sense as this layout should not be used as standalone.



I understand the positive support for PayPal advanced payments but the implementation is not good and not as intended by PayPal, that layout was not made to be shown with a page redirection and rather embedded on a checkout page.

gorillaAlso I do not ship any items, everything is downloaded from e-junkie servers, I do not need shipping address in the form.



I'll pass your answer to the PayPal team that is assisting with this issue.

Also unfortunately, it's an all-or-nothing proposition. If we support Layouts A/B, we'd be doing so for everyone; even though it would not adversely affect sellers such as yourself who sell no tangible goods, it would affect sellers who do sell such items. I'll see if Development might be able to make seller-specific exceptions to this upon request.



Glad to hear you're passing this along to PayPal; maybe if enough people point out to them (as we've already done) how the third-party cookie blocking issue makes their iframe-embedding method obsolete, and how a lack of shipping-recalculation callback support makes Layouts A/B susceptible to shipping-fee fraud, they'll devise a fix or workaround for those problems.

We're successfully using Layout C and the white form page, and have had zero complaints about the lack of branding or the odd domain name.



(We were one of the early adopters in the linked discussion, so you can probably blame us for the lack of an iFrame -- we were getting continual failure reports from users due to the third party cookie issue. Since the change, not a single complaint.)



We were able to put our logo at the top of the "Billing Information" form, so perhaps that's helping users feel comfortable. I honestly can't recall where we did this, but it's somewhere within the twisty maze of passages that are all part of the eJunkie configuration screens.



Once a user clicks off that page, they are taken to the actual paypal https site, so I think that allays any fears -- at least for our users, it's never been reported as an issue or reason they didn't buy.



You can see our credit card integration by adding any of our products to the cart (hover over an icon and click Buy), then clicking the credit card logo: http://manytricks.com1.



regards,

-rob.

No, we've always only used eJunkie (didn't want to try to integrate two disparate systems into our buying process). When we saw that they'd added Pro support, we signed up and dove in.



Credit cards now make up about 5% of our purchase transactions; the vast majority of our customers pay via PayPal, and a much smaller percentage pay with Google (which we'll probably drop soon).



-rob.

Whoops, too early in the morning: we have Advanced, not Pro.



-rob.

BTW, the custom logo/header Rob mentioned can be uploaded in Seller Admin > Edit Profile. This would be shown at the top of the initial checkout screen where we request the buyer's address(es) before redirecting them to the actual payment screen. It appears you've already uploaded your custom logo/header, gorilla, so I'm mostly just mentioning this to confirm that with you and in case anyone else reading along here may be curious about it.

Yes, unfortunately we can only add your custom logo/header to pages we manage, such as the initial checkout page; PayPal provides no way to customize their final payment page. Note that the third-party cookie blocking issue would affect ALL sites that use PayPal Advanced with Layout C embedded in an iframe; that issue isn't just something peculiar to our own system.



As for the new Admin, we had some false starts and unforeseen setbacks in 2011, but about a year ago we hired an experienced new developer specifically to help out with the new Admin project and got a fresh start on that; we are very conservatively projecting it should be done by the end of this year, and optimistically projecting very much sooner if all goes to plan. Initially, we're just shooting for feature-equivalence with the current Admin, to keep the project scope focused and avoid feature creep that would only set things back even further, but once that's done, we'll be able to start modifying it as needed to support new features and functionality.

This is very disappointing news. I agree with gorilla completely and actually opened a ticket minutes ago regarding the hideous looking white form (before I found this post).



I also have a hard time believing people would trust and use that form. Maybe because I've been programming professionally for 10 years, but the appearance is embarrassing and doesn't exactly scream "legitimate, safe, secure business".



I started with eJunkie because of price, but as my eBay and website sales increase I really need an online cart that accepts on-site payments. I was trying to decide between eJunkie with PayPal Pro / Advanced or a more robust solution like Shopify. Looks like I'll have to bite the bullet and invest energy in that.

We agree that the final payment screen for card-based payments using PayPal Advanced is not exactly confidence-inspiring when displayed by itself, but unfortunately the iframe embedding method that PayPal intended for that form requires setting a third-party cookie, which caused problems for a significant number of buyers, as Rob mentioned above. That number will only increase as people upgrade their browsers and as more browsers block third-party cookies by default, not to mention people increasingly enabling that setting deliberately for privacy reasons (as most third-party cookies are used for advertising and tracking purposes). This third-party cookie-blocking issue will affect EVERY site that uses an iframe to embed that payment form as PayPal recommends; it's not something peculiar to E-junkie.

I understand completely. It's disappointing for me because I know for my business I have to take the "on-site" processing step within the next year or two. I prefer to take this step with eJunkie because I have my site designed and traffic coming to the existing URLs.



I don't want to start a store from scratch with say Shopify and result to redirects for my existing traffic. Also, eJunkie integrates great into my site and it looks great (beside the page in discussion).



Maybe making A/B templates available to some like mentioned above could be a solution. I sell tangible goods, but offer free shipping on all products so the shipping calculation issues wouldn't affect me either.



I want to end by saying, I love eJunkie's cart! I really do. If you guys could get a professional looking on-site checkout solution/page, it would really bring your service full circle.



Oh, and fix the flash login so I can manage my store from my iPad

Okay, Development says that for specific sellers upon request, we can disable the part of our code that requires Layout C, so you can set up Layout A/B in your PayPal Manager and see if/how it works for you. To confirm your identity and attend to this request, we would need you to email Support with your E-junkie account password, or your Subscription ID (from your Seller Admin > Account Summary screen), or your original activation code (from the original "Account information" email we sent you at registration):

https://www.e-junkie.com/ej/contact.php



Bear in mind this would be considered an unsupported hack for use entirely at your own risk, as we have not tested this at all nor researched any settings or other parameters that may need to differ from the standard setup for Layout C, so we can offer no guarantees. Once we disable the Layout C requirement for your seller account at our end, you would be expected to configure any needed settings in your PayPal Manager and test it on your own to make sure it actually works.

This is the page where I found PayPal Payments Advanced listed as a "Legacy product" which is "No longer actively marketed; now included with PayPal Payments Pro":

2https://developer.paypal.com/webapps/developer/docs/classic/products/payflow/2



Elsewhere in that documentation, they have indicated that "Legacy products remain available for pre-existing users", so it seems they will continue to support existing integrations using it into the foreseeable future.



We've already prepared the design for a more modern, mobile-responsive card checkout page, but Development still needs to actually implement that as a live checkout page, replacing our current card checkout page (which is not responsive, as you've seen). When that project is completed and goes live, we would post a notice to our System Status & Updates forum here:

http://www.e-junkie.com/bb/forum/6

There are ways to have us post the order details to more than one URL, and I've contacted EDD support to clarify something about their integration which would determine the best approach for that; however, EDD's E-junkie integration would only have us post the order details to EDD after we're done processing the buyer's order, so you'd still be using E-junkie's purchase buttons and checkout -- i.e., this wouldn't allow you to use some other checkout experience and then have E-junkie issue download links after the buyer has paid.

If you want to continue using E-junkie's download delivery and affiliate features, you must sell your products using E-junkie's purchase buttons and checkout flows.



Only PayPal Advanced uses that rather bare-bones top-left-aligned payment information page that comes after the buyer submits their billing/shipping address on our checkout page. 2Checkout works similarly, but their payment information page is much nicer than the PayPal Advanced one. Only PayPal Payments Pro, Payflow Pro, and Authorize.Net use a single page for our card checkouts (which all use the same non-responsive page you've already seen for PayPal Pro). You can see the 2Checkout flow by testing our demo cart here:

http://www.e-junkie.com/ej/2checkout-shopping-cart.htm



Also bear in mind that the PayPal Payments Standard checkout site will usually offer a card-based payment option for buyers without a PayPal account, depending on your own PayPal account type and related settings, which we explain in more detail here:

http://www.e-junkie.com/ej/faq.paypal.card-checkout.htm

2Checkout's process begins with the basic form on our site but then redirects to a different payment form at their end. You can see that by filling out the demo checkout at http://www.e-junkie.com/ej/2checkout-shopping-cart.htm with any information and then clicking the "Proceed to payment form" link at the bottom.

EDD has not replied to my inquiry from over a month ago, so I've just sent them a followup reminder.

EDD SupportSo it actually looks like we'll have to make some decisions with this extension very soon (as we are about to do with all extensions we sell). The thing is, EDD hosts an extension marketplace. While there are several 3rd party extensions that we do nothing more than link to, there are also several that we sell for 3rd party developers. We simply take a small commission cut.



Some extensions, like this one, don't sell much at all. And we've recently made the decision to start getting rid of them. I did ask the extension developer about the things you mentioned, specifically the last paragraph of your original query [regarding why, or even if, it required both a Code Generator URL and Payment Variable Information URL, both identical]. His response was:



"Thanks for the update. It's been a while, so I'm not sure why I chose to use both."



Obviously, that's not very helpful. It was immediately followed by asking us, the EDD team, if we were interested in buying the extension from him. Because of its very low sales (2 in a year and a half), we aren't. So it's very possible that it will be taken off of the market extremely soon. And I can say with certainty that its codebase will not be receiving an update from us or its developer.

It may help to clarify whether you're upgrading to PayPal Payments Pro vs. PayPal Payflow Pro.



If you'll be using PayPal Payments Pro, then there are no credentials to enter at our end, aside from your PayPal Email; the API permissions in our setup instructions would take care of the rest:

http://www.e-junkie.com/ej/paypal-partner.htm



If you'll be using Payflow Pro, that uses the same PayPal Manager credentials as PayPal Payments Advanced:

http://www.e-junkie.com/ej/paypal-payflow-pro-shopping-cart.htm



In both cases, card-based checkouts would use a secure checkout page we manage for you, rather than anything at PayPal's end. To preview what this page looks like, you can test the demo cart buttons at either of the links above. It's mostly the same as the buyer name/address initial checkout page you saw with PayPal Advanced, except that it incorporates card account info fields in the same page, rather than using the separate, bare-bones PayPal-hosted card-info page you saw with Advanced. BTW, we're quite aware that checkout page looks rather dated and are planning to modernize it soon. :^)

This is the first we've heard of in-context checkout, so it must be pretty new, and we'll have to research that further; thanks for the tip!



I've already prepared the HTML/CSS for a new card checkout page, just waiting on Development to get to that item on their to-do list. :^)

This is the first we've heard of in-context checkout, so it must be pretty new, and we'll have to research that further; thanks for the tip!



I've already prepared the HTML/CSS for a new card checkout page, just waiting on Development to get to that item on their to-do list. :^)