feat(tipping): honour the recipient's minimum on the tip that opens a DM - #1366
Merged
Conversation
…ns the chat Both the in-chat amount entry and the custom tip entry floored at the regional preset minimum, which is not the amount the recipient set. #1360 gave users their own minimum, `UserProfile.minDmChatInitFee` — the fee another user pays to open a DM with them — and neither entry read it. The fee buys the conversation, so only the payment that opens it pays: - `TipPaymentDelegate.minimumToOpenDmWith` is that floor, converted through USD into the currency the sender is entering in, falling back to the regional preset when the recipient charges nothing or a rate is missing. - `minimumTipFor(userId, ...)` charges it while no DM with that user exists and the system minimum once one does. The tip card follows it: presets below the floor are dropped from the modal, and `confirmTip` checks it, since a preset chip never passes through the amount entry. - The in-chat entry applies it to the send that opens the chat and drops the floor entirely afterwards. A contact DM never had one. The standing hint reads "$5 minimum" rather than "Minimum tip $5", matching the prompt that blocks a send below it.
The prompt read "$5.00 Minimum / Increase the amount to send"; node 9553:20236 has "$5.00 Minimum Tip / Please enter a higher amount". Both strings are shared by the three places that raise it — the chat send, the tip card, and the custom amount entry. The custom entry raised it as a destructive alert while the other two used the info style, so it also moves to info: nothing has failed, the amount is just under the floor.
The in-chat entry said "Swipe to Tip" for the whole life of a tip DM. Only the first payment is a tip: it pays the recipient's fee to open the conversation. Every one after it is an ordinary send with no minimum, so it now reads "Swipe to Send" and drops the floor hint, the same as a contact DM. The label and the floor were already asking the same question separately; both now read one flow, so they cannot disagree.
This was referenced Aug 28, 2026
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
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.
#1360 let a user set the fee another person pays to open a DM with them (
UserProfile.minDmChatInitFee), but no amount entry read it. Both the in-chat entry from #1362 and the tip card floored at the server's regional preset, so a tip under the recipient's own minimum was accepted locally and rejected on send.The fee buys the conversation, so it applies to exactly one payment — the tip that opens the DM:
TipPaymentDelegateowns both answers —minimumToOpenDmWith(recipient)andminimumTipFor(userId, recipient)— so the three entries can't drift apart. The fee is stored in whatever currency the recipient set it in, so it converts through USD into the currency the sender is entering in; when either leg has no rate it falls back to the preset rather than state a floor in a currency the entry isn't using.Two consequences fall out of the same rule:
confirmTipre-checks the floor because a chip never passes through the amount entry.Also fixes the below-minimum prompt to match node 9553:20236 — "$5.00 Minimum Tip / Please enter a higher amount", was "$5.00 Minimum / Increase the amount to send" — and moves the custom entry's copy of it from a destructive alert to the info style the other two already used, following #1361. The standing hint reads "$5.00 minimum".