galoymoney / galoy-pay Goto Github PK

Description

We can't seem to receive payments in nostr browser clients when folks use things like Alby. It seems like the issue has been diagnosed as a CORS one. More details in the nostr thread below:

• https://primal.net/e/note1qj0333p2cc5rx6tgdqfqlsdpj8g7f5ytvs3unavhnm2sqx53m94qa6w3u4

step to reproduce: open https://ln.bitcoinbeach.com/nicolas?amount=100&currency=SATS with brave

Nan will display instead of a dollar amount. switching currently and using dollar as the unit of account also have an issue.

when sending some sats as an anonymous donation, someone may want to add a comment on it.

currently this is possible to have a Memo from the mobile when sending to another user. there is no way to do it currently from galoy-pay.

it may require some update on the backend. Also important to take into consideration the anti spam measure on the memo.

When an invoice is paid, we should denominate the amount in the user display currency. In the image below, the display currency is set to GHS (Ghana cedis) (as shown in the localStorage inspector by the right) but the amount showed after payment is denominated in USD.

Merchants might want to make the appearance to resemble e.g. company colors and maybe even a Logo or some additional Text.

This could be done by some simple CSS instructions.
Kemal mentioned BTCPay enabled something similar, so maybe the solution can be replicated.

My first thought was to enable sideloading a CSS-file via parameter in the URL. This might not be ideal here though.

https://en.m.wikipedia.org/wiki/Hong_Kong_dollar

we know with the logs that most of the payment is made in dollars. so we should have a way to set a dollar amount.

The way BTCPayServer manage invoice is probably a good inspiration.

Testing out the latest PR that was merged with LNURL support and think I ran into an issue with printing QR codes.

OS Used: MacOS Monterrey 12.0.1
Browser Used: Safari 15.1 (17612.2.9.1.20)

Steps to reproduce:

1.) Navigate to /[user]/print
2.) Click blue "Use Web URL" button
3.) Click blue "Print QR code" button
4.) Cancel system print window
5.) Click blue "Use LNURL" button
6.) Click blue "Print QR Code" button
7.) Safari will prompt "This webpage is trying to print. Do you want to print this webpage?", click "Print"
8.) Print preview generates blank

I also tested this with Firefox 94.0.2 on the same OS and didn't encounter this issue. Also tested on iOS 15.1.1 with Safari and didn't encounter this issue, so it seems to be only affecting Safari Desktop.

This appears to be a known issue with the react-to-print library that this repo is using. See: MatthewHerbst/react-to-print#397 . The posted workaround is kind of ugly, unsure if it would be worth it to implement in this repo.

• be able to pass an amount in sats in the header so that the invoice created contain the amount
• be able to set a sats amount from the page (ie: ln.bitcoinbeach.com/username)

Add support for NWC, which would enable users to zap directly from their Nostr client. This is basically the counterpart to LN addresses, for receiving.

Not sure if this is the correct module to create this issue.

Specs: https://github.com/getAlby/nips/blob/master/47.md

Example: https://github.com/mutatrum/ligess

UX How-to:
https://blog.getalby.com/native-zapping-in-amethyst/

There should be a simple user experience for merchants who want to accept Lightning payments to the Bitcoin Beach Wallet (or other Galoy Wallet).

Could be saved as a bookmark on a mobile device or tablet.
It should allow multiple employees at a merchant location accept Lightning payments without the need to be authenticated in the merchant's wallet account.

Similar to BTCPay numpad POS

Clicking "Connect the Bitcoin Beach Lightning node" link at https://pay.bbw.sv sends user to a 404. Appears to be because it has /testnet/ in the URL.

For printed lnurl

Currently the LNURL pay code usage does heavily depend on custodial services running the infrastructure allowing to receive payments all the time and supplying the clearnet domain however the LNURL protocol does support Tor domains as well which make the self-hosted setup easier.
There are no mobile wallets which currently support LNURLs using a Tor address, but to reduce the barrier to entry to self-custodial usage this should be improved.

Changes will be likely necessary in:
The mobile app (this repo) to recognize the onion addresses
https://github.com/GaloyMoney/lnurl-pay - where the LNURL related functions are
https://github.com/GaloyMoney/galoy-pay- to resolve the onion addresses using a Tor proxy

Example LNURL over Tor address and setup with BTCPay: https://gist.github.com/openoms/9be181ffba14afcfb458cd3e1d726b5e

when opening galoy-pay on mobile, this is what we have:

while the UX might be ok for a tipping page (Alice share a link to the world to receive tips), it's not great interface for alice to use this as a point of sales terminal for in person payment.

for it to make a good POS, we should have:

• a keyboard that show on the screens. the keyboard should be designed in a way that is incorporate in the rest of the page, as opposed to the native ios/Android keyboard.

here is an example with how cashapp is doing such keyboard integration:

• after putting an amount, the QR code should be displayed, with an invoice that contain an amount (and replace the keyboard)

