What information would your form require the buyer to enter? If it's only a few fields/menus, our Variations and Variants features can be used to add up to 3 text fields and 3 menus to your Add to Cart button code:

http://www.e-junkie.com/ej/help.variants.htm



That would probably be far simpler and more reliable than redirecting buyers to a form after checkout; once payment is completed, the values from those fields/menus could be transmitted back to a script at your end, along with all the other order details (such as the buyer's name, email, Transaction ID, shipping address if relevant, etc.), via our custom/3rd-party Integration method, which we regard as the only reliable way of transmitting order details back to your end for custom processing needs after payment is completed:

http://www.e-junkie.com/ej/help.integration.htm



If you redirect buyers to a custom URL after checkout, we do append some order details to your redirection URL, but this is really only intended for your page to use those details in dynamic generation of page output; for various reasons it's not considered a reliable method of transmitting order details to your system:

http://www.e-junkie.com/ej/help.redirection.htm



The only way to have a product both redirect the buyer to a custom URL and also issue a download link would be to create a product that bundles two separate redirection and download products, but this would provide both the redirection and download links together at the same time on the same E-junkie-generated thank-you page, rather than sequentially as you require, and bundle products also cannot engage PDF Stamping, which only works with Single File Download products.



You could sell the PDF as a Single File Download product and also redirect all buyers to a custom thank-you page URL regardless of the item(s) purchased, but buyers would be able to access this page as soon as they finish checkout, regardless of their final payment status (payment processors sometimes take longer to complete a payment than it takes for the buyer to finish checkout). You could use custom scripting in your site's thank-you page to embed E-junkie-generated thank-you page content (including download links) in an iframe within that page, or just display a link to the download page, as explained here:

http://www.e-junkie.com/ej/tips.redirection.download-link.htm



Some checkout methods (PayPal and Google Checkout in particular) do not auto-redirect buyers to any thank-you page after they finish checkout, instead providing a Complete Purchase link which the buyer must click-through to reach the thank-you page. Once we receive confirmation that a payment is completed, we send the buyer a thank-you email message with a link to reach their thank-you/download page in case they did not proceed to that page after checkout.



The Transaction ID format (&t= value) varies according to checkout method. For PayPal checkouts, it's just identical to the seller's Transaction ID generated by PayPal for the payment; for other checkout methods, we add a prefix indicating which method, followed by the Transaction ID generated by the payment processor/gateway (gc- for Google Checkout, au- for Authorize.net, 2co- for 2checkout, cb- for ClickBank, tp- for TrialPay, jg- for E-junkie Free Checkout, j- for free download links). The &c= value is a hash of your E-junkie Client ID, and is thus the same for all your thank-you page URLs. The &d= value indicates which item in that transaction the thank-you page should be generated for, and is thus the same for all downloads of that item; omitting the &d= parameter would generate a consolidated thank-you page for all items in that transaction.

The IFRAME would be used to display our thank-you page content (including download links) within your site's thank-you page; if you wish, the scripting in your page could just write out the HTML for a regular link to the download page, instead of writing out the HTML code for the IFRAME. The general approach you described with the URL you picked out from the example should work. :^)

Whenever we redirect a buyer to a custom URL, those other parameters are always appended at the end of the URL in a GET query string, as documented on our Redirection help page:

http://www.e-junkie.com/ej/help.redirection.htm



The scripting in your page should be able to pluck any arbitrary GET value(s) from the page URL's query string, while ignoring any other parameters in that URL; you can examine the PHP and JavaScript examples on the IFRAME page I linked previously to see how those scripts accomplished that for the 'txn_id' value.



The Transaction ID value gets passed with either the &t= or &txn_id= variable, depending on which URL it's being passed to and for what purpose. The &txn_id= variable name is more self-apparent in its meaning, and is thus generally used when sellers may need to manipulate it somehow, e.g. with custom scripting. The URLs for the default thank-you pages we generate use the &t= variable; that value is really only used for internal reference when we generate the page, so we don't expect anyone else to need to decipher it, and that function was also one of the earliest aspects of our system ever built, so we don't try to fix what isn't broken just for the sake of clearer syntactical semantics.

If you'd like to hire a developer to assist with the programming needed, we can recommend the competent, E-junkie-experienced developers for hire are listed in our directory here:

http://www.e-junkie.com/ej/developer-directory.htm



However, by using a "hosted" solution such as E-junkie, where we manage the software on our servers and you subscribe to use that software as a service (SaaS) in your pages, your buyers' information would necessarily be shared with us and stored in our database, and the details of every order are transmitted to the payment processor (e.g. PayPal) and back to us again in order to process their checkout payment. Of course, we and the payment processor only use this information to provide our services to you and your buyers, and we do not otherwise share or use your buyers' information for any other purpose.



If you require the utmost, absolute confidentiality of your buyers' data, then you would need to install software on your own server (whether it's fully-custom programming or an off-the-shelf solution like Magento), set up a database there to store that information, and install an SSL encryption certificate for your domain to ensure secure transmission of sensitive data between your server and the user's browser, so your own server would handle everything as a fully self-contained system. Even so, if you are accepting any online payment, at least the buyer's name, credit card account details, and billing address would need to be transmitted to a payment gateway service to authorize their payment.



