New Checkout Feedback

[dennisreimann]

We're curious to hear your thoughts about the new checkout, which we ship as an opt-in feature with v1.7 — let us know below!

[pavlenex]

It is added already?

[dennisreimann]

It's not available for the new checkout yet, but there's a PR already: Kukks#8

This will be added soon. Meanwhile you have to use the classic version of the checkout.

[petzsch]

We are NOT affiliated with the ongoing Bitcoin Bonus Scam.
In short: if you paid them anything, your money is lost.
They only use our free and open source software.

Please report these fraudsters to: https://complaint.ic3.gov/

[dstrukt]

Really appreciate this feedback, and glad to hear you're enjoying the update .. will work this feedback into the next set of iterations!

[jgrodrigues]

I second the second and third points. Users a lot of the times want to pay with crypto using their CEX accounts, and CEX's do not accept these QR codes, they only accept the QR codes with the wallet address, and you have to manually input the btc amount to send. A better solution would be to have a button or a way to obtain a QR code with just the wallet address and not the whole payment information, besides having a way to easily copy or show the wallet address. Previously we would copy the wallet address and use a third party to generate a QR code containing only the wallet address and the customer would manually input the amount to send, when a customer was using a CEX.

[dennisreimann]

Addressed those point in #4489 and #4471. Thanks for the feedback!

[dergigi]

For zero-amount (any-amount aka top-up) invoices, unified QR code of v2 defaults to on-chain, but I'd much prefer it would default to Lightning (LNURL-pay).

On-chain is used even when "Default payment method on checkout" is Off-Chain.

• Any amount, LNURL-pay: ❌ No QR code¹
• Any amount, Off-Chain: ❌ QR code shown, but QR code encodes an on-chain address
• Any amount, On-Chain: ✅ QR code shown, expected behavior

Footnotes

1. Tracked as https://github.com/btcpayserver/btcpayserver/issues/4352 ↩

[petzsch]

For zero-amount (any-amount aka top-up) invoices, unified QR code of v2 defaults to on-chain, but I'd much prefer it would default to Lightning (LNURL-pay).

We discussed this also during final testing and came to the conclusion:

• LNURL has it's place for LNAddress and withdraws
• for Top-Up invoices we also want to offer a unified QR code, but with a 0 amount bolt11 invoice ... it is on our agenda
• The consensus was to keep LNURL out of the new checkout as it offers only minimal benefits for this use case (sending a receipt URL to the user is nice, yeah)

None of it is set in stone of course and that's why we love your feedback to help us understand how you use btcpay.

[Wayne4167]

So what do I do now

[dennisreimann]

In case the new checkout doesn't work for you yet, you can always switch back to the classic version, which ist still the default.

We understand that it isn't fully done yet and will improve it based on the feedback we receive.

[Kukks]

For zero-amount (any-amount aka top-up) invoices, unified QR code of v2 defaults to on-chain, but I'd much prefer it would default to Lightning (LNURL-pay).

On-chain is used even when "Default payment method on checkout" is Off-Chain.

• Any amount, LNURL-pay: ❌ No QR code¹
• Any amount, Off-Chain: ❌ QR code shown, but QR code encodes an on-chain address
• Any amount, On-Chain: ✅ QR code shown, expected behavior

Honestly, the unified checkout is really not that great for flexibility on payment methods since it is just bip21 with a bolt11 lightning query string parameter. I very much prefer a different approach which expands the lightning address spec to handle other payment methods. See Kukks@7c03ca0

I did this draft branch which does this in BTCPay a while back:
* Every invoice in btcpay becomes a lightning address
* Additional well-known paths for onchain, bolt11, 
* Additional well-known path for discovering all payment methods at the address 

Can someone test if the lightning query parameter can have an lnurl instead of bolt11 and if wallets handle that correctly?

0 amount bolt11 invoices offer inferior ux imo.

Footnotes

1. Tracked as https://github.com/btcpayserver/btcpayserver/issues/4352 ↩

[petzsch]

Regarding your last question: replacing the bolt11 invoice with a lnurl in a unified QR code seems to work:

QR content: bitcoin:bc1q8e7cm6p46qyljs6nsj2v59usq6tdzljad0agyy?amount=0.00002&LIGHTNING=lnurl1dp68gurn8ghj7cm0venx2efwwpjhg7nnvd5zuet49ap9gse0d3h82unv9acxz7f0dyh4js2sg3m4jm3kvdxx65ztxex4572vvex45msydmdj9

