We are currently (as is obvious from my last few posts) using a variant for Account number, which works well. The item we are offering is simply a payment on account, so the price is specified by the customer at the time that they are adding the product to the cart. However, it has been proving difficult for customers to figure this out. They enter the account number and click "Add to Cart", but do not change the price to reflect what they want to pay. The system then presents them with the "CONTINUE WITH FREE CHECKOUT" form and they happily submit a payment for $0.
I know I could set a minimum payment amount, but the suggested price jumps to whatever the minimum is set to, so I would expect to see a bunch of customers happily submitting payments for whatever the minimum payment is.
Is there a way that I can provide two fields on our page? Basically, I would like to have the customer enter their account number and the price before clicking "Add to Cart" and have the price information sent to e-junkie along with the account number.
Lest it be thought that I haven't bothered looking for answers on my own, I am aware that I must append "&amount=amount_you_want_to_pass"to the end of the url that is sent to e-junkie, but I am unsure how I would go about modifying the javascript to make this work.
OK, one more idea. Instead of using a variant with a modifiable price, could I just use a "Buy It Now" button for an item that has some bogus price defined in Admin (say, $0.01). Then, all I would need to do is build the button code when the form is submitted so that the normal button code for the buy it now button has the account number passed as &custom and the price passed as &amount. That would meet my needs quite well, seeing as it would eliminate the whole "Shopping Cart" metaphor, which is somewhat confusing, given that there is really no physical or downloadable product with a fixed price.
Have you enabled "Let buyers edit price" for that product? That setting is necessary to allow the price you set in Admin to be overridden. BTW, if you leave the "value" attribute for your "amount" field blank (value="") or omit that attribute entirely, that will leave that text field blank for your payers to fill in; whatever value you choose to put in there will "pre-fill" the field with that figure, which buyers could change to whatever amount they want to pay.
Another thing you can do is send billing emails to your payers with a link to pay their bill, in the form of a Buy Now button URL with the proper account/amount values appended to the URL, like so:
...strung on one long line together of course, altho' you can see this may be tricky to implement in practice if whatever software you are using to send the emails would break the URL into two lines, but as long as what originally gets sent has it all on one line, then I think it should get received that way as well.
BTW, if they try to be sneaky and manually edit the amount value in the URL or your text field to less than what they owe, then you could of course simply credit their account for whatever amount they actually paid and send them another billing request for the remainder. :^)
# POSTED ON: September 18, 2008 @ 12:10 GMT -7 MODIFIED ON: September 18, 2008 @ 12:14 GMT -7
Tyson_N...strung on one long line together of course, altho' you can see this may be tricky to implement in practice if whatever software you are using to send the emails would break the URL into two lines, but as long as what originally gets sent has it all on one line, then I think it should get received that way as well.
It's usually the e-mail reader which is "responsible" for breaking the long links .. so http://tinyurl.com/ might be a good solution in this case.
Well, I disabled the variable price because it does not allow the use of the buy it now button, which is one of the main points of what I am trying to do. Anyhow, I'll fiddle with it a bit more.
As for people paying less than they owe, that's not a concern, because this is just a "Payment on Account". If they fail to pay within their payment terms, then regular collections actions will ensue.
I do like the nice, easy e-mail links. I'll keep that in mind. Eventually we will be moving to a solution that will interact directly with our accounting software via SOAP, and actually post the payments to a customer's account, but I need a professional to do that.
OK, I re-re-re-setup a test product here, and this time I was able to get a Buy Now button with a variable price enabled. However, the form suggested does not seem to work. For example:
The form works as-is, but the price always shows up as whatever I set in the Admin interface as the minimum price, whether it is $5, $10, $0, or blank (which ends up as $0, anyway).
Your form should be working now.. basically, our CART code (it gets a little complex - Auth.Net and GC BUY NOW buttons are based on our CART, unlike PP Buy Now buttons, which are real buy now buttons) could have only handled passed amount as long as it was in the URL OR if you were using our CART BUTTONS with the box.js line in your page .. as in that case, box.js reads all the params and appends to the action in the form automatically.
Anyway, the form you've posted above (with POST) should work fine now as we have adjusted the code to handle this scenario.
If it does not, please paste the URL of the page where you have this form.
Thank you for the help! I thought I was going insane for a moment. Everything works as intended now, and is a much superior solution for our needs as compared to the shopping cart!
Also, FYI, your user shows up as "member" instead of "E-Junkie Crew", but it sounds like you are with E-junkie.
Lastly, there is no method to pass a Customer ID to Authorize.net, which means I cannot require that field in my authorize.net Payment Form settings. Is that something that could be added at a later date?
trymes
Also, FYI, your user shows up as "member" instead of "E-Junkie Crew", but it sounds like you are with E-junkie.
Yeah, I was testing something using that ID and did not bother logging in using the "official" id :)
trymes
Lastly, there is no method to pass a Customer ID to Authorize.net, which means I cannot require that field in my authorize.net Payment Form settings. Is that something that could be added at a later date?
Tom
If you are using our VARIANTS feature, you can simply rename one of the 3 text fields you are allowed to create to Customer ID
Actually, you would want to enable "Variations which tell more..." for your product, then you can name an option something like Customer ID and below that, leave the list of values for that option blank, which will alter the button code we provide to include a blank text field that buyers could fill in. You should be able to just copy the new INPUT tag from that code and insert that into the form code you've already been working on here.
Well, I was using the Variants feature, but that disables the "Buy Now" button code in the interface. Come to think of it, choosing to allow the user to change the price more often than not does the same in my experience.
Tyson, Do I read your post correctly to mean that I can continue to use the same URL that is currently in my form and just pass the "Customer ID" variable along with it, even though the standard interface doesn't present that option?
Yes, that is correct; the form code you have been working on should still work with the new Variations field added. I think they should even still work regardless of whether you save the product config with editable price enabled and/or the Variations option for your Cust. ID configured; you might need to save the Variations config in order for the option name/value to be recognized, if anything.
Designated trademarks and brands are the property of their respective owners.
Use of this Web site constitutes acceptance of the Terms of Service and Privacy Policy.
