[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

Also, you can monitor how much disk space you have left when a blockchain is being downloaded, verifed and havings its UTXO pool (chainstate) built with with 'df -h'. If too much is going to be used you can disable a blockchain as above.

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

On 4/20/2024 at 4:18 PM, Kurogane said:

It's ok, i going to test myself when i have time.

If you use https://github.com/btcpayserver/btcpayserver-docker then something like the following can be used to add in ltc, dogecoin, dash and monero. I have not tried it so I don't know how much of it will work.

Enabling even one coin at a time puts a heavy strain on server at the start of catching up with its blockchain. It is not just a matter of downloading, the blockchain needs to be verified and a pool of UTXOs (chainstate) needs to be built up. So while you can enable multiple coins at one time, its not ideal.

# to see current settings exported in environment
set | grep BTCPAYGEN

# do not run this sequence one after another. enable one coin only at a time and wait for its blockchain to catch up

# add in ltc
btcpay-down.sh
export BTCPAYGEN_CRYPTO2=ltc
cd $BTCPAY_BASE_DIRECTORY/btcpayserver-docker
. ./btcpay-setup.sh -i


# add in dogecoin
btcpay-down.sh
export BTCPAYGEN_ADDITIONAL_FRAGMENTS="$BTCPAYGEN_ADDITIONAL_FRAGMENTS;dogecoin"
export BTCPAYGEN_CRYPTO3=doge
cd $BTCPAY_BASE_DIRECTORY/btcpayserver-docker
. ./btcpay-setup.sh -i

# add in dash
btcpay-down.sh
export BTCPAYGEN_ADDITIONAL_FRAGMENTS="$BTCPAYGEN_ADDITIONAL_FRAGMENTS;dash"
export BTCPAYGEN_CRYPTO4=dash
cd $BTCPAY_BASE_DIRECTORY/btcpayserver-docker
. ./btcpay-setup.sh -i


# add in monero
# see also https://sethforprivacy.com/guides/accepting-monero-via-btcpay-server/
btcpay-down.sh
export BTCPAYGEN_ADDITIONAL_FRAGMENTS="$BTCPAYGEN_ADDITIONAL_FRAGMENTS;monero"
export BTCPAYGEN_CRYPTO5=xmr
cd $BTCPAY_BASE_DIRECTORY/btcpayserver-docker
. ./btcpay-setup.sh -i


# to only allow btc and ltc
btcpay-down.sh
export BTCPAYGEN_EXCLUDE_FRAGMENTS="dogecoin;dash;monero"
cd $BTCPAY_BASE_DIRECTORY/btcpayserver-docker
. ./btcpay-setup.sh -i


# to only allow btc, ltc and dogecoin
btcpay-down.sh
export BTCPAYGEN_EXCLUDE_FRAGMENTS="dash;monero"
cd $BTCPAY_BASE_DIRECTORY/btcpayserver-docker
. ./btcpay-setup.sh -i


# to reallow dash and monero
btcpay-down.sh
export BTCPAYGEN_EXCLUDE_FRAGMENTS=""
cd $BTCPAY_BASE_DIRECTORY/btcpayserver-docker
. ./btcpay-setup.sh -i

 

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

@Kurogane, if you do want an invitation to open a store, your tests are sucessful with LTC anf you want to try othe altcoins then I will enable them in order of your choice until I run out of hard drive space for storing their blockchains.

Currently I have three BTCPay running on three servers, only one of which has enough hard drive space for extra altcoins and I plan on letting this server go in the next few weeks.

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

Sorry, I don't hold LTC or any of the other altcoins you showed. Nor do I plan to in the future. I don't have anything against them though.

If you want I can send you an invite to open your own store for a few days. You can then add in xpubs for Bitcoin and LTC and even use  Lightning with an external node or with Breez or with Blink, as I have enabled these extra plugins in BTCPay. Of course I can make off with your Breez and Blink funds, so you would need to trust me. But I could not make off with youe BTC and LTC funds, if you use xpubs.

You can generate your own invoice and pay yourself. If you still run Blesta you can try and see what happens when you comment out line 268.

I hope this is acceptable.

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

On 4/13/2024 at 12:53 PM, John Heenan said:

With regard to issue with @Kurogane and alt coins, my guess is that not setting the two parameters mentioned in the API call will give him what he wants. Maybe he could let us know the results of commenting out line 268, as I did.

@Paul My solution, commenting out line 268 in file of btcpay_server/btcpay_server.php. also fixes problem of @Kurogane

 

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

On 4/13/2024 at 2:42 AM, Paul said:

You can make a feature request at https://requests.blesta.com to recommend adding support for additional coins

@Paul I would like to add two feature requests. One minor and one large. I cannot put images into the requests topic so I will copy text from here and reference here.

Also, the minor proposal gives context to the major proposal and the major proposal involves use of the BTCPay API, as mentioned here. So, maybe it is appropriate to link to here to start off and provide context.

Minor proposals for enhancement of the Virtualmin module

Proposal at  https://requests.blesta.com/topic/minor-enhancments-of-the-virtualmin-module

1) Add in an extra text box below the 'Configurable Options' of an order form similar to Domain option below (which is not an option, it is a requirment).

 Call the option 'Site Header Text'.  If you take this value and pass it to Virtualmin in the remote API version of the call to 'virtualmin create-domain' as parameter --content then this text will appear in the header text of the created default web site. The reference for the API is at https://www.virtualmin.com/docs/development/remote-api/#the-remote-api and the reference for individual commands of the API is the same as for those of the CLI. This means call is https://www.virtualmin.com/docs/development/api-programs/create-domain/ is the reference for create-domain API call. The reference does not explain what is done with the --content parameter and the reference to a filename does not appear to make any sense in [--content text|filename] with regard to code paths I followed in Virtualmin source code. Well, I have told you now what it does. The text of --content goes at the top of newly created web sites in big bold letters.

