v060 Beta Pre-Release: PayPal Standard, Guest Checkout, Multiple Payment Options

brettbrett FoxyCart Team
in Important News edited October 2009
Hello all.
We're very excited to give interested developers access to v060 as a beta pre-release. There are _many_ of you that have told us you needed v060 "yesterday" or "last week," and while it's not 100% at this point, you can now turn it on for your stores.

What it has:
The big ones are:
* PayPal Standard
* Debit (non-credit) card support
* True guest checkout (checkout as a guest or create/use an account)
* Display the full checkout on pageload
* Multiple payment options (CC + PO + PayPal or any combo)
* Much better cart functionality wrt detecting changes that would require an update, and improved updating (try changing quantities on the cart)
* XML now has CDATA tags

What you absolutely need to know:
v060 is still undergoing _ACTIVE DEVELOPMENT_, and things _WILL CHANGE_. The wiki upgrade notes are a work in progress. PayPal's sandbox is kind of a pain, and we haven't documented it yet.

We do NOT recommend using v060 on a live store at this point. Really, we're not just saying that. We've done a lot of testing, but there are bound to be issues, so please don't just "set it and forget it". Let us know about any strangeness or room for improvement, and we'll let you know (via this thread) about any changes we made from here out that might impact you.

What's not done yet:
* Ability to select the guest/account options. (Default to guest, default to create an account, only allow one or the other.)
* Subscription improvements.
* Testing Google Analytics as it relates to PayPal Express Checkout.
* More.

Again, DO NOT USE THIS!
You've been warned ;)

UPGRADING:
We recommend no upgrading your live store at this point, but rather creating a new store to test with.

