36 / 43
Oct 2011

Perfect !!! Men, you have just saved a grand for me.... !!!!



Now third party integration codes can work smoothly on practically any self hosted wordpress installation. All i need to do is to code a notification url constructor in the plugin settings .



Example :



aweber (common notification list) + wordpress data treatment script + quick book integration = only one url to construct using multiple postto[]





THANKS !!!





PS BTW if the final user does not need to relay data to any other script than wordpress - the notification url constructor will output direct link to listening script eg :



http://store.creersitepro.com/data-treatment-page/



thus your servers will not be overloaded for nothing

question 9 - do i need to respond/send back to your data sending script? or i just exit execution once the data is treated in wordpress ?

8c2) -- solved , just finished the notification urls constructor script.



Features :



construct commmon notificatio url to use in e-junkie.com admin



aweber list is integrated (text input for aweber list name),



up to 3 additinal urls to receive data (3 text inputs for urls)



if no aweber list or additional urls - gives direct data treatment script url.



just tested - postto[$number]=$url works perfectly (got two accounts registered on 2 different sites with my plugin)



QUESTION :



sign @ in aweber is encoded into %40 by wordpress add_query_arg() function, will it still work in your o_plug.php script? (same for multiple e-mails)



example url constructed :



http://www.e-junkie.com/ecom/oplug.php?aweber=aweberlist%40aweber.com&postto[1]=http://store.creersitepro.com/data-treatment-page/&postto[2]=http://realestate.creersitepro.com/data/

So, as of today (2011/10/10) the beta version 0.0.7 of E-Junkie Store for WordPress is ready to provide basic functionalities :



Create Product Pages

Create Catalog of all Products

Receive and treat data from e-junkie.com to :

a) open client account for buyers in your wordpress site (automatically register user) and fill in their profile forms

b) register transaction in wp database

c) register order (printable) in your wp database

d) track buyer's purchases and orders, total spent amounts

e) automatically relay received data to external services such as ConsoliByte (integrate into QuickBooks software), Aweber, multiple e-mail notifications



No shortcodes stuff (simple boxes on edit product screen to paste add to cart/ buy now button codes) - thus the plugin will display the needed buttons itself accordigly to your store settings.



Some other user friendly features in the admin.



The current version of the plugin misses some "shiny painting" (comming soon) but is really simple to install and configurate to provide a solid wordpress/e-junkie solution to sell downloadable and "no-options" products (more functions are coming). Fully integrated in wordpress admin and as i know (I've spent a couple of years searching for this wordpress functionality) - is exactly what a regular small online business needs to integrate e-junkie store into wordpress site.



Now i need testers - if you are interested to get the beta of the plugin for free (it will be sold around 50 euros = 65 $USD later), you have exactly 21 day to contact me to get it.



You may reach me here :



serge liatko

Biarritz France

+33 (0)6 50 45 34 36



webdesign : http://creersitepro.com/

twitter: http://twitter.com/SergeLiatko/

facebook: http://facebook.com/serge.liatko/



get ready for 35% affiliate program for this plugin.



About the price of plugin development - the basic structure of the plugin was coded in around 20 days and payed by a client of mine as much as 1300 euros (so you may use it as a review argument for affiliate sells from your blog)



cheers,

serge



PS my aim is to split the market part taken by wp e commerce plugin (oh, boy, headache with their "templates" and post_meta fields as soon as one get out of a poorly coded theme)



PPS @e-junkie team : guys, any news on recurrent payment integration in e-junkie?

LOG:



current (0.0.9) version constructs Payment Variable Information URLs for individual items



supports :



Acutrack

TrepStar

SwiftCD



Aweber

Multiple E-mail Notifications

3rd Party Script data relay



here is the link to screenshot of how it looks in the admin on edit product screen :



http://creersitepro.com/wp-content/medias/2011/10/itempayment_variable_url_constructor.png

One thing to be aware of re: &postto=/&postto[]= URLs -- it cannot properly handle URLs that have their own &name=value query string parameters, since those would be interpreted as parameters on our o_plug.php URL itself. I've asked Development to consider whether we could support urlencoding such query strings (e.g. %3F for ?, %26 for &, %3D for =, etc.). Speaking of urlencoding, you could test that for the Aweber method by using your own email address, since that pre-integration method just sends the specified email address a subscribe-this-person email formatted to Aweber's requirements.



9) You should at least return a proper HTTP status (e.g. 200 OK) acknowledging the transmission; if the HTTP session just exits without any return status, or if it returns an HTTP 500-class server error status, we would email a notification about that to the seller's E-junkie Login Email. BTW, if the script should also return actual output for the buyer to receive, you can use our Send Generated Codes feature instead of Integration to have us forward that output to the buyer:

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