I've tested it with Breez and it defaults to the LNURL. (haven't tried actually paying, but I assume that works as well: it showed the correct amount)

So that would be our prefered for top-up invoices or the default to be going for?

[pavlenex]

This is a known bug.

[dennisreimann]

@strnly this is fixed in v1.7.1, which we just released.

[petzsch]

looks like an nbxplorer problem. Is this mainnet or testnet? We had a similiar issue this week on testnet. Can you try if you got a newer version of nbxplorer available? I'll check in mattermost if I find the discussion....

[utxo-one]

This is mainnet. You think I should modify the docker-compose generated by btcpayserver to use a different version of nbx? I recently just ran the btcpay-update.sh i saw that the image was updated during the pull

[petzsch]

I think there was something related to hot wallets (with or without the advanced RPC option) ... maybe try playing arround with that option... still trying to pull the discussion from mattermost.

[petzsch]

nbxplorer tends to get better wih every new version, I wouldn't downgrade :-)

[petzsch]

This is the discussion: https://chat.btcpayserver.org/btcpayserver/pl/yb7fg3u3k78u7ydr31zuw8z7nw
I think @NicolasDorier suggested removing that RPC config option as it does more harm then good.

[PeterRounce]

Checkout v2 is currently missing an NFC option to allow for card payments
Button is "Pay by NFC and LNURL-Withdraw" on Checkout v1

[dennisreimann]

Ok, this is most likely related to the iframe permissions that get set by the webserver. Can you check whether or not you are doing something extra there?

Also, what error does the browser console report? Something like this? Uncaught (in promise) DOMException: The Clipboard API has been blocked because of a permissions policy applied to the current document. See https://goo.gl/EuHzyv for more details.

[strnly]

I get exactly that

invoice:1 Uncaught (in promise) DOMException: The Clipboard API has been blocked because of a permissions policy applied to the current document. See https://goo.gl/EuHzyv for more details.

Not sure what "we do extrat". Almost sure it used to work flawlessly only last week.

Any hint on the permission I should allow for the iframe?

Thanks for your time

[strnly]

I suspect we need to give permission to a feature:
geolocation
microphone
camera
midi
encrypted-media

I suspect geolocation, microphone and camera are irrelevant in that case. But I am not sure if i should give permission to midi or Encrypted media.

Thanks @dennisreimann

[dennisreimann]

Fixed in #4453

[dennisreimann]

We addressed this in #4489.

[pavlenex]

@astupidmoose

"Show timer if less than X minutes are left" would be a decent compromise?

This is exactly what we do already.

Recommended Fee:

I actually think we should remove this entirely, it's up to a wallet to properly recommend a fee, recommended fee isn't clear information for soemone: Which fee? Who charges this fee? Is merchant charging me a fee?

"Plugins" aren't visible:

Which plugins I think both sideshift and the other one are there?

Logo/Name:

+1 for logo it really seems small cc @dennisreimann

[dennisreimann]

"Show timer if less than X minutes are left" would be a decent compromise?

This is exactly what we do already.

I think what Mike is referring to is that this should be configurable, which is not the case currently.

Recommended Fee:

I agree with Pavle here, yet the customer needs to clearly understand that they need to pay the shown amount and fee should suffice to get confirmed quickly. It seems like there are still too many problems with that and people end up underpaying.

"Plugins" aren't visible:

SideShift and FixedFloat are compatible by now — please check if you need to upgrade them from the Manage Plugins page.

logo it really seems small

I have an idea about how to make it configurable via CSS and also give the option to hide the store name if that's desired.

[astupidmoose]

I think what Mike is referring to is that this should be configurable, which is not the case currently.

This is exactly what I mean. I'd like to be able to configure the warning to happen at the exact moment the invoice is generated. Some might prefer 50% of the way, some might be ok with 5 minutes.

Recommended Fee:

I agree with Pavle here, yet the customer needs to clearly understand that they need to pay the shown amount and fee should suffice to get confirmed quickly. It seems like there are still too many problems with that and people end up underpaying.

While nice in theory, but most people just don't understand fee's and how they work in getting blocks into the chain. When they put 1/sat because its "cheaper" they don't realize this could potentially take weeks to confirm. Having this recommended fee saved this issue for sooooooooooo many of our customers as it made them think "oh what is this, my wallet mentions fees, I should make sure they are the same", and worked as a tool for us to also be like "we recommended you pay 50/sats but you only paid 2/sats.