Links of interest:
* Upgrade notes
* New XML (coming soon; you can grab it yourself if you're interested in the meantime)
«134
Comments
  • rthrashrthrash Member
    edited October 2009
    How are multiple payment methods handled; is it per category?

    What does "true guest checkout" mean?

    When do you anticipate active development to cease? I mean it's nice and all that we can test, but not being able to use it in production and rightfully warned against it, doesn't solve the "yesterday" and "last week" issues that we too face.
  • The admin site seems pretty borked on 060-- like the CSS just isn't there. Among other things, it appears *not* to be possible to downgrade to 051.

    The entry page (w/sample code) looks okay the first time that it's loaded, but after clicking through to any other pages, it's a full plaintext site, and there's no menu to get to the other admin pages. The template section seems to be missing from the pages-- the page source begins at
    <noscript>
    
    -- so the whole
    <head>
    
    and header sections are missing.

    The forms also appear to not be working: Once you upgrade to 060, you cannot make changes to the template or select a different store version.
  • brettbrett FoxyCart Team
    edited October 2009
    Checking on that now. Thanks Oskay. What browser are you using when you're seeing the borkage?
    Fixing right now.
    Fixed. Sorry about that. Miscommunication with something between staging and production. Human error.
  • This is great news! I can't wait to try it out! :)
  • brettbrett FoxyCart Team
    @rthrash: Payment methods are per store, but could be easily forced per category (or anything else) using the JSON and javascript on the checkout.

    As far as the development schedule and further changes go: When we call it "ready" will be largely based on how much feedback and bug reports we get from everybody during this testing phase. We've done a lot of testing, but there are many changes, and there are always bugs to be found (even after a true release, as you can see based on the number of improvements and fixes ported back to 050 and 051 in the 060 changelog). If you need the functionality in 060 though the best way to make sure it's ready for production use is to test it and let us know about issues. We'll be fixing them as quickly as we can.
  • Would you be good enough to copy the change log into the "Reports" section of the admin for 060? I think that the only way to see the change log right now is to downgrade and then upgrade again....
  • brettbrett FoxyCart Team
    Good point, oskay. That page is set to only pull from "available" versions. To prevent newly created stores from being at v060 for the time being, v060 isn't "available" so it's not being included. We'll discuss that. (Actually, I think we'd be safe to change that because of some recent improvements to the admin, but I'll update later about it.)
  • If you change "Bank card payment method" to "Paypal Express" and check pick "Use default test account", foxycart provided test API credentials are not inserted. Should they be?
  • brettbrett FoxyCart Team
    Nice catch, tookings. That "PayPal Express" shouldn't actually be there at all. If you want to turn PayPal on use the second checkbox there, "Let customers pay with a PayPal account."

    Also, due to the nature of testing PayPal on their sandbox, we won't be able to provide test accounts for PayPal. We'll document this as soon as we can, but for now you have to create your own dev account.
  • That makes more sense now. :)
  • Not certain that this is new, but it's our first time not using guest-only checkout.
    Incorrect Password:
    That email address looks correct, but the password is not. Please change your password or click the link below to have your password emailed to you.

    When this message is displayed, the "Email me my password" link is no longer visible.
  • brettbrett FoxyCart Team
    Ah... you mean you have been forcing the "fake" guest mode by passing in a space for the customer_phone, and now that we have true guest checkout mode those previous customer emails are showing up as existing customer records? Or am I missing the situation?

    That's a good question. The "fake" guest mode in 051 and prior didn't actually mark the customer as a guest, and those users do actually have a randomly generated password on their accounts. What might make sense would be to take all your existing customer records and set them as "guests", so that from here out your customers can create accounts or checkout as guests, whichever they desire.
  • Ah... you mean you have been forcing the "fake" guest mode by passing in a space for the customer_phone, and now that we have true guest checkout mode those previous customer emails are showing up as existing customer records? Or am I missing the situation?
    That is the case, but it's not what I meant-- I really did mean that there's a case you can get where it says "Click the link below" but there's no link below.

    I was going to ask about the randomly generated passwords, but that's a *very* different question, and I thought that I would wait until the first layer of dust settled on 060. BUT, since you bring it up... setting prior customers to "guest" sounds like a great idea. How can I go about this?
  • lukeluke FoxyCart Team
    @oskay: We'll probably have to do it from our end... it's actually something we talked about months ago, but I'm not sure we ever landed on a for sure solution. 060 comes with a true is_anonymous bit which, in theory, you could update using the API, but depending on how many customers you have, that might take a while. We'll try to reproduce the missing link, but if we can't will hit you up with some more questions on what the details are to see that.

    @tookings: looking into that one now. I really thought I had removed that from the drop down.
  • Hurah! for the first substantial update in a long time. Keep up the great work guys!

    Do you have a rough ETA for when this new version can be deemed "stable"?
  • lukeluke FoxyCart Team
    @TwoVectors: that depends largely on what some of our developer friends out in the field find wrong with it. Also, we have some features we'd still like to improve in this version. Additionally, we plan on moving the FoxyCart store (signup) to this version and using it to run our business first before we sign off on it for everyone else. That's something we didn't do in 051 and should have.
  • lukeluke FoxyCart Team
    @tookings: Fixed. There we actually two places where paypal_express needed to be excluded on that page and I only changed one of them. Thanks for catching that.

    @oskay: The changelog should now show up, but keep in mind it will be changing up until we make this version officially launched.
  • oskayoskay Member
    edited October 2009
    >The changelog should now show up

    Hmmm.... Not seeing it yet.

    Edit: Also, recent transactions don't seem to be showing up in the transaction log.
  • brettbrett FoxyCart Team
    Thanks oskay. Luke got too excited and forgot to actually commit the changelog fix. We'll take a look at the transactions displaying and let you know about that as soon as possible.
  • >060 comes with a true is_anonymous bit which, in theory, you could update using the API,
    >but depending on how many customers you have, that might take a while.

    I'm looking at the API. I suspect that there may be something amiss with the 060 datafeed/API results-- I can use it to view recent transactions (taken in 060). None of them have the anonymous bit, nor do they have any customer data-- it all looks like this:
    "<customer_first_name><![CDATA[]]></customer_first_name>"

    Cart contents are there, though, and when I query older transactions that took place under 051, customer information (such as first name) is there... so it looks like a problem of data collection and/or storage, rather than retrieval.

    In any case, we do have thousands of customer records that apparently need to be updated....
  • >We'll take a look at the transactions displaying and let you know about that as soon as possible.

    No rush-- I have the transaction e-mail. Just thought that I should report bugs as I come across them. ;)
  • brettbrett FoxyCart Team
    Oskay and all: We've confirmed that there is an issue with storing completed transactions, which affects the transaction display and the API, but not the receipt or XML datafeed. We will update as soon as we have this resolved. Thanks for pointing it out, Oskay. (And in case anybody's wondering, yes, this is a big thing for us to miss in our own testing. It has to do with changes made to our dev database but not yet pushed to our production system.)

    Update: We've identified the cause. We'll update again once it is resolved.
  • rthrashrthrash Member
    edited October 2009
    @rthrash: Payment methods are per store, but could be easily forced per category (or anything else) using the JSON and javascript on the checkout.

    Glad this is easily forced. Can you elaborate on the recommended way to do this given the future FC roadmap?

    Let's assume you have two types of customers (retail and wholesale) and you only want to have wholesale customers be able to use PO payment methods. Also assume this would be coming out of a MODx-based cart with logged in wholesale users.

    BTW, Brett, Luke et al: I'm very appreciative and excited by the 060 release. Thanks for you guys hard work and ongoing improvements. :)
  • Looks like Garry has a way he'll share in a few on the hiding the PO option when it's not allowed. More soon...
  • garryngarryn Member
    edited October 2009
    Looks like Garry has a way he'll share in a few on the hiding the PO option when it's not allowed
    And, here we go - it's a fairly simple solution :) Assuming that you are passing in a custom field with the transaction called show_po (with possible values of 'Y' or 'N'), then the following JS code will hide the PO payment method if required. The code needs to be added to your Checkout template.
    $(document).ready(function(){
    	  if (fc_json.custom_fields.show_po == 'N') {
      	    $('#fc_payment_method_purchase_order_container').hide();
    	  }
    });
    
  • brettbrett FoxyCart Team
    edited October 2009
    @garryn: That's exactly what I'd recommend. Worth noting though is that the HTML for a checkout with multiple payment options is slightly different (obviously, I suppose) than the HTML for a checkout with a single payment method. An extra ul/li/fieldset combo encloses the payment method options (and is shown/hidden) when multiple payment methods are present.

    Also perhaps worth noting is that you may need to set certain elements to show/hide based on what payment method you want to show, but for just hiding the PO you'll be fine, since the CC is selected by default.


    Update on the transaction/API issues: They're resolved now. Please continue to let us know any issues you discover, and thanks for finding everything so far.
  • oskayoskay Member
    edited October 2009
    We seem to be getting a number of "10419 Express Checkout PayerID is missing" errors. Any idea what might be causing this?

    Edit: We seem to have found a likely clue: Upon "completing" payment in PayPal, and trying to return to complete the payment, we're actually coming back to:
    https://[ourstorname.com]/[redacted, included a dev path that doesn't need to be spidered]?ThisAction=paypal_express_checkout&fcsid=[...]

    If it helps to locate the problem, this was observed after clicking the paypal button on the checkout screen, not the one in the cart.
  • brettbrett FoxyCart Team
    edited October 2009
    Hi Oskay. I'm editing your post to remove something "sensitive" (not really, it just doesn't need to be spidered).
    Sorry about the issue. Fixing now... please standby...

    Fixed. Thanks for pointing it out. We'd actually known about this but in fixing the other issue we'd neglected to push this fix out along with it.
  • >Fixed.

    Seems not to be. :(
  • A little more searching data here: Seems to be browser dependent. Testing right now on FF/Mac, Safari/Mac.

    FF catches the error, displays "Error: There was an error processing your payment: (10419 Express Checkout PayerID is missing.) Express Checkout PayerID is missing." on the checkout page, without heading to PayPal to enter information. This generates an error that shows up in the error log.

    Safari does not generate that error, and passes through to PayPal to collect data. It's only on return from PayPal that it redirects to the "bad" address that I mentioned earlier. This does not generate an error that shows up in the error log-- it just hangs.

    I can't seem to complete a purchase in either case.
Sign In or Register to comment.