As it's slight different use case than the tipping page, I think this could be pointed out to the /pos page.

The "Connect the Bitcoin Beach Lightning node" link at https://pay.bbw.sv goes to 404.

Can help prevent fraud

currently when an invoice is being created, there is a poll to know if the invoice has been paid

the intention is that if the invoice has been paid, then there should be a checkmark letting know the payer that the payment has been received

but maybe people are probably leaving their tab open, this result with a lot of unnecessary poll/ load pressure to our server.

so we should have a backoff mechanism after some time (maybe 30 min or 1h).

maybe also using subscription would avoid this issue (@samerbuna)

Cobac Request
Invoice page should show underlying exchange Rate
Reason: Transparency - Cobac said that it's best practice in Turkey to show the exchange rate so customer can verify he is not being ripped off / knows the underlying exchange rate is fair.

Example:
Invoice amount in Display Currency TRY 1,000
Invoice amount in Sats 125,448 sats
Exchange Rate: 797,143 TRY / BTC

this repo is really used to tips the users

so tips would be a better repo name than lnpage

• Replace BBW logo with Blink logo in center of QRs (invoice and paycode),
• Replace BBW in the header/nav of the page with Blink icon
• Add small line of text above "Powered by Galoy" --> "Bitcoin Beach Wallet is being renamed to Blink. Learn more: blink.sv"
• Paycode page: Update "username's paycode" to "Pay [email protected]"
• Update Lightning address in the navigation menu to "[email protected]"
• Update colors of buttons/borders to match blink oranges/gradients
  • view button examples in figma dark mode UI https://www.figma.com/file/rH7A7NquSsXEH7v8eGuYM7/Blink-(BBW)-Mobile-App-Design?node-id=4724%3A98228&t=YVZMGIoU2FP3GqrK-1

Not sure if it makes sense to leave pay.bbw.sv the way it is (old branding) and have pay.blink.sv get new branding (probably not?), but we should consider our plan for sunsetting pay.bbw.sv. (if we do a redirect, it may make sense to communicate the name change very clearly to not surprise anybody)

Can help prevent fraud

I had a go at fixing this but for some reason it was not working in BBW (not only did it not fix the USD wallet issue but it also made payments fail for BTC wallets too so I rolled it back).

date/commit-height: 2023-04-15 2197b53 for version reference

relates to #444

problem: currently the printable static qr is a website url with parameter for lnurl in uppercase encoding.
this results in the qr not being accepted by lightning wallets and quite some advanced users and an additional qr reader being necessary to fix issues. waiting for standardization might hurt users and thus adoption in the meantime.

problems:

• uppercase
• website url
• lnurl only

measures for better wallet compatibility and usablility I imagine with e.g.

• band together with other (esp. wallet) teams to level up on interoperability
• show the encoded text underneath the QR Code for human readability in doubt
• make it lowercase, I would not count on other implementations mitigating this (known fail with samourai wallet encoding BC addresses uppercase leading to problem for users not aware of this)
• option for lnurl only
• option for lnaddress only
• option for bip 20 uri with fallback parametersfor lnurl/lnaddress
• (future) option for bolt12
• don't rely on clearnet only (as openoms already suggested in #444)
• add list of wallets tested as compatible with the qr (app symbols might suffice) to the print page

wallet tests

Only scanning the QR as is with wallets available to verify if I can pay the lnaddress included in the lnurl as a parameter of the webwallet.
Not validated if the payment is actually happening.
My list is sorted by likelyhood (most likely first) the wallet implementation is used, Android only.

problem: user is blocked from action without feedback for the reason.
expected behavior: information on what parameters need to be adjusted.

When preparing to send bitcoin there is reasons why the completion of the process is blocked, the botton to "Confirm Payment" is blocked. Those reasons are not transparent to the user and might not be easily mitigated in the process with multiple views depending on changing things going forth and back.

One reason might be the address is recognized as an internal one? (suggestion by Kemal)
Another reason seems to be the left over amount for the fee is too low, especially when trying to empty the wallet this might make things difficult.
Also payment is blocked for low amounts …
Maybe the address type could be a (if not currently then a future) reason…
etc.

basically the user needs to know what is going on and get advise what should be the parameters to change instead of being blocked.

No accessibility/text features on... mobile safari is cutting off numbers. Also the dropdown looks weird, not sure if there is an easy way to change it so it's not half light grey, half dark grey.

When you create an invoice in LN cash register, user expects that "Share" will pop open the OS share functionality and share the invoice that has been created (as it works in the mobile app). Currently, it captures a link for sharing the cash register:

"Use the link embedded below to pay [username] some sats. Powered by: https://galoy.io"

Let's update so that the "share" button works as it does in the mobile app, which is that it shares the invoice. If possible, we should also include the QR image in the sharable message.

Note: this is for mobile browsers only. Desktop experience is different, and does need improvement which will be outlined in a separate GitHub issue.

After an invoice is paid and user navigates back to cash register home, the note from the paid invoice still persists.