I'm not sure I follow what you mean about cookies. A cookie is basically just a text file that stores a persistent name=value variable in a user's browser for a set period of time, so the server which sets a cookie can read or update that cookie later as the user moves from page to page, leaves the site and returns later, etc. Cookies must be set for a specific domain name and can only be read by pages/scripts hosted on that same domain. You may be interested in this help page covering how cookie-based tracking works:

http://www.e-junkie.com/ej/faq.tracking-how-why.htm

Since ours is a centrally-managed system shared in common among all merchants who use us, it's not generally possible to alter how our system works for any one merchant without also applying the same alteration system-wide to everyone, unless there's a setting to manage that as a custom preference in Seller Admin.



Tracking cookies do not work the way you seem to think they do. A cookie is not software nor any sort of script that can do anything by itself, and they certainly cannot be used to monitor the URLs a user visits which are entirely unrelated to the site which originally set the cookie.



A cookie is just a plain text file that stores a name=value pair in the user's browser for a set period of time. A cookie must be set by and for a specific domain name and can only be read by pages on the same domain. The way Internet tracking basically works, a script in a page sets a cookie in the user's browser, and other pages on the same site may have a script that can look for that cookie in the user's browser, as the user moves from page to page on that site.



It's a bit unfortunate the inventor chose the term "cookie" for this, when he might have picked a term from a more familiar and suitable analogy. Setting and tracking a cookie is really rather like getting a ticket stub at some event, where your stub and the other half of the ticket each have a set of matching numbers. While attending that event, you might be asked show your stub on demand to claim a doorprize or complimentary drink, or to otherwise prove you're the same person who gained admittance at the door.



Extending the metaphor, now imagine that you are asked for the stub every time you enter a new room at the venue, and the doorman in each room logs which ticket numbers entered which rooms when; in that way, the hosts could anonymously track the movement of each specific ticket number through their venue and figure out generally where people generally went, and when, and in what sequence, even without knowing exactly who has each number. However, if you provided some personal information to the event hosts by writing it on their half of the ticket (e.g., to enter a doorprize drawing), the stub you keep and show to the doormen only has the ticket number, which cannot be tracked back to you personally without matching its number to the host's half of the ticket which has the personal info you wrote on it.



The tracking script (doorman) on each page (room) just requests the tracking cookie ID (ticket stub number) from the user, or sets a cookie (issues a stub) if they don't have one, and tells the tracking service such as Google Analytics (the event organizers) to log that ID as having visited that page URL (room). Tracking just "follows the bouncing cookie" as the buyer goes from page to page on that site.



This gets a bit more complicated when the site's pages embed third-party advertising and tracking scripts in their pages. E.g., suppose you're visiting Site A, and the pages on that site are displaying advertising served from Site B. Those ads from Site B may have scripts that can set and read their their own cookies for Site B's domain, but the pages on Site A cannot read those cookies. However, if another Site C also displays advertising served from Site B, the scripts in those ads can read the cookies that Site B had set on Site A, allowing Site B to know that the same user viewed their ads on both Site A and Site C. While you're viewing Site A or Site C, the cookies that Site B sets or reads would be considered "third-party" cookies (since they're not set by you personally nor the site you're on); most browsers now have a setting to block these, and these would also be the type of cookies that your anti-malware software finds and offers to delete for you.

While it may be possible to use CSS to hide the download link in our thank-you pages, that would always hide the download link; there's no way to only hide it when the buyer arrives there after checkout but then have it displayed again when you provide them a link to that page later. The only way to prevent buyers from accessing the download immediately following checkout would be to redirect them to a custom thank-you page URL, which would have all the GET parameters we've discussed.



That said, a privacy policy really only covers what you promise to do with data that the user has provided to you -- e.g., what purpose(s) you will use it for, who else you will share it with, how you will store it and for how long, etc. You can't be held nor hold yourself responsible for factors outside your reasonable control, such as malicious software installed on the buyer's computer or any computer they may be borrowing, upstream network resources they may be connecting through, etc.

You can use the div.item_info_by_ej CSS selector to pick the line(s) on our thank-you page with the "Click Here" download link and do what you wish with it in CSS or jQuery -- e.g., this CSS would completely hide that line:



div.item_info_by_ej {display:none;}



However, I'm not really sure if it's even possible to hide that line when the buyer arrives there after checkout and yet still display it when the buyer views it through an IFRAME in your page.



If you'd like some help setting things up, we can recommend the competent, E-junkie-experienced developers for hire listed in our directory here:

http://www.e-junkie.com/ej/developer-directory.htm

You should be able to use https://www.fatfreecartpro.com/ecom/rp.php?noredirect=true&clientid=198715&txn_id=IDGOESHERE as your site's link to the download page. You could use some custom javascript (maybe easier with jQuery?) to display the hidden link once the buyer has performed some required action on your page, eliminating the need for any scrolling/overflow trickery.