We really do appreciate your efforts in developing this plugin; as soon as you confirm it's ready for public release, we can link to your page (will you have a page in English available? :^) from the WordPress section of our sites/blogs help page:

http://www.e-junkie.com/ej/help.site-blog.htm#wordpress

Re: your inquiry about recurring payments, that matter is covered briefly here:

http://www.e-junkie.com/ej/faq.payment.recurring.htm



To expand on that, the main challenge with supporting such a feature is that presumably the buyer doesn't want to keep receiving the same download they got with their first payment, nor would any sellers want to provide that, and at present that's all we could actually do with notifications of each recurring payment.



Even if we added support for sending orders to checkout that would initiate a recurring payment plan, we have nothing built into our fulfillment system that could provide buyers and sellers with anything of value for those periodic payments -- e.g., tracking membership/subscriber status, administering access to a members-only system, scheduling periodic mailings/downloads, etc. In order to make support for recurring payments a useful feature, we'd need to develop all of those fulfillment features from scratch, without which support for recurring payments alone is only half a solution that's no solution at all.



While we do use PayPal Recurring Payments to manage subscriptions for the use of our own services, that isn't integrated with our cart or order-processing system at all. We just provide Subscribe buttons that help our sellers set up a payment schedule in their own PayPal account, telling PayPal to send us the same amount every month, so we just passively receive those payments to mark the seller's account as active for another month.

Thanks for your answer. Once the plug is done i'll get closer to this feature. As for now, i have just some ideas in that area (not sure that be a kind of helpful for you) :



what we have :



Seller (willing to sell subscriptions)



Buyer (willing to get subscribed and ready to pay reccurent fees)



Subscription (as a product type, totally independant from any other product types you support for the moment) - subscription itself has the value only if payment data is treated as it should be : means seller is capable to receive successful payment notifications to start/update buyer's account, and update/suspend buyer's account if the recurrent payment failed (can you manage failed payment notifications?)



Product/ url notification managment system - E-junkie



Payment systems supporting recurrent payments and sending notifications to E-junkie on success/failure ( like PayPal or if there are any others)



Seller's script capable to receive/treat data from e-junkie and fulfill actions on different type of notifications (eg open an account for buyer, update buyer's status on payment failure etc)





If we take the example of paypal -



would be nice to have "subscription" as a new e-junkie product type with item number generated especially for subscriptions (thus you separate products and subscriptions)



the button type you may provide for sellers would be "subscribe" (configured from within e-junkie admin) acting pretty much as buy now button (no add to cart) and redirecting to the checkout page (paypal recurrent payment checkout)



where you include subscription item number to paypal, so that it sends data to your script.



your script (you will sertainly need a separate listening script for subscriptions) will treat and translate the data received from paypal - then send translated data to seller's script



seller's script will take actions accordingly the data received from you. No feed back.



Once done, next step is to create the "unsubscribe" button... or may be it would be wise to develop them in the same time.



Actually this can be done without bothering e-junkie, with paypal only. But their "handshake" (sending data back and forward to confirm it comes from paypal) is too complicated for average website owner. Your "handshake" can be managed easily, and thus can be implemented on a bigger amount of websites. So recurrent payment feature managed by e-junkie would be so much easier to integrate into wordpress or other CMS.

Forgotten to mention your affiliate programm feature.



This is the most important point of why I would like to see a "subscribe" button done by e-junkie team !

There's an approach you may wish to experiment with; we really haven't tested it yet ourselves, though in theory I think it could possibly work: Combine PayPal's own Recurring Payments solution as-is with our method for fulfilling eBay sales:

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