(also see formatting issue, the note field is cutting off the border of the edit note button)

This was discussed at daily east

Builds have been failing due to a git issue

causes all instances running galoy-pay to display the same. This should be configurable for example for :

https://pay.freecorn.galoy.io/ and all others.

Will need a value to be passed in:
https://github.com/GaloyMoney/charts/blob/main/charts/galoy-pay/values.yaml
for the build.

Steps to reproduce:

1. Click top/right hamburger button
2. Ways to get paid
3. Lightning Cash Register
4. Planet button to launch the web app
5. Enter any amount
6. Press Create invoice button

Expected result:

A bright new BTC lightning invoice is generated (currently displaying a 5 mins max expiration timer with a Blink logo QR code and 2 links (copy and share invoice)

Actual result:

The QR code is blinking few times and then fading forever so it's not possible to be scanned

Environment:

Google Pixel 6 Pro
Android 13 (5 Aug 2023 update)
Google Play version (1 Jul 2023)
Kernel 5.10.157-android13-4-00003-g776d0a76f6aa-ab10208116
Blink v2.2.120.30000578

There is no automatic payment confirmation currently.

Step to reproduce:

• open https://ln.bitcoinbeach.com/nicolas
• pay one sats
• page doesn't refresh

Current functionality: clicking QR code copies the lightning invoice
Feature request: When user clicks on the QR code, it should show a modal or prompt asking the user to choose which bitcoin wallet(s) installed on their device to pay the invoice.

To Implement Fix

In this file, add the lnUsdInvoiceCreateOnBehalfOfRecipient mutation as well and then implement by one of:

• (easier) adding a fallback to usd mutation if original mutation fails with the MutationDoesNotMatchWalletCurrencyError error
• (harder) poll the currency of the default wallet somehow first and then switch on mutations based on the currency

This may be out of scope for this webservice, just dropping it anyway.

Situation: I have some other POS / stock management (maybe even think as far as web shop and lnswitch) for products and want to use your webservice for very easy integration of payment with lightning.

Currently:

• I can hand out the link to other people and have no need to trust them with handling the received sats. awesome.
• I can generate a link with the url parameters with many ISO currencies already. very nice, I dont need to calculate for sats value nor have to denominate in sats but still can.
  Just it is necessary to confirm again and manually operate on the invoice via qr or text.

Basic Problem: This is not a good user experience. Staff training might be difficult but an option, operation by users directly is not practical.

Solution: I'd like to be able receive the invoice in a proper format and make it directly useable by basically any application with a single request to the webservice.

such formats useable could be e.g.:

• text of the resulting invoice
• qr image of the resulting invoice
• json including different encodings or parts easy to encode in the integrating applications

some more parameters useful might be

• invoice type (bolt 11, maybe even bolt 12 in future, lnurl taking preserving the valued of given parameters, …)
• encoding format (text, incoice as json, data as json, qr as image file, qr as data-url)
• maybe image format (svg, png)

problems I see:

• this might enable DOS for the webservice, some API management might be desirable
• maybe it's regarded abuse of this service and should be a seperate one

From @Extheoisah - "The issue occurs when we get a delayed response from the price subscription that converts the USD amount to SAT. SO if we haven't subscribed or gotten an update of the price and you switch the currencies, we get an invalid value NaN"

There is a Fallback Scheme in LNURL. If implemented in the Paycode Print it could eliminate the need for a second QR as fallback for all non LNURL wallets. Then, all users could scan the same QR - users with LNURL supported wallets could pay directly, all others could scan with camera and be directed to the Web URL.

Decoded example (Uppercase):
HTTPS://LN.BITCOINBEACH.COM/ideasarelikeflames?LIGHTNING=LNURL1DP68GURN8GHJ7MRW9E3XJARRDA5KUCN9V93KSTNRDAKJ7TNHV4KXCTTTDEHHWM30D3H82UNVWQHKJER9V9EKZUN9D35KKETXD3SK6ETN7KSR69

This would make the QR a bit more complex. To mitigate, the Web URL could be shortened with a shorter domain:
e.g.
HTTPS://BBW.SV/ideasarelikeflames

Also the URL in LNURL could be shortened from

https://ln.bitcoinbeach.com/.well-known/lnurlp/ideasarelikeflames

to

HTTPS://BBW.SV/U/ideasarelikeflames

resulting in a fairly compact QR:

HTTPS://BBW.SV/ideasarelikeflames?LIGHTNING=LNURL1FP29G5ZN8GHJ7SJZ2UH9X430D9JX2CTND35KKETXD3SK6ETNV8UF7N

Furthermore, if all wallets in the ecosystem checked for a Web URL in a QR when they dont find a payment request, like Breez Wallet already does, the need to switch from wallet to mobile's camera wouldn't be necessary, and non LNURL wallets could navigate to Web URL from wallet to get a Bolt11.

h/t to @CandleHater for bringing this idea up.