ZGo invoices #1
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
ZGo should be able to provide an invoice for payment in Zcash so it can support non-retail applications like professional services.
assigned to @pitmutt
I believe ZGo's current item management implementation can support professional services, since you can create an item for your person-hour rate, and then enter your total billable hours for the project/client. The existing implementation can support different kinds of services and individual rates, e.g.: 10 hours of consulting at $200 plus 2 hours of admin work at $100.
As for the invoicing, I think there are two ways of implementing this feature:
Please add any other ideas or comments 😄
Here are my notes on what would be ideal, from my perspective as a business owner and accountant to businesses both in the crypto/web3 space and in the professional services space.
Prior to crypto/web3 we had been very involved in assisting businesses implement web2 apps into business processes to, as the mantra went "save time and money'. I can say that businesses are at this point exhausted with the need to sign up for yet another separate app they will need to sign into each time they need to perform some additional business function. Businesses are more keen on rolling off niche products that require work inside their platforms and want to have things more streamlined and efficient.
That being said this does not mean they are against technology that helps with their business, they just want it to work in the background without the need to constantly be signed into 100s of different apps switching between them to do each different task.
The number one problem with all crypto payment processing companies as we see it at the moment is that they miss the main point of what they are trying to achieve, which is to add a seamless process to the back end of the merchant’s already existing workflow allowing them to accept crypto payments. It should add no additional steps to the current workflow for the customer or the merchant, and it should absolutely not be a separate platform the business needs to sign into at any regular interval.
It should be set and forget, and should work 100% autonomously in the background.
The businesses you are wanting to target will already have invoicing software, and in almost every instance this is either already a part of their accounting software (Xero, Quickbooks, NetSuite, etc) or linked in with a number of other things such as their credit card payment gateways (Stripe, PayPal, etc). They don’t want you to build a separate invoicing system just for crypto.
Services like BitPay that require you to go into their platform to create an invoice to send out are super frustrating as it creates double handling and duplication of invoices every time someone wants to pay with crypto. As someone currently using a service like this it’s painful and cumbersome (more effort than just having everyone pay with credit card or EFT), but we do it because we love crypto and our clients want to pay us in crypto.
What merchants want you to build is a payment gateway that links to their current invoicing system via its API (The above 3 accounting software providers have extensive APIs), deposits the payment into their crypto wallet and then updates their invoicing software via this same API to mark the invoice as paid
From the customer side they should receive the same invoice they already do, from the businesses current invoicing software (not ZGo) the only difference being that next to the link on the invoice that says, ‘pay with credit card’, it has an additional payment link on it that says ‘pay with crypto or pay with ZCash’.
The process/workflow for paying with crypto should be the same as paying with a credit card. When you click on the link that says pay with crypto it should take you to a new webpage (the ZGo payment gateway page) this page should show the invoice denominated in Fiat as well as the live currency conversion and the amount payable in ZEC, it can be made to time out after 5 mins (to make sure the currency conversion rate is correct) or have a constantly updating rate, depending on how good of a product you want it to be. ZGo should be able to link through the invoice software’s API to pick up what invoice this is in the accounting system and pull all the data for this specific invoice to the payment page. The customer either uses their phone to scan the QR code and pay, or clicks on the ‘link wallet’ button to pay using a hardware wallet. As soon the block confirmation has been processed it should change to a new page showing their payment has been confirmed, in addition via the API it should mark the invoice as paid in the invoicing software
Another bug bear of payment gateways and processors is the cost of the platforms, and it seems everyone (in the credit card space at least) has taken a liking to the price gouging method of charging a percentage of transaction processed. The platform should charge a flat fee per month instead of an ever increasing amount based on transaction volume. You should want to incentivise businesses to push as much volume through your platform as possible by having a pricing structure that means the more that goes through the platform the cheaper it is to them the merchant, not the other way round, which acts as a disincentive to promote the “Pay with crypto/Zcash”. Implementing a fixed price model will mean that you will see businesses encouraging their customers to pay with crypto/ZCash instead of paying with credit cards, as it means more money in the merchants pocket.
Attached are a few mockups of what this could look like
Happy to take feedback and hear what other people think too
Process_Workflow.pdf
Thank you for the detailed post!
Agree completely. I don't know if this is happening everywhere, but at least around me, businesses are now even charging a credit card surcharge and are having different pricing between cash and credit card payments. One of my motivations for building ZGo is that Zcash technology allows for low-cost payment systems, that's why we don't have a fee-per-transaction model, rather a time-based subscription.
I understand the idea of seamless integration but at the moment I don't know if it is feasible given that I don't know what capabilities the invoicing system's APIs have. Also, I assume each would have its own, I would be surprised if this was standardized.
I believe most of these invoicing tools allow you to customize the invoice with HTML, so adding a link to ZGo is (probably) not an issue. This would get around the need to get the invoice tool to implement an API call to ZGo.
This link at a minimum should provide a way to identify your ZGo shop and the invoice ID. So I imagine the process would be something like this:
zgo.cash/invoice?shop=shopID&invID=invoiceIDThe most likely path will be to first implement invoicing in ZGo with no integration, to then follow with connecting it to an invoicing tool.
That’s great on the ZGo revenue model, and i agree is a great benefit of Zcash over other crypto chains having lower transaction fees that allows you to just do a normal fixed monthly subscription fee.
I also agree it is going to be a little more work, but the payback of doing the html link integrations with accounting software will more than outweigh the extra time to build.
There are in excess of 20 platforms (BitPay, Request, etc) i know already offering the separate invoice method and they all offer multiple crypto chains, which would make them more appealing than a single chain solution one such as ZGo, that being said none of our clients have taken any of these up due to their clunkiness making them non-viable in their eyes (and to note these are pro-crypto businesses searching for a way to accept crypto, these are not mainstream businesses who would be even less inclined) Given how easy the html link would be to setup (on the merchant side) you’d easily be able to have massive take up once it was built
Not that you’ll need to, as i believe your proposed html link and what you have mentioned so far will be more than sufficient, but if in the event you wanted to go down a full integration path with a 2 way sync you wouldn’t need to do too many different integrations, as the Accounting software market is quite centralised. There are 2 main players globally in the SME space (<$10M Revenue <50 Employees)
AU Xero has 65% market share
NZ Xero has 75% market share
USA Quickbooks has 73% market share
In the big end of town (>$10M Revenue >50 Employees) there are also only 2 main players
Netsuite (Oracle)
SAP
I’m not a developer, but we have numerous clients in the web2 space that have worked extensively with both the Xero & Quickbooks APIs and they seem to be of the opinion that they are very extensive and not too difficult to use. Xero being the easier of the two. So getting enough information to have the html link working with Xero and Quickbooks shouldn’t be an insurmountable task.
Attached is what it looks like in Xero on the merchant side to implement your html link option, nice and easy for the merchant to implement
We use a service called eway to accept credit cards and they use your exact planned method of html link, and here is their url as an example for you when building the ZGo one, incase it helps:
https://secure.ewaypayments.com/sharedpage/invoicepaymenthandler/PayThis/Xero?shortCode=[SHORTCODE]&invoiceNo=[INVOICENUMBER]¤cy=[CURRENCY]&amount=[AMOUNTDUE]
This is very helpful, thank you!
One of my other goals in creating ZGo is to foster the adoption of Zcash and your insight about businesses using crypto for payment is very valuable.
I agree that nothing will promote a service like an "It Just Works" functionality. I'll start breaking down the pieces that will get us there.
The Xero integration has been completed.