1 / 11
Oct 2009

I am not yet a customer, before I sign up, I have a question:



I am a musician, I have a new album out soon. I will be taking "pre-orders" before the release date for the CD. This is very easy to do as customer addresses will be sent to me by paypal, which I can store until the release date.



I would like to take pre-orders for mp3 downloads, and use e-junkie to facilitate my download sales.



Is it possible that the order/payment could be taken by you, but the delivery of the file be delayed until a set date?



If not, is there a way to do it manually? E.g. create an item/buy-now-button for the preorder, store the customers email addresses, ejunkie then emails all customers on the specified date with the download link?

  • created

    Oct '09
  • last reply

    Jul '12
  • 10

    replies

  • 1.5k

    views

  • 6

    users

  • 3

    links

You can setup a product with no download or shipping options checked and use that to accept payments.



Once you release the album, you can create a product and send that out as an update to all the buyers who'd purchased the pre-order product.

Thanks for replying.



Can you tell me more about these "updates": will the email received by customers work exactly as if I'd sold them a download? Including unique links for security of the product, etc?



Looking here:

1http://www.e-junkie.com/ej/help.updates.htm1

it implies e-junkie would charge me a fee for sending out these updates.



With paypal as I use it now, I have access to all my customer's email addresses: I would not be happy to lose this by joining e-junkie.

You do have access to all your customers' email addresses with us, which does not require you to use (and pay for) our Updates/Newsletter service. All customer data (including names and emails) are saved in your E-junkie Transaction Log, and you can view/edit/export export your Buyer Group lists from here:

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



We do charge a nominal fee for our Updates/Newsletter service (this is our only service which is not a standard feature included in your monthly subscription), to cover our costs for the spike in additional overhead required to send mass emails and serve a flurry of free downloads for you. The amount will be calculated automatically based on your actual need/usage for that service, and you will be given the choice to either decline and cancel or accept and proceed.



Links issued via our Updates feature would work the same as if you'd issued each person a free link manually via Seller Admin > "Send free download link". These links would be unique for each person and expire after the hours/attempts you defined for the product, but we would not process these like an actual checkout sale (e.g., no buyer data would be saved to your Transaction Log or sent to a Product Variable Information URL), although all free links you issue are logged in Admin > Free Downloads Log.

That sounds ideal. The downloads will be about $9, so I can swallow $0.02 per customer.



Thanks for all the advice.



Jon

1 year later

Building off the above scenario, I would be selling a personalized video product online.



I understand I would set up the sale with no download or shipping options and set up the payment to be approved manually in PayPal until I the product was created and I was ready to process the order for electronic delivery to the customer.



My question is regarding the updates. Each customer would receive a unique product so it sounds as if I would need to create a new buyer group for each customer update and then send that customer a unique update link for their specific personal video download at a cost of $1 from e-junkie. Would this process be the solution or is there another option as I would prefer not to set up a buyer group for each customer?

Actually, I'm afraid you would not want to use our file delivery feature to handle the sale of personalized or otherwise unique downloads.



You'll need to handle the file delivery of unique files by other means outside of our cart, but at least you face a much lower risk of file sharing when each file is personalized to each buyer's needs.



And if you are handling the distribution of your personalized files outside of our system, there's nothing our Update service can do for you. Like our normal file delivery feature, it would only be helpful if you had one file to distribute to a lot of people rather than a lot of individual files.

1 year later

I'd like to look into something about this. I aim to sell a game which could be quite large in size, for that reason I've considered buying a package where I can host it elsewhere.



This game intends to have a pre-order, and then of course and actual product file product, sent to the pre-order customers as stated above, using updates.



But the updates help page states you cannot send updates if the file is hosted elsewhere.



Can you explain to me why that is, why there is such a limitation? The help files suggest that e-junkie create a 'copy' of the remote hosted file and just sends the customers that cached version, so why does it become not possible to link updates to remote hosted files?



Or have I interpreted "Remote Product File URL." incorrectly? Many thanks.

I've asked Development about this, and they can't remember the original reasoning why we don't allow sending Updates for products that use a Remote Product File URL. It could be that the original reason for that has become moot by now, with the upgrades applied to our system since that limitation was put in place, so we're looking into whether the limitation is still necessary.



That said, if your file is under 500 MB in size, you should be able to upload that in the product's settings and temporarily remove the Remote Product File URL when you send out the Update. Our cheapest plan that allows Remotely Hosted Downloads also includes 500 MB of upload space, so if you're using Remote File URLs for all your products, you should have the full 500 MB of upload space available to you. Once the Update is sent and everyone has had a chance to claim their free download for that, you can edit the product and re-add the Remote Product File URL, and if you wish use the Overwrite Product File button to Delete the uploaded file and reclaim that upload space.

Thanks Guru, and for checking with your peeps. Gotta admit it's a little frustrating, because the next reasonable package for my needs is $100 more than the first option allowing for remote file hosting (the price jump is massive, for 500 - 750 mb folks like myself- it's the ejunkie grey area). I'd have thought that, because I still pay for the update mails going out, it could still accept the remote file URL. I plan to have several, maybe many products running through ejunkie, and economically it makes sense to host the more massive files elsewhere - so ideally I don't want to be deleting products to make way for more and have updates work for some things and not others, but I see what you're saying. Guess I'll have to lump it, and jiggle around what's hosted on ejunkie at the time of updates and what isn't. There are sneaky ways to unlock "ejunkie achievement" that I've picked up in other threads and I DO see how you're describing the workaround could work... So that isn't necessarily a problem, providing I can get my head around just how to do it :slight_smile: But perhaps your devs could open that area up for remote paying customers? Or no? I realize you probably want to sell more hosting space, but you could always run a stricter limit on number of products in such circumstances, I'd certainly be happy with that. Cheers!

It would probably be easiest and most economical in the long run to just host all your download files remotely, and delete the files uploaded to us for each product, so you would have the full 500 MB of upload space available to you for sending Updates up to 500 MB in size, without having to upgrade to a larger plan with more space.



We are looking into whether the restriction on sending Updates for remotely-hosted files is still relevant with our current provisions, so if we conclude it's a moot point, we may well remove that restriction.