1. Kayako Download customers: we will continue to develop and support Kayako Download beyond July 2017, alongside the new Kayako for existing customers.

    Find out more.

  2. The forum you are viewing relates to Kayako Classic. If you signed up or upgraded to the new Kayako (after the 4th July 2016), the information in this thread may not apply to you. You can visit the forums for the new Kayako here.

SupportPay For Fusion "Beta Testers Wanted"

Discussion in 'Apps and modifications' started by hamish, Apr 16, 2011.

  1. hamish

    hamish Established Member

    Hi folks

    We are now in the final stages of beta testing of SupportPay for Kayako Fusion Helpdesk,

    In case you are not aware SupportPay is a module that allows you to charge and collect payments for support calls. This can either be on a one off basis per ticket or minute or as part of a package.

    As with our V3 app we will be offering the following Features
    • Simple Installation
    • Supports many currencies
    • All Payments are automatic
    • Bill for both Tickets and Live Support
    • Track customer credit levels automatically
    • Sell 'Minutes', 'Tickets' or 'Packages'
    • Discounts
    • Clients can be their own Account Managers
    • Affiliate Bonuses for signing up others
    • Built-in reporting
    But with so many requests from our existing v3 customers we have also added some New features
    • Handle Tax Calculations
    • Regular Billing Agreements (Recurring Billing)
    • Pre-Approved Credit Card Payment
    • Startup Packages on a Per user Group
    We are now only awaiting 2 main bug fixes from kayako and we will be ready for release but in the meantime SupportPay for Fusion is ready for beta testing.

    Although we still consider the release as beta our tests have had very positive results and we hope that with the help of kayako on thier bugs and depenent on beta feedback we should be ready to release a production version very soon.

    In the meantime if you are interested in being part of the beta just submit a ticket at our helpdesk and will send you all the info.

    Please see the screenshots below for a taster of SupportPay for Fusion

    Staff screens
    User Credits
    [​IMG]This is one of the most important Staff screens. It lists each user plus how much credit they currently have, how many current affiliates they have signed up and whether on not they are an account manager.

    It also allows you to change their credit by adding or removing it, set their discount rate and manage their dependent users - that is, anyone who belongs to their account group.

    Add Credit
    The Add Credit screen is for making manual adjustments to your users' credit levels. You can add or remove minutes, tickets or packages from here. You can also set a price which will appear on their account history, in case you have received a payment outside the SupportPay.

    Staff View of Credit History

    Your staff can, of course, view a client's entire history of payments and use of credits.

    Staff Tickets Pending
    A list of open tickets, similar to the existing screen, but also showing each user's current credit rating.

    User screens
    Paid Ticket History

    The other side of the billing system is the list of payments from the account. This page, like the Payment History page, has the client's credit along with the purchase buttons and affiliate page link.
    The grid on this page shows any changes to the credit level of the account. This might be automatic payments for closed tickets or Live Support, or manual adjustments made by your staff. Any tickets or Live Support calls can be viewed by clicking the 'Subject' link.

    Payment History
    This is an important screen, showing lots of different things. First is the user's current credit. If this user had an Account Manager, their credit would automatically be added to the totals here. Next is a standard grid showing the most recent payments made by this user; in this case, one from PayPal and two payments and refunds from 2Checkout.
    Next is a small control with dates, which allow a client to print their own account statements at any time. After that, the purchase buttons (which can, of course, be customised), and a link to the Affiliate control page.

    User Widgets
    Very simply, this is the new front page with three additional widgets visible. Two are always there, allowing your clients to see what they have paid for and where their credit has been used. The third is only visible to Account Managers.
    A User Account Manager is designated by your Staff with a single click. After this, they can manage their own list of friends, family or colleagues for whom they are willing to pay bills. For example, one person at a company would be responsible for paying the bills of all of their department.
    One more widget can appear, showing that an Account Manager has offered to pay your bills. You then have the choice of whether or not to accept that offer.

    View Chat
    [​IMG]In the standard Fusion system, there is no way for a client to review old Live Support sessions even though they are stored. This new page, linked from the Payment pages, allows a client to review their old Live Support sessions.
  2. SteveLV702

    SteveLV702 Kayako Guru

    Ill beta test if still in need of some testers....
  3. hamish

    hamish Established Member

    Hi steve

    If you can send us a ticket on our helpdesk we will ping you back with all the relevant info
  4. nibb

    nibb Reputed Member

    I have 3 questions.

    How much will the final product costs?
    Will be change Kayako core files or is it a plug and play module? That means I can ugprade kayako just fine without affecting anything
    Can I do the billing outside it? Using kayako for billing is something I dont do and most companies dont. Most of us have their own account/client billing system. So it would not make sense that the client should pay in the Kayako module, as you could not track expenses and payments made. The solution would be simply with some kind of API that tells the module when an invoice was paid so the invoice in the module is marked as paid.
  5. hamish

    hamish Established Member

    Hi nibb

    As with our previous release we do not change core files so upgrades should not be a problem. I do understand that some companies do not use kayako directly for billing and for those there are ways that SupportPay can be used to allocate time to clients and manage support packages

    It is also an ideal with to make money day to day from work where there is not an existing support contract. whilst an api would seem ideal for integration with other billing solutons it would not be a simple thing and would distract us from what is our core product.

    As it is for business who sell there support services via the net SupporPay is a complete billing solution and with the automatic payments it now allows you to collect payments quickly without having to wait till end of the month and remember to add to an invoice
  6. nibb

    nibb Reputed Member

    I dont think you are seeing this from a company perspective side. You said SupportPay is for companies that want to bill support. Do you expect them to have a separated accounting just for support?

    Lets me an example. A company selling a service on the Internet as well with other products, has their own billing account and system where people log in for paying checking their invoices, accounts, etc. This also is integrated with accounting.

    Now you expect them to bill their clients separated for support?

    I can see all type of problems with this. First clients will ask why there was an extra charge on their CC card, because those support invoices are not showing in their account but are in Kayako.

    Then you will have people wondering why do they have to log in to another system to check support invoices and why they are not conciliated in their current invoices.

    They you have accounting having to pull invoices from another place and having to do an extra integration. Now if this model was for all softwares, clients would have an invoice for each thing in separated log in account. One invoice in one system for support, another one for their services, another one for this, for that. That just doesnt make sense. Companies and clients will have the invoices should up just in one place.

    I really like the features from this module, and the billing automation is great, for people not having any other current way to bill for support their customers. But sadly I dont think its an option for 99% of Kayako users that could be a potential buyer, companies. Most companies which are going to or already charge for support are already selling other products or services, so that means they are already sending out invoices.

    Having a complete separate billing and invoice system doesnt make sense and causes more support and confusing for both the client and the company.

    Dont get me wrong, the credits system, check invoices, etc, all this would still be in the module. The API of external integration could be extremely easy.

    If there is no API then manually marking invoices as paid in Kayako would do it.

    This way you could generated a support invoice or package in your current billing system, once paid, accounting could just log into this module and mark it as paid. So clients would not be actually paying with this module. This way they would still use their current invoice system

    Of course this would not be an option for bigger companies, and an API automated system would do it.

    You say its complicated and im really surprised by that.

    Loading a url in a browser is very easy, and thats all the API would would do. There are millions of paypal scripts or 2checkout scripts you can take as an example. All you do is execute a url to mark a invoice as paid on your module. All the API would do is "yes" or "no". The external integration of billing systems would rely on each company. Once an invoice is paid you would just load or send the client to that url to mark it as paid on your module and thats it.

    On your module instead of being send to PayPal for paying, you would just change the url to what ever billing system you are sending them to pay.

    I really like to buy this module but forcing users to use a complete different invoice and paying system its not an option. It would be a mess, once they find charges which are not on their accounts and having to explain them to log into Kayako to check this invoices in a complete separated account system would not make sense. At least I prefer an option to disallow payments from your module, sending them to another url (our own account system) and after payment was made then we could just go to your module and mark it as paid manually.
  7. hamish

    hamish Established Member

    Hi Nibb

    I am not the technical side of SupportPay so my colleague may also respond regarding the api, but before I say anything I highly advise you actually test out our software a little before making so many critisism's we do not have an API as we do not see it as commercially viable to provide this at the moment.

    We have focused on making SupportPay as complete as possible but we also give clients the Flexibility to configure however they want via an easy to use configuration screen to bypass our billing and payment system.

    The software can be configured very easily to push clients to alternative billing systems to buy packages, see invoices and pay for support, but by using a Seperate invoicing system it would require a suport staff member to add any balances to the account manually.

    Alternativly if you can find say 200 people who would require an api we would be more than happy to look at adding this to SupportPay..

    Hope this helps
  8. nibb

    nibb Reputed Member

    Well you should had started with that reply then initially since that was what I was asking, if it was possible to use our own billing system bypassing the one in the module. :)

    Criticisms isn't always bad, it allows companies and people to improve their product. It was just my opinion from a user perspective. I would test the product but I dont know how.
  9. jimkeir

    jimkeir Member


    Probably a little late responding but here goes anyway.

    The reason that the billing is done internally is so that we can have a single solution for the smaller companies who don't already have an external billing system. It's a one-shot package. Having said that, there is already integration for VirtueMart and WHCMS is being considered. It's perfectly possible to pull payments from another system, or to push credit used out if that's what's required. It would require a bit of coding to glue the systems together, and that would of course be different for each type of external payment system.

    You could handle it many different ways, depending on what you sold. You could add a package once a month, for example, which contained a fixed amount of credits or, for unlimited credit, gave specific clients 100% discount. You could add different packages depending on your requirements; say, "Gold", "Silver" and "Bronze" options with different numbers of tickets or minutes credit. The key, though, is that integration requires coding so it's not mentioned as part of the base product.
  10. ronilieberman

    ronilieberman New Member

    Are you still in beta? Do you have integration with Magento?

    Thank you in advance,


Share This Page