"Plugins" aren't visible:

SideShift and FixedFloat are compatible by now — please check if you need to upgrade them from the Manage Plugins page.

Thanks, updated and fixed. Didn't realize these would need independent updates.

[bigsk1]

Would be nice to have a screenshot or demo store to check it out and see how well we like it.

[dstrukt]

You can enable this checkout (V2) via the Store Settings > Checkout Appearance on the Live Demo from the main website.

We will definitely be surfacing more screenshots, etc.. soon though!

[strnly]

We addressed this in #4489.

When is #4489 and/or #4308 deployed ? Thanks

[dennisreimann]

Hopefully with the next release, no ETA yet.

[strnly]

Actually been released in 1.7.3. Works fine with Brave now

[strnly]

We addressed this in #4489.

Hey there.

Same issue was detected with Duckduckgo browser. User cannot copy the address tapping on the QR code.

[strnly]

Hi there,

Regarding the new 1.7.x checkout style.

I believe I need to call Checkout type = V2 when creating store via API

https://docs.btcpayserver.org/API/Greenfield/v1/#operation/Stores_CreateStore

Once created, can I have a hosted logo (from my marketplace) uploaded via API in the New Checkout automatically ? I believe the link to hosted logo on my market place will render with Checkout V2. So i could still use the link to hosted logo... but you may tell me it's better to upload the logo according to V2 UI in BTCPay

Finally, how do we select brand color via API ? Current API still refers to custom CSS... which is not helpful here.

Thanks!

[strnly]

Hi there,

Regarding the new 1.7.x checkout style.

I believe I need to call Checkout type = V2 when creating store via API

https://docs.btcpayserver.org/API/Greenfield/v1/#operation/Stores_CreateStore

Once created, can I have a hosted logo (from my marketplace) uploaded via API in the New Checkout automatically ? I believe the link to hosted logo on my market place will render with Checkout V2. So i could still use the link to hosted logo... but you may tell me it's better to upload the logo according to V2 UI in BTCPay

Finally, how do we select brand color via API ? Current API still refers to custom CSS... which is not helpful here.

Thanks!

Hey there,

Hasn't been answered. How to we configure store color via API?

Thanks!

[dennisreimann]

It's not available right now and we will add it in the future. NO ETA yet.

[strnly]

Assuming if I change it in CSS root it will apply across the entire server, therefore the above API inclusion would no longer be needed. correct?

[dennisreimann]

The distinction of server and store-level makes sense nonetheless, e.g. for users of a third-party host. We'll get to implementing the API once these concepts are fully fleshed out.

[strnly]

[strnly]

Here is what I get

type=lnbank;server=https://subdomain.domain.io/;api-token=xxxxxx

When I test the connection it "cannot resolve in a timely manner"

Not sure how to resolve the DNS record. @NicolasDorier said you had worked on a fix included in a release for this week. Hopefully it addresses the issue.

Thanks!

[dennisreimann]

Please SSH into your server and run ping subdomain.domain.io (with the host from the server option in the connection string).

See if that resolves to the correct IP address. If not, check the hosts file (cat /etc/hosts) and see if it contains the hostname. If so, remove or comment out that line – afterwards it should work.

If you server has a static IP, you can also use that in the connection string server option.

[dennisreimann]

Does it work if you use the IP instead of the hostname in the connection string?

[dennisreimann]

Yes, that's the connection string. Like this please: server=https://YOUR_IP (also containing the rest like the token etc.)

[dennisreimann]

This one got resolved as a Cloudflare issue. Added a guide for troubleshooting LNbank connection problems.

[strnly]

Hey plebs!

In Server Settings > Theme, under Branding, we can now add a logo. Good.
Could we also set a color just like we can in Store Settings > General (under Branding) ?

Would be really great tbh. Does not seem like a huge stretch.

Benefit? when we redirect a customer to a payout/refund link, the branding is ours, not the BTCPay green.

Thanks!

[dennisreimann]

You should use the theme functiuonality for that or wait for #4527, which might also serve that purpose.

[strnly]

I am talking about the Them functionality under SERVER settings, you seem to refer to STORE Settings. We cannot edit the color of the SERVER. only the STORE.

[dennisreimann]

Yes, we don't intend to add a similar feature on the server level, because there's way more complexity involved at that level. Please go with custom CSS if you intend to change the server theme.

[strnly]

Understood. Is there a template for the CSS file format to use?
I tried before using the CSS file in the github repo, when loading it it messes up the whole UI of the admin panel. So the CSS file in Github is prob outdated (?)

