Merchant Tools – Variable prices

Front Page Forums Webmasters Merchant Tools – Variable prices

This topic contains 5 replies, has 2 voices, and was last updated by  James Bachini 12 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • #6147 Reply


    I’m currently developing a link exchange website where webmasters could register their links for free.
    The main service will be free forever, however, I was thinking about adding some premium services. No intend to make profit with the website, but would be nice to be able to break even after a while.

    I really believe in JSECoin and as my target audience is webmasters.. my idea was to make JSE the currency on the website. This will promote JSECoin and gives webmasters something they could spend JSE’s, which also adds value to JSE. (the more you could do with JSE, the more value the coin gets)

    I looked at the merchant tools, and I think they are a bit limited. My idea is that I give some bonus JSE’s once someone submits a link and for clicks they generate from their site to other sites in the system. These bonus coins could only be spend on the website and not be withdrawn.
    So once someone wants to buy a premium service, it would be possible that part of it will be bought with bonus coins, and the rest with real JSE’s. This would mean that the actual price varies and this doesn’t seem to be possible with the Merchant Tools in which a fixed price is set. I looked at the “Merchant Payment Request” and that seems to be close to what I have in mind.. However, I think it is only supposed to be for on the platform, not to be used on websites.. Will such a feature become available for websites? Or am I allowed to reverse engineer the “Merchant Payment Request” form and try to come up with my own code? (if it turns out that it might be usefull for others I could share the code if allowed)

    I’m in no hurry as the site is still in development and premium services won’t make sense before the site is up and running with sufficient links and views.. but would like to know my options so that I could take them in mind during the development.

    #6148 Reply


    Hi Rob,

    Here’s a quick demo script I knocked up which changes the price in the link and generates a new button automatically:-

    Source code at:

    It’s pretty basic but is that the kind of thing you wanted?

    One consideration is that you’d also need to deduct the bonus tokens from their account. I’d use the C1-3 custom variables for that (in advanced options on the merchant page). Dynamically insert the number of bonus tokens as well. Pass it through in the link and then call back another script on your site that deducts the bonus tokens using either the IPN or completion URL.

    So use c1 for their userID or reference and then c2 for bonus tokens amount for example then have the completion URL as something like:-{c1}&deductBonusTokens={c2}


    If that’s not what what you wanted then you are welcome to use the payment request function. I have put the source here:

    Hope that helps.


    #6149 Reply


    Hi James,

    Thanks, that should work.

    Just thinking out loud.. would this be a safe or very easy for malicious users to come around? Probably best to add the obfuscate url data part to make it harder for people to come up with their own prices.

    Would it be an idea to add some kind of “create payment request” functionality to the API in the future? With a server side API call a website could send all data needed for the payment request to the API, and the API returns an unique payment URL (with a hash or something) to which we could send the user to pay. The payment system matches the hash with the prevously supplied payment details from the API call and uses that for the price, the return URL, parameters to return, etc. And then maybe API functionality to check/validate the payment.


    #6154 Reply


    Hi Rob,

    Yes because the url is generated on the fly a user could manipulate the price. The obfuscation function helps but doesn’t solve the issue completely as a user could reverse engineer the code. You can use the IPN URL which is private and called from our servers on completion to send data such as price at checkout back to your internal functions.

    The reason we do it this way is because we are trying to avoid storing button or product data on the system. If we had an API we would need to store the item/button and give it a hash to send back, then look it up on checkout. If we tried to do it without storing the data privately via encryption I think it could always be reverse engineered if a malicious user wanted to go to that trouble.

    It’s a compromise and not perfect but the idea is to make it as simple as possible for merchants to accept crypto payments. The tools are also a work in progress and there’s lots we would like to do when we have more time and resources after the ICO.

    #6168 Reply


    Hi James,

    Thanks for clarification. Have never used payment processing before, so am still learning 🙂
    The IPN URL indeed seems to be the part I was missing.

    So this is how I could make it as secure as possible:

    • I create an unique payment reference in my database with payment amount, purchased item, etc.
    • I include my unique payment reference as a tracking variable and the IPN URL in the payment URL for the user.
    • The user goes to the payment URL on the JSE Platform and completes the payment.
    • Once the payment is processed on the JSE Platform, it calls the IPN URL (server side) with details on the payment, and sends the user to the completion URL
    • The script I make on the IPN URL simply uses the unique reference which I provided as a tracking variable to settle the payment in my database and activates the premium service if it was paid in full.
    • The completion URL also contains the unique reference, and once the user gets there it will lookup if the settlement was succesful or not. And show them they succesfully purchased the premium service and that it has been activated.. or.. if they modified the price, the settlement is unsuccesfull, and I could show them a messgae like “Nice try, but here is a link where you could pay the rest :)”
    #6169 Reply

    James Bachini

    Yep that’ll work.

    Basically you are taking the data from your site, sending it to the checkout and JSE server via the button link, the user is then returned to your URL.

    IPN URL is called privately so noone will see the data and it will come from our internal servers rather than the users browser.

    If you want me to take a look at your code or URL I can, just drop me a message on Discord or Telegram or via the contact form:

Viewing 6 posts - 1 through 6 (of 6 total)
Reply To: Merchant Tools – Variable prices
Your information: