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

[John Heenan]

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

 

 

[Paul]

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.

[John Heenan]

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.

[John Heenan]

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.

[John Heenan]

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

Edited April 9, 2024 by johnhe
incomplete

[John Heenan]

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.

[John Heenan]

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.

Edited April 9, 2024 by johnhe
correction

[John Heenan]

Here are current settings

[Paul]

56 minutes ago, johnhe said:

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.

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.

[John Heenan]

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.

 

[Paul]

Ok, to see if I understand:

• 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.

 

You said:

22 hours ago, johnhe said:

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

But it appears that it may also be possible for us to allow the payment method (From the 4 mentioned) to be set in the gateway configuration in Blesta) so that the payment button generates a BTCPay invoice in the desired method. Or, we can simply remove the option and allow the client to select it.

What path would you recommend?

• Allow the payment method (of the 4 options) to be set in the gateway config in Blesta, so that the button specifies that method when a BTCPay invoice is created.
• Or, comment out the line so that the client is presented with the options?

Curious what you think is the best way to go. Do you think admins want to force the client to pay with Lightning or BTC on the gateway config level, or let the client choose? I assume that the client will only be able to choose from methods that have been configured in BTCPay Server? So if BTC is the only option, then only it will appear.

[John Heenan]

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.

 

[John Heenan]

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

[John Heenan]

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

[John Heenan]

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.

 

 

 

[John Heenan]

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.

[Kurogane]

I report this "BUG" two years ago blesta module only accept BTC as payment even if the store allow multiple coins.

 

This is competitor module and this is correct way blesta should be display.

 

 

Module should be display store coin supported instead of just accepting BTC/LN.

 

 

[John Heenan]

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.

[Paul]

@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

@Kurogane I don't see a bug here at all, if these altcoins are plugins to BTCPay Server and not configurable out of the box, then they fall squarely under the category of feature request. You can make a feature request at https://requests.blesta.com to recommend adding support for additional coins.

 

[John Heenan]

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.

 

[Kurogane]

10 hours ago, Paul said:

@Kurogane I don't see a bug here at all, if these altcoins are plugins to BTCPay Server and not configurable out of the box, then they fall squarely under the category of feature request. You can make a feature request at https://requests.blesta.com to recommend adding support for additional coins.

Maybe not a "bug" but is not done correctly, Blesta module not should managed coins if not btcpay store, For example if btcpay support 3 coins blesta module should be display that three coins if two then two etc.

I already create feature request as i say two years ago and ignored or not care https://requests.blesta.com/topic/btcpayserver.

You need to see how whmcs handle their module and you will see what is blesta module lacks.

 

[John Heenan]

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

[John Heenan]

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

 

Edited April 19, 2024 by John Heenan
Removed uncesessary detail

[Kurogane]

Can you test if you can pay LTC invoice?

Right now i don't have how to test it with altcoins.

If possible to add more coins to test it would be great.

[John Heenan]

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.