buyer code contact data feature field generated including info information integration issue list order perhaps product program provided purchased script send stored text url variable

Hello Everybody,

We have configured our ejunkie product to send order information to a URL on our server. One of the variables that we are extracting is the "key" field. We have generated codes configured in our product, so our understanding is that this field will be populated with this code. We tested it out and the code is there, however, we noticed that there is additional information in this field. In particular, the "key" variable has "Registered Name:" in there. Is there a field that can be sent to us that just contains the generated code with out the additional information? Thanks!

Our Send Generated Codes feature simply sends the raw text output that your keygen script provides when we hit its URL, so if your keygen is including a "Registered Name:" field in its output along with the code itself, that's what we'd provide to the buyer and to your Integration URL. The only way to eliminate that would be to modify your keygen script so it outputs only the code alone; otherwise, perhaps you could modify your Integration script to parse out the "Registered Name:" component of that field value and keep only the code itself.

Hi. I'm brand new to e-Junkie and just getting things set up.

I'm having the same problem as above, and using the E-Junkie code generator.

Is there a way to turn off the Registered Name field?

I'm not sure what you mean about an "E-Junkie code generator"?

We do host a keygen script for Silicon Realms' SoftwarePassport/Armadillo software-locking solution, so if you're using that solution to lock your software download, you should contact Silicon Realms for any tips you may require to configure their keygen script properly.

If you aren't using that locking solution, then the keygen script we host that's designed to work with it probably isn't the best thing to use. If you're not using a solution that already comes with a keygen script you'd be required to use, in that case you'd probably do best to use Send Stored Codes instead:
http://www.e-junkie.com/ej/help.selling-codes.htm

I am experiencing the same issue. According to the documentation there isn't even a 'registered_name' POST variable in the list. Why is it sending that along with the auto generated key in the 'key' POST variable? Can't you just go in and check the code to make sure there isn't some variable concatenation going on?

Yeah, I have no idea where it comes from either, and the Silicon Realms site makes no sense.

So I wrote a fragile little parser and moved on.

Our Send Generated Codes feature just accepts in full whatever raw text output the keygen script generates in response to our POSTing order data to it. ALL of that output gets forwarded as-is to the buyer as their purchased Code, and ALL of that output is included as-is within the value for the 'key' variable that we can POST to your Integration URL.

If the script outputs a "registered name" along with the actual key string, that's part of the script's design and part of the VALUE for 'key' that we can pass along as-is to you and the buyer; it's not a separate variable of its own and not a matter of what data we POSTed to the keygen script nor how we can POST data back to you afterwards.

The Armadillo/SoftwarePassport keygen script we host may output a "registered name" along with its actual key string by design, as programmed by Silicon Realms to work with their proprietary software locking solution. We did not program that script and cannot modify it; we simply host the keygen script they provided to us and let that operate as-is, as a courtesy to sellers who have pre-locked their software download files with Armadillo or Software Passport.

That makes sense. Thank you for your reply. I think we're confused because the documentation doesn't explain that. It just reads like each variable will be output as seperate variables. Anyway, we will parse out the extra info and move along. Thanks again!