[dennisreimann]

The light theme includes all variables you can set/override — see for instance the dark theme which extends the light theme by overriding some values.

So basically you define the CSS custom properties in the :root {} block, e.g. when redefining the primary color like this:

:root {
  --btcpay-primary-100: #fef3e6;
  --btcpay-primary-200: #fcdcb5;
  --btcpay-primary-300: #fbc584;
  --btcpay-primary-400: #f9ae53;
  --btcpay-primary-500: #f79621;
  --btcpay-primary-600: #de7d08;
  --btcpay-primary-700: #ac6106;
  --btcpay-primary-800: #7b4504;
  --btcpay-primary-900: #4a2a03;

  --btcpay-primary-rgb: 247,150,33;
  --btcpay-primary: rgb(var(--btcpay-primary-rgb));
  --btcpay-primary-accent: var(--btcpay-primary-600);
  --btcpay-primary-shadow: rgba(var(--btcpay-primary-rgb), .5);
}

[chendo]

We're hoping to add Lightning as a payment method to our live store soon, however there are some UX issues that the new checkout could help to address.

We would like to use the unified QR code option, however there are still wallet apps out there that have issues. Would it be possible to display the unified QR code by default, but still have options to show a Bitcoin-only QR code? I suspect apps that support Lightning are more likely to support BIP21, so theoretically we don't need an option to also show a BOLT11-only QR code.

Thoughts?

[pavlenex]

There are still wallet apps out there that have issues

Which apps have issue? The point of unified QR is to eliminate the options, if the wallets don't support it, it's best we ping them to do so, patching their poor work of not following specs, will only make the checkout look overcrouded and we'll be back to a legacy checkout in no time.

[dennisreimann]

I agreed with @pavlenex. If you find that the BIP21 option with unified QRs don't work for your customers just yet, opt-out of that setting and have them choose their prefered payment method explicitely. I'm sure that situation will vastly improve during this year and we've already seen increasing support since we made it more prominent on BTCPay Server.

[chendo]

It appears that Coinjar's app doesn't handle BTCPay generated QR codes even with just on-chain only... not sure what's going on there. Disregard my comment for the time being!

[chendo]

It would be good to have the option to display the fiat amount and currency where the BTC amount currently is, and potentially having the crypto amount underneath in smaller text. I know the fiat information is under View Details, but it would be great to be able to surface this easier for users.

[dstrukt]

This was in the original mocks, but we opted to remove .. but might be worth reconsidering.

Thank you for the feedback!

[esteban2006]

Hello there after updating to 1.7.5 I tried to create an invoice and I got this error

Warning: You have payment methods configured but none of them match any of the requested payment methods or the rate is not available. See logs below:
02/06/2023 03:20:26:Info Creation of invoice starting
02/06/2023 03:20:26:Info BTC_USD: The rating rule is coingecko(BTC_USD)
02/06/2023 03:20:26:Info BTC_USD: The evaluated rating rule is 22899.324
02/06/2023 03:20:26:Info BTC (On-Chain): Payment method details creation took 0 milliseconds
02/06/2023 03:20:26:Error BTC: Payment method unavailable (Full node not available)

Could anyone address me to an article or share steps to fix this

regards,

[dennisreimann]

It looks like your full node isn't synched. Can you confirm that's the case and if so see the logs for details?

[esteban2006]

That is correct the node has stoped sync

[cahueya]

Playing around with v2 Checkout I found, when using the "Redirect invoice to redirect url automatically after paid"-Option, the v2 Checkout leads to a javascript-pagereload-loop which the v1 doesn't. I haven't investigated further but which variables are passed back that might be different?

[dennisreimann]

Thanks! Fixed in #4633

[status21]

Set it to off chain default, of chain below 50 and on chain above 500. Works like a charme. Very appreciated that customer don't have to choose with the unified QR. Genius!

[zachherbert]

Really liking the new checkout modal (via WooCommerce), one quick question – any easy way to hide the store name? I couldn't find any documentation. Thanks

(specifically I want it to show just the logo, not the "Foundation" text)

[dennisreimann]

Yeah, in store Settings > General you can upload a Custom CSS File with this content:

.store-header .store-name { display: none; }

That does the trick.

[zachherbert]

perfect, much appreciated.

[dstrukt]

We could potentially build out more customizable granularity in the UI in the future as well, but glad to hear you're liking V2 @zachherbert!