2) Also please pass in a --desc parameter with create-domain with automtically constructed text, such as "Created through Blesta, order ID: xxxx". This will appear in an admin screen in Virtualmin for the account holder and the text can be edited by the account holder.

3) The API refenece page above has the following text: "The output from remote.cgi is plain text, including the command-line program’s output and an exit status line indicating success or failure". Please make sure Blesta uses it. For example, during tests Blesta got told to create two different accounts with the same domain name. Virtualmin freaked and refused. Blesta thought everything was great and failed to provide any notification of failure. It might be wortwhile to check beforehand if the domain already exists.

Major proposal for enhancment of use of BTCPay API

Proposal at https://requests.blesta.com/topic/major-proposal-for-enhancment-of-use-of-btcpay-api-in-a-new-module

The proposal is big but the text of the proposal is small. Pease add in an additonal module to allow creation of BTCPay stores that works in the same manner as the Virtualmin module. It would be great if the module could also be used to provide an addititonal service to order in other order forms, but this may be asking too much. The reference for users for what to do after user level store creaton is at https://docs.btcpayserver.org/CreateStore/. Please include a field for the store name. Suppose a user filled ''My New Store Created By Blesta". What an account holder will get when they login is in image below. They can go into Settings to alter the default currency. More information about what to do can be provided in links in the welcome email, as configured by the Blesta admin. The API reference to create a new store is at https://docs.btcpayserver.org/API/Greenfield/v1/#operation/Stores_CreateStore

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

10 hours ago, Paul said:

@John Heenan I'm not sure I have a complete understanding of this, but I've created the following task if you want to review and advise whether this is the proper solution. https://dev.blesta.com/browse/CORE-5168

I think we should be getting more precise. For example, what exactly does default mean? 

There is no simple answer. Here is my attempt at providing a precise answer.

Below is the default screen when a manual invoiceis created in BTCPay.

1. The Supported Transactions Currencies appears with three ticked boxes when Lightening is enabled and when LNURL is enabled
2. If Off-Chain and LNURL is selected then only the Off-chain will appear in invoice
3. If Combined URL/QR is chosen then only one QR box will appear.
4. The equivalent in the API is the "paymentMethods" array.
5. If the "paymentMethods" is not set in the API then this appears to be equivalent to choosing all available transaction curriencies, as BTCPay calls it.