That is, if you can set up a Subscribe button from PayPal Recurring Payments with the exact, same Item Name as a product in E-junkie Seller Admin, and you also set up PayPal IPN with our URL for externally-generated sales (https://www.e-junkie.com/ecom/ipnext.php), I think our system should process a sale for that product every time we receive IPN confirming each recurring payment for the matching Item Name.



E.g., if the product is set up with a file download, we should issue another link to download a copy of whatever file is uploaded for that product, so if the seller adheres rigorously to a schedule for replacing the uploaded file for the product, buyers should get periodic download links for the product's current file; if custom/3rd-party Integration is set up for the product, we would POST the order data to the specified URL(s), etc.

E-junkieGuruOne thing to be aware of re: &postto=/&postto[]= URLs -- it cannot properly handle URLs that have their own &name=value query string parameters, since those would be interpreted as parameters on our o_plug.php URL itself. I've asked Development to consider whether we could support urlencoding such query strings (e.g. %3F for ?, %26 for &, %3D for =, etc.). Speaking of urlencoding, you could test that for the Aweber method by using your own email address, since that pre-integration method just sends the specified email address a subscribe-this-person email formatted to Aweber's requirements.





that's why i disabled 3rd parties if TrepStar is used... yes, urlencoded links support would be great on postto . Note, this needs supporting both urlencoded and raw links (raw links without parameters) as manually typed links are still in use.

E-junkieGuru9) You should at least return a proper HTTP status (e.g. 200 OK) acknowledging the transmission; if the HTTP session just exits without any return status, or if it returns an HTTP 500-class server error status, we would email a notification about that to the seller's E-junkie Login Email. BTW, if the script should also return actual output for the buyer to receive, you can use our Send Generated Codes feature instead of Integration to have us forward that output to the buyer:

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





Ok , got it i will look how to code it in wp. As for the codes, for the instance the plug is working (tested) with "no options" products and does not posess the keygen feature. As soon as i be at this point of development, i will look on it closer.

E-junkieGuruWe really do appreciate your efforts in developing this plugin; as soon as you confirm it's ready for public release, we can link to your page (will you have a page in English available? :^) from the WordPress section of our sites/blogs help page:

http://www.e-junkie.com/ej/help.site-blog.htm#wordpress





Thanks, that would be greate. The plug will be sold for about 60 USD and will have a dedicated support site. Yes the primary languale for the plug is english, personally i can provide support in russian or french, but that seems to be useless as frenchy are not good payers and russians are prohibited from using paypal to receive payments... lol



thus we could interchange our affiliate links ( i paste reseller link in the plugin core and you on your wp page :wink:) ) , kidding.



Certainly, all your team will have it for free as well as access to the support site (no kidding this time).

BTW great big thanks to all the team here and to Keith from consolibyte.com for support and clearance of a lot of questions.

28 days later
1 month later

ANOTHER IMPORTANT QUESTION



Hi, yesterday I talked to my accountant (french tax laws are awesome :frowning: )



So the request is :



Plugin, in order to simplify management uses mostly common notification URL to receive data from e-junkie, but there is some tax info missing in the ITEM SPECIFIC section :



current data :



Item Specific IPN Data

Here, X represents the position of each item in the buyer's cart:



item_nameX

item_numberX - item number you have set in product configuration

quantityX - quantity sold

mc_gross_X - sale price for this product * quantity sold

option_name1_X - (if applicable) if you are using any options with your products, then this will contain first option's name

option_selection1_X - (if applicable) if you are using any options with your products, then this will contain first option's value that buyer selected

option_name2_X

option_selection2_X

option_name3_X

option_selection3_X





needs to be :



Item Specific IPN Data

Here, X represents the position of each item in the buyer's cart:



item_nameX

item_numberX - item number you have set in product configuration

quantityX - quantity sold

mc_gross_X - sale price for this product * quantity sold



tax_X - tax amount for this product * quantity sold (some products may have different tax rate) and in some countries (france) this information is a must on the bill sheet



option_name1_X - (if applicable) if you are using any options with your products, then this will contain first option's name

option_selection1_X - (if applicable) if you are using any options with your products, then this will contain first option's value that buyer selected

option_name2_X

option_selection2_X

option_name3_X

option_selection3_X



also, it would be so genius to include :



affiliate_fee_X into the data sent to common notification URL - thus the final user would skip the whole process of setting up Product specific notification URLs just to track the affiliate share.



I do understand this request asks more coding from the e-junkie team, but I'm also sure this kind of amelioration of the data send would improve your service quality.



thanks guys

Serge, just letting you know I've asked Development to consider your concerns and requests re: IPN/Integration variables.



Offhand, I'm not sure if we pass an item-specific tax breakdown to PayPal that they would pass back to us in IPN, which we would then passthru to Integration URLs, vs. if we only pass them a lump-sum tax. This may actually have changed recently now that we support their tax/shipping recalculation feature. Also, since affiliate shares are all calculated as item-specific now, it seems reasonable to include those in our Integration POSTs if feasible.

Thanks for supporting me on that, I stay tuned.



The affiliate_fee_X would be really greate!