`processBundle` accepts certain params on sandbox but ignores them on production

The processBundle shopping cart interface for the production app seems to be ignoring fields which are accepted by the sandbox app: inf_field_FirstName, inf_field_LastName, inf_field_Company, and inf_field_City. Here are two links which differ only in the subdomain they point to:

(Note that if you test those out repeatedly, you may have to delete cookies for the relevant subdomain, since the shopping cart caches your information in cookies.)

Any idea why this would happen? Maybe something to do with the payment gateway enabled on production (but not sandbox)?

1 Like

Hi @Marvin_Humphrey I am not sure what exactly the difference is here… I would look at possibly using jquery or javascript to parse the url parameters and set the various field values. I know that in the past I have come across users that have written jquery to accomplish this. You will just need to add a small script to one of the “HTML Areas” of your shopping cart theme. Keep in mind though, that this may need to be maintained as future improvements happen.

If you are not bound to using our forms, an alternate way that I would feel more comfortable with would be to use the API to both query to retrieve the contact data and to place the order.


1 Like

Hi Carlos! For the sandbox app, the shopping cart behaves as expected. But for production, we get this:

Note the empty First Name, Last Name, Company Name, and City fields.

This has been reproduced on Windows 10 Home (version 1709) with MS Edge and on Mac OS 10.12.6 Sierra with both Firefox 58.0.1 and Chrome 63.0.3239.132. However, the bug did not manifest using Windows 10 and Chrome.

It seems like the argument handling of processBundle is haywire. (I speculate that the code to iterate the arguments is janky.) I had earlier problems with productOptions being ignored. But while productOptions is marked “legacy”, these other fields are fully part of the supported interface.

Parsing the query string is probably not a solution. For one thing, processBundle immediately redirects to showManageOrder, and it is certainly not part of the documented API that the query string will be passed along intact. (I’m not even sure that’s the current behavior.) Code written to depend on that implementation detail could break at any time.

As for performing a bunch of API calls to create an Order, I don’t think that makes sense because the Order object shouldn’t exist until the customer completes the check out process. Otherwise, aren’t we going to create a bunch of orphaned Order objects for people who decide not to follow through with the last “OK, place my order” click?

I appreciate the suggestions, but I really wish I could count on processBundle.

That is interesting… Give me a little while to look into it and I will update this thread with my findings.


I’m showing those fields populating on both?

This morning, I am also seeing the fields populating on both Mac/Firefox and Mac/Chrome. Perhaps @Carlos_Ochoa has made some progress? Or is this an intermittent Heisenbug?

One remaining quirk is that once the shopping cart thinks it has contact data (cached in your cookies), the contact data URL parameters to processBundle will be ignored on all subsequent requests. So if the end user, say, forgets the Zip and goes back to the form on the non-infusionsoft domain and then resubmits, the new value for inf_field_PostalCode will silently disappear and the “Zip Code” field in the shopping cart will remain blank.

However, that quirk is something I think I can live with. It seems to me that ordinarily, end users will not change up their contact information the way that I do during development. And once you update info using the shopping cart itself, it sticks – so the occasional odd case should be recoverable.

:expressionless: I suspect that this might be configuration changes? Not sure at the moment, as I had to step away from debugging. I know that there is a legacy cart and our current cart that may have something to do with this… I want to wait until after our next deployment to fully step through since there have been recent changes. @Marvin_Humphrey, I will create a ticket to follow up with you after the next deployment.

As of this moment, I have no idea what caused this.


A couple more things to consider: I’m wondering if the setting for not allowing a product to be ordered multiple times in a given period might block some things. Refreshing fields is possible after page load and it might be that the normal IS processes that manage the page are pre-empting the update? Spitballing on that but had a client where that was the case once.

Thanks Carlos, thanks John for looking into this Heisenbug. I will cross my fingers that it has disappeared for good.