6. The 'Default payment method on checkout' ABOVE provides a single choice way to override the setting BELOW in Settings, Checkout Appearance

7. The "defaultPaymentMethod" string in the API is, I guess as in invoice creation, really a way to say, no I don't really want the store default.
8. The upshot of all of this is that not setting either of the two API variables we (hopefuly) get a clear outcome: all available transaction curriences (unless LNURL clashes with Off-Chain) and no override of store default
9. Now what does 'store default' or its overide mean in practical terms?
10. If a combined URL/QR it means nothing. It can't, as there is no choice to make.
11. If not combined then it decided which of the two QRs is shown, with the chosen one having it's button in green.
12. A complicating factor is that if store settings indicate to show URLs as copyabe text, then they will both be shown below at the same time.

So what happens if we do decide to pass a "paymentMethods" array and "defaultPaymentsMethod" string in the API call?

Hopefully the answer is simple: that it corresponds to making alterations in a corresponding manner as with the manual invoice creation. 

With regard to issue with @Kurogane and alt coins, my guess is that not setting the two parameters mentioned in the API call will give him what he wants. Maybe he could let us know the results of commenting out line 268, as I did.

 

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

Altcoins FAQ for BTCPay at https://docs.btcpayserver.org/FAQ/Altcoin/

It looks like up to nine altcoins can be added. There are currently integrations for 14 altcoins.

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

I should also add that in the context of Blesta, sending a LNURLPAY makes little sense. It's main advantage is that payments can be made without generating an invoice beforehand, as LNURLPAY allows invoices to be generated on the fly.

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

I now have better information on how BTCPay behaves with settings and how the very popular Blink wallet behaves. There is bizarre behaviour can have a profound effect if Blesta invites admins to override settings.

The BTCPay default payment method is set from Settings, Checkout Appearance, Invoice Settings

 

BTC (LNURL-Pay) is only available if it is enabled from Lightning, Settings, Enable LNURL (image above).

For Lightning,  BTCPay will only every show an LNURLPAY or an Offchain fully encoded invoice, NOT BOTH ON THE SAME INVOICE. 

LNURLPAY has advantages over Offchain, but not when a regular invoice is being issued.

In BTCPay, if a PARTICULAR invoice is specified to to show both LNURLPAY and Offchain encoding it will only show the Offchain encoding: the LNURLPAY setting is overriden.

So checking all three below for a PARTICULAR invoice is pointless when generating an invoice as only Onchain and Offchain will show in the invoice, not the LNURLPAY.

The effect is the same whether the unified on-chain and lightning URL/QR code is enabled or not (image above)

The following is subtle with the Blink wallet.

Blink will read LNURLPAY if not part of a unified QR code

Blink will read Offchain if it is part  of unified QR code with Onchain

Blink will not read LNURLPAY if it is part of a unified QR code with Onchain. This means show a unified QR code with Onchain and LNURLPAY to Blink and Blink will choose the slow and expensive Onchain.

So if a Blesta admin decides they will be smart, allows unified URL/QR, allows Offchain and LNURLPAY, but not Offchain which overrides LNURLPAY in BTCPay, and a customer pays with a Blink wallet, guess what, they are forced Onchain with a slow result and unnecessary expense.

 

 

 

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

Or the choice of what the customer sees, including the default choice or even no choice, could be left to the Blesta admin.

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

A refinement. Blesta could add to a customer form two choices, defaulting to first:

• Pay with BTC Onchain (this can delay order processing)
• Pay with BTC by server default (may or may not also include BTC Lightning)

Or this could be left to the Blesta admin as a choice for all customers

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

2 hours ago, Paul said:

• The payment method is set by the Blesta button, so that the BTCPay invoice generated requires payment via that method.
• BTCPay supports (Bitcoin or Lightning, or any of the 4 you mentioned) as returned.

