feat: add "custom" internally settled fiat method - #245
Open
cashowdev wants to merge 1 commit into
Open
Conversation
Adds a second administrative payment method alongside the existing cash settlement. It follows exactly the same flow, an internal invoice that a cashier confirms manually, but records fiat_method "custom" instead of "cash", so operators can tell the two apart in payment history, receipts and the Orders extension. The use case is a payment received through a channel LNbits does not integrate with, for example a bank transfer, a voucher or a staff tab, that still has to end up in the till total. Rather than duplicating the cash branches, the literal "cash" checks are replaced by a shared INTERNAL_FIAT_METHODS tuple in helpers.py, so adding another method later is a one line change. - helpers.py: INTERNAL_FIAT_METHODS and a label colour per method - views_payments.py: invoice creation, _payment_method_from_payment and _serialize_tpos_invoice_response now work on that tuple - views_payments.py: validation logic extracted into _validate_internal_fiat_invoice, with the existing /cash/validate route unchanged and a new /custom/validate route next to it - tasks.py: _payment_method reports "custom"; _tabs_settlement_method falls through to "other", which is correct for this method - checking_id becomes internal_custom_<hash> instead of internal_cash_<hash> - payment-method-selector.js: Custom button, same visibility rule as cash - tpos.js: internalFiatMethod computed drives both the dialog title and the validation route - dialogs.html: the confirmation dialog shows CUSTOM or CASH - tests: test_custom_validate_invoice_endpoint, mirroring the cash test, and asserting that /cash/validate rejects a custom invoice Custom reuses the allow_cash_settlement toggle and the same super user requirement. A separate per TPoS toggle would need a migration; happy to add one if you prefer that.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
HUMAN WARNING: This PR is entirely AI generated
Remain cautious before merging current PR ...
What
Adds a second internally settled fiat method,
custom, alongside the existingcash settlement.
It follows exactly the same flow: an internal invoice is created and a cashier
confirms it manually. The only difference is that it records
fiat_method: "custom"instead of"cash", so the two can be told apart inpayment history, on receipts and in the Orders extension.
Why
Merchants regularly take a payment through a channel LNbits does not integrate
with: a bank transfer, a voucher, a staff tab, a partner app. Today the only way
to get that into the till total is to book it as cash, which then makes the cash
figure wrong at the end of the day. A second, neutrally named method keeps the
books straight without pretending to be a payment integration.
How
Rather than duplicating every cash branch, the literal
"cash"checks arereplaced by a shared tuple in
helpers.py:Adding a third administrative method later is then a one line change plus a
button, not another pass through the codebase.
Backend:
helpers.py:INTERNAL_FIAT_METHODSand a label colour per methodviews_payments.py: invoice creation,_payment_method_from_paymentand_serialize_tpos_invoice_responsework on the tupleviews_payments.py: validation extracted into_validate_internal_fiat_invoice. The existingPOST .../cash/validateroute is unchanged;
POST .../custom/validatesits next to ittasks.py:_payment_methodreportscustom._tabs_settlement_methodfalls through to
other, which is the right bucket for this methodchecking_idbecomesinternal_custom_<hash>instead ofinternal_cash_<hash>Frontend:
payment-method-selector.js: Custom button, same visibility rule as cash.Currency symbol plus the
more_horizicon, sinceqr_code,tollandcredit_cardare already takentpos.js: aninternalFiatMethodcomputed drives both the confirmationdialog title and which validation route is called
dialogs.html: the confirmation dialog showsCUSTOM <currency>orCASH <currency>Tests
test_custom_validate_invoice_endpointintests/test_api.py, mirroring theexisting cash test. It also asserts that
/cash/validaterejects a custominvoice with a 400, so the two routes cannot be used interchangeably.
Backwards compatibility
Nothing existing changes behaviour.
/cash/validatekeeps its path and itssemantics,
fiat_method: "cash"payments are unaffected, and no migration isneeded.
Important note
customcurrently reuses theallow_cash_settlementtoggle and the samesuper user requirement, so it needs no schema change.