🦋 Improve payment methods selector and allow advance management

[Tirodem]

Context

We have a lot of thoughts about fiat payment processors.

We learnt that :

• Sum Up has a (hidden in documentation) maximum limit for online payment
• in France, for european cards, with respective fees :
  • Sum Up online (without paying monthly subscription) is more interesting up to a 25€ order
  • After that, Stripe is more interesting because of lower fees
• Depending of the account type, Paypal has payment limitations (see comment here on previous request : https://github.com/B2Bitcoin/beBOP/pull/1389#issuecomment-2353803267 )

We also know that :

• Bitcoin onchain can be bothersome because of fees for small payments, and implemented a 1000 Sats amount minimum to display this onchain - previously https://github.com/B2Bitcoin/beBOP/pull/76/files then a seemingly current minimum amount of 10000 - I didn't find where it was in the code- ; currently it's 6.27€, it can change with time
• Lightning payment can be bothersome for huge amounts, depending of :
  • channel capacities (with a node)
  • ACinq Phoenix Server fees and auto-liquidity feature fees

Currently, payments can be restricted if :

• disabled in /admin/config
• disabled for a particular product
• disabled if not setted (credentials in payment processors, bank informations in shop identity for bank transfer, env values for BTC / LN on .env.local, XPUB on interface for nodeless on-chain, and httpconf password for Phoenix Server LN nodeless)

And there's "substitutions" :

• stripe won't be displayed if sum up is setted
• paypal will be proposed as card if neither stripe or sum up aren't enabled
• LN Node will

Needs

This is to be precised and discussed on a grooming with @coyotte508 .

First thing in my mind is :

• 💡 let's allow a be-BOP owner to define a minimum and maximum (strict or not) amount to enable a payment (filter = total order amount, VAT included, delivery fees included), for both payment method and payment processor

This directly raises a warning about this case :

• going on checkout with a default country
• selecting a particular payment mean
• changing the delivery country
• the cart amount changes
• ❓ what happens to the payment mean ? Is it resetted ?

Other case is the use of PoS Seat with a discount.

And, 3rd case : what about a wrong configuration when Stripe and Sum Up are enabled on the same order price range ?

But, in the end, maybe we can do smarter than just having tresholds for payment mean activation or not (while it can be a good beginning, at least for Sum Up vs Stripe and Paypal).

I'm open to discussion.

[Tirodem]

For information, nearly 10 years ago, I worked on some kind of payment processor balancer for benchmark, live tests, progressive deploy and technical A/B test.

At this time, we considered :

• cart amount
• customer ID last digit or order last digit range (for a more or less kind of random dispatch)
• payment processor availability
  • that is something we thought about with Ludom, the fiatroulette, to avoid be-BOP from adult industry to send a customer to a fiat payment processor from whom they are banned, or if the service if temporarily unavailable entwined with a random dispatch to an available target payment processor
• billing country
• delivery country
• etc

While we had to implement a "stickyness" through cookie / session / account to the processor in case of random dispatch (on big pro eshop websites, it can be scary for the customer to have the payment form change on each command), we don't have this consideration on be-BOP for now I think. Maybe we could add, in the future, the possibility for the be-BOP owner to display an information note on the /checkout with a custom message (like "Depending of your amount order, you can be send to Sum Up or to Stripe), but it's minor and has to be light.

I don't want that exactly, I'm just sharing experience, and some needs we might have in the future outside plain amount order, like "hey, who knows".

And as we did earlier already, introduction of back-up payment processors already can be a good thing (imagine that your node is down ? use phoenix server ; phoenix server down ? use a yet-to-implement 3rd party service instead).

We also can imagine something specific to Lightning Network depending of the channel capacity (related to https://github.com/B2Bitcoin/beBOP/issues/1467 , like not providing the payment mean if notification was send at 80% capacity and the pending order will triggers a bigger channel management + fees on Phoenix Server if nothing was done since notification).

Or, another idea : we can also disable on-chain payment if payment fees are more than 5€, or 10% of the order amount.

We can slice it, as long as we know what's pertinent and make an evolutive implementation.

⏺️ Still, the Sum Up vs Stripe balancer depending of the order amount is the 1st case to implement, I think.