A BTCPay method is set by API call if it includes an option to set it. I don't see how it has anything to directly do with a Blesta button. The buttons a customer sees on the final payment screen are BTCPay buttons, not Blesta buttons and what they are depends on what the API call instructed.

To eliminate confusion, there is the Blesta invoice and the BTCPay invoice. The only way to make a payment with BTCPay is to 'create an invoice'. So there are two invoices involved. BTCPay really considers itself to be a store that includes a payment gateway. With Blesta we are short cutting the BTCPay store part and going straight to make a payment through generating a second invoice with an API call to BTCPay. Also the 'invoice' terminology is core with Lightning. Also the concept of an invoice expiring is central to  Lightning. Which means if a customer does not pay before expiry then another invoice has to be generated with BTCPay.

A regular BTCPay only recognises BTC crypto. Its payment methods are BTC Offchain and BTC Onchain. BTC Offchain recognises payment through a LNURL and through what I suppose is traditional Lightening, through a choice of both and also through a BIP21 unified Offchain/Onchain URL. Also all methods have QR codes.

Why add to the confusion?

Personally I think Blesta should stay out completely of changing BYCPay store default choices and make it very clear the payment method is chosen by the BTCPay store default. It only adds a second layer of confusion otherwise. I think Blesta should very prominently display advice to check defaults,  to test well and also advise that Lightning is very convenient for customers (fast and tiny fees) but requires additional set up to using an onchain xpub address and that a hot onchain wallet should never be used with BTCPay. I think helping Blesta customers feel safe about using BTCPay is important.

You could offer a choice to either force BTC Onchain use or to allow BTCPay store default. If you default to force BTC Onchain then this is backward compatible and you don't have to make any prominent announcements.

You are requesting I provide opinions about what is best, something I cannot do.

 

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

2 hours ago, Paul said:

Removing this option lets the user select Bitcoin or Lightning like your original screenshot from a BTCPay invoice? Do you consider this the best solution? I assume if you don't have Lightning configured it'll just default to Bitcoin.

I have tested with a new store with Lightning not enabled and the behaviour was fine with line 268 commented out.

You ask as to best solution with my current config. No, if all wallets are BIP21 compliant. But they are not, including the world's most dominant Lightning wallet by far: Blink based wallets. Odd that https://bitcoinqr.dev/ refuses to even list Blink wallets in its compliance test conformity list.

I deliberately took the unified BTC/Lightning URL and QR image option off during tests as I needed to see a clear visual distinction between BTC and Lightning during tests. 

Until I have made tests with different popular Lightning wallets, I will keep the distinction. Blink based wallets may not be happy with the unified BIP21 appoach, maybe for good reason. I will need to complete more tests to confirm some earlier results.

 

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

Here are current settings

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

For the record, this is what now appears in the Blesta log, as returned by BTCPay server, with the fix.

s:14:"paymentMethods";a:3:{i:0;s:3:"BTC";i:1;s:12:"BTC-LNURLPAY";i:2;s:20:"BTC-LightningNetwork";}s:20:"defaultPaymentMethod";s:20:"BTC-LightningNetwork";

I did not see allowed payment methods with my own curl API resposne to the store for information. It likely reflects what my store currently allows as payment methods.

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

Yes, commenting out line 268 of btcpay_server/btcpay_server.php (->setPaymentMethods(['BTC'])) fixes the bug for me.

The payment form for the invoice now shows both Bitcoin and Lightning payment options, consistent with the store defaults.

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

Found the bug.

Line 268 of file btcpay_server/btcpay_server.php overrides any defaults with
    ->setPaymentMethods(['BTC'])
 

Will see what happens if I comment out the line

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

From https://docs.btcpayserver.org/API/Greenfield/v1/#operation/Stores_GetStore there are four recognised default payment methods. When I do a curl with this API call to my store I get the answer 'BTC-LightningNetwork' in field defaultPaymentMethod. 

 

 

From Blesta logs for a create invoice call to my store, the following is in the returned data from the BTCPay serverr;

s:14:"paymentMethods";a:1:{i:0;s:3:"BTC";}s:20:"defaultPaymentMethod";s:20:"BTC-LightningNetwork";

