Add currency to support level

[Sjors]

Fixes #3

Tested EUR with BTCPay server. I didn't test Stripe yet.

To make it work with BTC as a currency we'd also need to allow fractional values. It would also require a workaround for Stripe. However I don't want to make this PR more complicated.

I should probably add some tests.

[JeffVandrewJr]

Localization is much appreciated!

Please test Square (instructions for Square test charges: https://github.com/JeffVandrewJr/patron/blob/master/test-charge.md). (See below comments.)

You had also mentioned adding some tests; that is much appreciated as functional/unit tests are somewhat lacking right now (see #10).

If Square/other testing is successful on your end, please post here and I will then test everything in Docker to make sure none of these changes broke the primary Docker deployment. Assuming that all works, I will then merge.

Thanks again!

[JeffVandrewJr]

Update on the above comment: Square does not support multi-currency (https://squareup.com/help/us/en/article/5415-can-i-accept-multiple-currencies-with-square). Each account can only accept its home currency. Currently Square is only available in USA, Canada, Japan, Australia, and UK. It is not available in the Eurozone.

Adding Euro/multi-currency support is still a good idea for BTC payments, however.

With that in mind, I would suggest adding a warning that using currencies other than USD will deactivate Square, and automatically make sure Square is inactive if a non-USD currency is selected. That would seem to be the easiest way to avoid breaking anything at the current time.

If you can add that, as well as any other tests you mentioned in your above comment, please then post here and I will test the main Docker deployment to ensure nothing is broken. Assuming not, I will then merge.

Thanks!

[Sjors]

Made a minor tweak: automatically convert currency name to symbol, so it looks like this:

Same on the creditcard page (see below).

This uses the Babel dependency which I added to dependencies.txt.

I also added that for Square the currency has to match:

I'm not having much luck with Square, perhaps because I'm in the Eurozone. I setup a test shop and tried both a EUR and USD payment with the test credentials. Both failed.

[JeffVandrewJr]

@Sjors Yeah Square isn't going to work for Eurozone payments. Is there any way you can add a warning to customers that choose non-USD currencies that Square won't work? Also please undo the changes you made to the code that processes Square payments.

[Sjors]

Yeah Square isn't going to work for Eurozone payments.

Not on production, but I'm not sure if that explains the error in their developer sandbox, especially because I get the same error with USD. I made a developer account with a merchant address in Europe. Someone else should test that.

Is there any way you can add a warning to customers that choose non-USD currencies that Square won't work?

It follows from the warning I added "The currency must match your Square home currency". We could also maybe fetch the currency via Square API as an extra check.

please undo the changes you made to the code that processes Square payments.

The changes in process_square are still needed for GBP, AUD, etc.

[JeffVandrewJr]

@Sjors I think adding the currency code to the PriceLevel model is as problem because price level data is set via freeform in the admin panel, so there is ample opportunity for the user to accidentally enter a bad three character currency code on a given price level which presumably will cause chaos on the backend.

One easy way to rectify this would be to have currency instead be an attribute of the BTCPayClientStore model, and therefore applied globally throughout the entire instance. It could be set by creating a new "Home Currency" view in patron/app/admin_views/__init__.py which would correspond display a form set in patron/app/admin_views/forms.py, said form being a dropdown of valid BTCPay currency codes. As a dropbdown rather than freeform text, this would force a valid currency code.

[Sjors]

I agree a dropdown would be better than a freeform field. Does the Python framework you use support enums perhaps (that automatically generate a dropdown form)?

[JeffVandrewJr]

@Sjors Flask is unopinionated on this and basically all matters (unlike Django). LibrePatron uses Flask-WTForms for forms; if you want to check out how to do what we're discussing using WTForms check out a SelectField in the WTForms documentation. It's very easy; I used one in app/admin_views/forms.py in the ThemeForm if you want to see an example.

SelectField basically uses tuples comprised of values paired with the display text for each value for the drop-down.