Cash Pay Server - UI Updates, Currency Conversion and Static Invoices

1 223

Written by

jimtendo

No bio yet...

4 years ago

This is a status update on the previous post on Cash Pay Server here:

https://read.cash/@jimtendo/cash-pay-server-b6d4983b

Updates

UI Updates

The tentative UI (default) when using the JS library now looks as follows:

This will be updated so that the confirmation is an overlay on top of the QR Code. In doing this, we make it easier to add animations, etc.

A basic example of the tentative API is here:

https://codepen.io/jimtendo/pen/vYNbEVO

Cash Pay Server can now accept fiat currencies which get converted to their BCH equivalent upon invoice creation. This (currently) uses Coinbase exchange rates and, on the pay.infra.cash server, these rates will be updated every 5m (configurable on a per-server basis via an environment variable).

Usage will likely be as follows:

var invoice = new CashPay.Invoice(...)
                         .addAddress('', '10USD') // String with currency code suffix
                         .addAddress('', '1AUD') // String with currency code suffix

Additionally, the currency that will be displayed to the user can be specified with the following:

var invoice = new CashPay.Invoice(...)
                         .addAddress('', '10USD')
                         .addAddress('', '1AUD')
                         .setUserCurrency('AUD') // Show final amount to user in AUD

Static Invoices

Thank you @dagur for the idea. I have integrated this into Cash Pay Server under the term "Static Invoice". The final interface for this will likely be:

var invoice = new CashPay.Invoice(...)
                         .staticInvoice() // Print QR code on paper and re-use me!
                         .addAddress(...)

To keep the interface consistent, if the Invoice is marked as static, a replica of the initial invoice is created each time a wallet makes a Payment Request and the fiat amount is re-converted to the BCH amount. All other parameters will remain the same as the initial invoice.

Additionally, all events (webhooks and websockets) will be broadcast under the original Invoice ID - meaning, if a use-case does occur where one wishes to listen for these events, they can.

A simple example of where these events might be used is in tracking inventory. Each time a broadcasted Webhook is received, we can assume that there should be one less beer in the fridge. Another simple use-case is for simple donation collection on Websites (or in store) where the QR Code should not expire and should be allowed re-use (while allowing dynamic currency conversion to take place)

As the term "Static Invoice" might not be very clear, am open to suggestions on this.

An example of its use is here:

https://codepen.io/jimtendo/pen/gOayjPR

Still To-Do List

Things are moving at a good pace and I'm hoping to have stable API's so that I can Alpha release within the month. That said, there are still some important pieces that need doing before this:

Finalize Static Invoice API (this term will likely change - please offer suggestions in comments).
Build easily integratable NPM packages so that developers are not confined to CDN. (Was stuck on this for a long time - and do plan on doing a write-up on how to achieve this as Webpack as this occupied > 1 day of my time painfully tinkering).
Make the default UI cleaner and more customizable.
Proper testing of the JSONPaymentProtocol (used by EdgeWallet)
General code clean-ups (we now use eslint to enforce style)
Add Unit Testing (before V1.0.0 release)
Webhook ECDSA verification (in-progress but there are some issues between Node Versions).
Raw Script output support (need to verify that JSONPaymentProto can actually work with this).
Lots more that I cannot think of at the moment.