The documentation for this call is at https://docs.btcpayserver.org/API/Greenfield/v1/#operation/Invoices_CreateInvoice

So it looks like Blesta specified to only use one possible payment method 'BTC' (equivalent to 'BTC-Onchain'), even though my store's default payment method is 'BTC-LightningNetwork'.

My investigation continues.

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

6 minutes ago, Paul said:

What currency is the invoice in? I assume it is being converted automatically to BTC?

So the issue is that payments from Blesta can only be made in the standard BTC, not through the Lightning network which is also BTC but off chain?

If this is specified in the button code, it may need to be a setting in the BTCPay gateway config to specify the type.

AUD currency for both Blesta generated invoice and store manual generated invoice. Yes AUD is being converted to BTC/SATS properly with both invoices (uses Coingecko).

Yes to second paragraph

I don't understand the point about the button code. I am currently looking to determine what Blesta passes to BTCPay in the API call to compare with BTCPay API docs.  Blesta logs the API call but not give the full call details. The response form BTCPays shows the payment method is BTC. Have to determine what the correct interpretation of this is.

The store BTCPay default paymenth method (by my choice) is to allow both BTC onchain and BTC offchain (with Lightning) for invoices

My main point is that an invoice generation  can override the store default and this appears to be what Blesta is doing.

[BTCPay payment module forces BTC payment method instead of allowing store to use its default]

Blesta: 5.9.3
PHP: 8.2.7
OS: Debian 2.5 (stable, bookworm)

When I manually create an invoice within BTCPay Server with my store's default payment method on checkout, the customer gets a choice between BTC and Lightning methods of payment:

 

 

When Blesta creates an invoice within the same store, the customer only gets to pay by BTC:

 

There is no option within Blesta to allow the BTCPay store to use its default method. 

I would expect that Blesta would either use the store default or offer a choice as to whether to override the store default or not

 

 

[How do I stop Blesta 5.9 with php 8 filling up daily logs with E_DEPRECATED messages?]

Have opened a new topic in 5.10 Beta Bugs category:
https://www.blesta.com/forums/index.php?/forum/37-bugs/

 

 

[How do I stop Blesta 5.9 with php 8 filling up daily logs with E_DEPRECATED messages?]

Now with Blesta 5.10.1 beta 1 with php 8.2.7

Here is a start after just installing a fresh overwrite of Blesta 5.9.1 with 5.10.0 beta 1, unpoulated database swapped back in, php 8.2.7

cat general-notice-2024-*.log | cut -d ' ' -f 1 --complement | awk -F, '!seen[$1]++' | sed 's/\home.*\/blesta\///'

general.NOTICE: E_DEPRECATED: Creation of dynamic property SimplePie_Autoloader::$path is deprecated {"code":8192,"message":"Creation of dynamic property SimplePie_Autoloader::$path is deprecated","file":"/plugins/feed_reader/vendors/simplepie/autoloader.php","line":67} 

 

cat general-notice-cron-*.log | cut -d ' ' -f 1 --complement | awk -F, '!seen[$1]++' | sed 's/\home.*\/blesta\///'

general.NOTICE: E_DEPRECATED: Creation of dynamic property TicketManager::$SupportManagerDepartments is deprecated {"code":8192,"message":"Creation of dynamic property TicketManager::$SupportManagerDepartments is deprecated","file":"/vendors/minphp/bridge/src/Lib/Loader.php","line":256} 

 

[QR code image not visible when enabling 2fa on a customer account]

I got the QR code image to diplay for admin for Blesta developer version by logging out and loggin in again.

[QR code image not visible when enabling 2fa on a customer account]

Below is image for a logged in customer with Manage Account, Authentication, Enable Two-Factor Authentication,

There is no QR code image visible, despite statement in section 2.

No error message found in logs.

Blesta version is 5.9.3 and php version is 8.2.7. Both on regular version and developer version.

On the developer version the QR image is also absent from staff account setup of 2fa (My Info, Time-based HMAC One Time Password). QR image shows in staff account setup of 2fa for regular version.