I’d like to use the webhooks feature to notify me of events that happen automatically within Quickfile. For instance a new transaction imported on the bank feed or a new receipt in the Receipt Hub. Are there any plans for these to be implemented?
There aren’t any plans to extend the webhooks at this moment in time, although we’re always open to suggestions. As with any feature, if the demand is there then we’re happy to take a look and evaluate the work involved in implementing them
Webhooks are generally available:
There’s a list of supported events here:
At the moment there’s no support for bank feed imports or new receipts. Some events are difficult for us to implement without making webhooks too chatty. We need to be careful how many http requests we make as it can choke our servers. Things like bank imports can be done in the hundreds, that said we can (and do) batch hooks together but with the banking side this is a little more tricky to get right.
Right now I would say if there’s broader demand for this we’ll consider how this could be done.
I’m still after a way to be notified of invoice payment via webhooks where the invoice was paid via bank transfer. Having webhooks containing bank data might help me create a workaround to the lack of a full payment notification webhook.
So I’d add tenuous support for this!
Ultimately I’d say it’s a banks job to provide an api/webhooks for bank data (which I wish they’d get on with). If you implement a feed of bank data via QF it feels more like the kind of functionality offered by messaging applications like BizTalk.
Firstly, we’d love to integrate more with banks, but there’s not much of an option with the banks to be able to do it - not automatically anyway. Unfortunately there is no way to integrate directly to them and requires a human input at some point (like a pin code for example from a handheld device). So at this moment in time I don’t believe automated notification from banks are possible.
In terms of payment notification, you can get notified via webhooks for an invoice being marked as paid. If this is done online via QuickFile, this would be pretty damn close to instant as we feed from webhooks from GoCardless etc. That would at least cover you in terms of cards, direct debit and PayPal.
Hope that helps
Here’s details on the paid notification:
Thanks for your reply and you are right, there is no sensible way to integrate bank data currently. The chancellor last year suggested banks should look into providing APIs for bank data. I think @GlennQF posted about this at some point.
Regarding the webhooks I don’t think what you say is correct. We can only at the moment receive a webhook if payment is made using the “pay invoice online” option in QF. If the invoice is paid via bank transfer or we mark an invoice as paid (e.g. over the phone payment) QF sadly does not send a webhook. In other words we can’t rely on the webhook for payments as we only see some of them.
Really all I’d like is notification from QF that something has happened so that I can log in to action it so I’m not looking for the banks to do anything here. Just for QF to say “I’ve got new bank transactions that need tagging” or “I’ve new documents in the Receipt Hub” etc.
I’ve checked this out, and yes, that’s correct. The issue we have is there are so many ways to mark an invoice as paid (and unpaid), this could potentially introduce problems elsewhere. But, if the demand is there from the community, as with other features, we could look at this further.
As with the above point, if the demand is there from the community, we’re happy to look at this as we do every other feature.
QuickFile is developed based on demand from the community, so the most requested features are introduced. Watch this space.
Just wondering if there might be any liklihood of a payment notification for methods other than just credit card anytime in the next 3-6 months?
I could really do with a webhook being sent when an invoice is marked in QF as paid, irrespective of how (and I don’t really need to know in the webhook how it was paid, just that it was). When the original concept of Webhooks was disucssed with @Glenn on QF this was one of the webhooks discussed.
The webhook for payment received is triggered for more than just credit card payments. It’s triggered by payment via one of the integrated gateways (PayPal, Stripe, GoCardless etc. - full list in the documentation)
I can’t really offer any timelines as it’s not something we’ve looked into deeper as of yet. We tend to look into it further if there’s a higher demand on the forums. All I can suggest at the moment is watch this space.
That’s fair enough, if I’m the only one asking for it then I can appreciate it doesn’t make sense.
My only frustration is what was offered when webhooks were announced (triggering me to get my end ready for them along with the API) hasn’t been implemented.
I’d also say that the means of payment is secondary to knowing whether the invoice was in fact paid. One of the main reasons we integrated with the API and webhook in the first place was so that our database could be updated when an invoice is paid which would allow me to do some useful things at our end.
I’ve been wondering though if there is a workaround to this? Can I find out though the API if an invoice is in a paid status? If that is possible then I could potentially create a task nightly to check each unpaid invoice to see if it’s now paid. I’ve looked on the API reference and can’t find a reference to invoice paid but I might be looking in the wrong place.
We’re happy to possibly work with you on an alternative here. The problem with payment triggers is the scope is very broad, there are so many places in the application where invoices can be marked as paid. Even though much of the logic is centralised, it’s a very complicated process intercepting all these points and triggering payment hooks. If we also have a large number of users enabling this or small numbers with very high traffic it can potentially create some undesirable performance problems.
Maybe we can break this down and prioritise those areas that will be beneficial to you and most other users. How do you mostly commonly log payments to invoices, manually, bank tagging, CSV imports, bulk entry, API? If we were to implement in stages which area would be the most beneficial for you?
Thanks for the reply and for offering to potentially help with this.
I’d say we’d most commonly log payments to invoices using bank tagging (75%) followed by Sagepay (15% - but already covered by webhooks) and manually (10%).
The bit I can’t quite follow is when I look at the list of invoices, QF is able to tell me that they are paid. Is there not a invoice status or similar in QF which records this simple fact and if so isn’t the fact that this set the sole point you’d need to raise a paid trigger? Or is it that the invoice overview screen looks at the invoice value and compares this to payments received and marks as PAID if the two are true (meaning no status flag of paid per-se exists)?
For a workaround I looked in the API reference last night and there is a System_SearchEvents method which I believe I could use to search by invoice ID (so I could run through all invoices marked as unpaid) and if that method returns an event containing “payment” I could trust that the invoice is paid (either partly or fully, which is good enough for us). It seems clunky but could work unless you see any issues?
If you run an
Invoice_Get call through the API, part of the invoice details that’s returned is
<Status>DRAFT</Status>. This could be one of the following values:
- CREDIT NOTE (Has been credited)
And a few others. The ones above are the ones you’re likely to be interested in to know whether it’s been paid or not.
<Invoice_Get xmlns="http://www.QuickFile.co.uk" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.QuickFile.co.uk http://www.quickfile.co.uk/WebServices/API/Schemas/invoices/Invoice_Get.xsd"> <Header> <MessageType>Request</MessageType> <SubmissionNumber>548746879787545456456569</SubmissionNumber> <Authentication> <AccNumber>6********</AccNumber> <MD5Value>******************************</MD5Value> <ApplicationID>*******************************</ApplicationID> </Authentication> </Header> <Body> <InvoiceID>5983462</InvoiceID> </Body> </Invoice_Get>
<?xml version="1.0" encoding="utf-8"?> <Invoice_Get> <Header> <MessageType>Response</MessageType> <SubmissionNumber>548746879787545456456569</SubmissionNumber> </Header> <Body> <InvoiceDetails> <InvoiceID>5983462</InvoiceID> <CreatedDate>2016-09-07</CreatedDate> <InvoiceType>INVOICE</InvoiceType> <InvoiceNumber>000001</InvoiceNumber> <PurchaseReference /> <Description>Test</Description> <IssueDate>2016-03-01</IssueDate> <PaidDate /> <ClientID>********</ClientID> <ClientCompanyName>Customer A</ClientCompanyName> <ClientContactName>Mr Example</ClientContactName> <ClientContactEmail>email@example.com</ClientContactEmail> <ClientAddress><![CDATA[<br>]]></ClientAddress> <ClientCountryISO>GB</ClientCountryISO> <ClientVatNumber /> <PayeeCompanyName>Company</PayeeCompanyName> <PayeeAddress><![CDATA[Address1<br>Address2]]></PayeeAddress> <PayeeVatNumber /> <Currency>GBP</Currency> <TotalAmount>250.00</TotalAmount> <Discount>0.00</Discount> <Notes /> <Viewed>False</Viewed> <TermDays>0</TermDays> <TermNotes>Default invoice terms</TermNotes> <Language>en</Language> **<Status>PAIDPART</Status>** <TaskLines> <Task> <ItemLineID>*******</ItemLineID> <CreatedDate>2016-09-07T00:00</CreatedDate> <ItemID>0</ItemID> <ItemName /> <ItemDescription>Test</ItemDescription> <NominalCode>4000</NominalCode> <TaxName1>VAT</TaxName1> <TaxPercentage1>0.00</TaxPercentage1> <TaxName2 /> <TaxPercentage2 /> <UnitCost>100.00</UnitCost> <Qty>2.5000</Qty> <LineTotal>250.00</LineTotal> </Task> </TaskLines> </InvoiceDetails> </Body> </Invoice_Get>
I’ve logged this to our development planner for now, so we will explore a few options shortly. We’re currently involved in some other areas of development at the moment but we should be able to take a look some time in October.
Thanks both for the feedback, very much appreciated.
The status from invoice_get is much better than my idea of parsing the events. I think though if you are kindly planning to look at extending the webhooks in or soon after October I’ll hold off the coding for the API for now as webhooks is a much more elegant and efficient solution for this than polling daily all unpaid invoices using invoice_get.