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.